Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dealing with IPv6 fragmentation in the DNS

blog.apnic.net

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Dealing with IPv6 fragmentation in the DNS

#41

Post by stephengillie »

tssva wrote: post #21
stephengillie wrote: post #9

Having a variable header complicates Cut-Through switching[0], which forwards the entire frame just after the switch gets the destination field of the header. This sounds like it would force a return to Store-And-Forward[1], where the switch waits for the entire frame to load into memory, before forwarding to its next hop. Waiting these few milliseconds doesn't sound bad, until you consider that's added to each packe…

Totally different layers. Switching occurs at layer 2 and isn't affected by whether the frame contains IPv4 or IPv6.

I was confused at first, because switches were mentioned in the article. But the Fates have allowed my mistake to be correct this one time, and provided a trove of education about the state of the art of network switching.

Re: Dealing with IPv6 fragmentation in the DNS

#42

Post by rasz »

verri wrote: post #31
feld wrote: post #29

Earlier quoted context omitted.

> I'd say it has a few main facets: - ICMP is dangerous, and needs to be blocked. This is partly true, as there is historically information leakage with ICMP under certain codes. So blocking all of it is easier than trying to figure out what should be allowed and what should not. It's actually quite easy to identify which should be allowed and which should not. ICMP: 0,3,8,11 (echo reply, destination unreachable, ech…

But why filter ICMP at all? I can understand that ICMP allows for covert tunnelling, but by that logic any IP protocol number should be blocked.

Under windows you cant whitelist applications allowed to use ICMP, all ICMP traffic originates from deep down ring 0 NT Kernel process.

Re: Dealing with IPv6 fragmentation in the DNS

#43

Post by oasisbob »

pilif wrote: post #18
joeseeder wrote: post #17

Earlier quoted context omitted.

Network I am on atm, IPv6 give me both green, IPv4 MTU fails ... It means my IPv6 vpn is better than IPv4 delivered by some wannabe corpo network masters.

the firewall is probably blocking ICMP. For a long time, it was considered best-practice to blanket-block ICMP and for a long time you could mostly get away with it. But over time some really useful stuff has been added to ICMPv4 (early congestion notification for example) and IPv6 mostly won't work at all without ICMP. I would argue that it's time for firewall administrators to reconsider this decision. The time whe…

> For a long time, it was considered best-practice to blanket-block ICMP

I agree with your point, but think this needs some clarification about who considered it a best practice - among enterprise firewall admins and financial-industry compliance audits, perhaps.

Large scale network operators have seen the problems associated with entirely blocking ICMP for at least a decade. (v4 has blackhole problems too)

A lot of the hatred for ICMP came from simple things like easy endpoint discoverability. nmap blew that argument out of the water pretty quick.

Re: Dealing with IPv6 fragmentation in the DNS

#44

Post by pas »

skywhopper wrote: post #20
tveita wrote: post #15

It sounds like IPv6 acknowledges that most protocols try hard to avoid fragmentation anyway, so fragmented packets are the exception. And it's not like fragmentation hasn't caused problems with firewalls in IPv4 either. E.g. http://all.net/Analyst/netsec/1995-09.html The fix is for equipment to handle the fragmented packets properly, just like for IPv4. How is forward fragmentation, which involves creating multiple n…

The problem is that the fragmentation header in IPv6 is not deterministic, so it can't be parsed in constant time, which is what makes it "anathema to a switch" which needs to be able to guarantee certain levels of packet throughput. IPv4-style fragmentation can be done in constant time.

It is still bounded time, which is still O(1).

Yes, the standard doesn't limit the number of extension headers, but looking at the fixed header, and at most 5-6 extenion headers is the maximum time required to process a packet. And that'd be enough for 100% of traffic.

The exact limit is the number of header types known to the processing node. Because encountering an unknown header should result in Parameter Error, and only one header can be used multiple times (the Destination Options), but that should be after the Frag one anyway.

Re: Dealing with IPv6 fragmentation in the DNS

#45

Post by feld »

verri wrote: post #31
feld wrote: post #29

Earlier quoted context omitted.

> I'd say it has a few main facets: - ICMP is dangerous, and needs to be blocked. This is partly true, as there is historically information leakage with ICMP under certain codes. So blocking all of it is easier than trying to figure out what should be allowed and what should not. It's actually quite easy to identify which should be allowed and which should not. ICMP: 0,3,8,11 (echo reply, destination unreachable, ech…

But why filter ICMP at all? I can understand that ICMP allows for covert tunnelling, but by that logic any IP protocol number should be blocked.

because some ICMP types are actually dangerous and can be abused
Post reply on HN