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

21–30 of 45 posts

Re: Dealing with IPv6 fragmentation in the DNS

#21

Post by tssva »

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.

Re: Dealing with IPv6 fragmentation in the DNS

#22

Post by tssva »

squeed wrote: post #16
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…

The real problem is that you can no longer look at a fixed offset for your parameters, which complicates filtering silicon. In other words, if you want to have a firewall rule of "drop tcp 135", in ipv4 you can just look at bytes 0x24-25 (for Ethernet). IPv6's extension-header mechanism means that the header has a non-fixed length, so you need to do work for the same effect. Given that firewalls are critical in a wor…

Most enterprise firewalls these days do some level of layer 7 packet inspection which requires going beyond looking at fixed offsets. The silicon to support this already exists. Even the $50 Ubiquiti ER-X router I use at home can do deep packet inspection assisted by silicon.

Re: Dealing with IPv6 fragmentation in the DNS

#23

Post by joeseeder »

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…

Totally agree, ICMP is needed.

When it's not blocked, you can debug and have healthy network, instead of a frankensteins monster.

Re: Dealing with IPv6 fragmentation in the DNS

#24

Post by toast0 »

tinus_hn wrote: post #10

> another painful issue in today’s IPv6 Internet, namely that of network filters discarding ICMPv6 Packet Too Big messages. How about we just let the people who configure these filters solve their own problems?

That's fine enough when that only directly affects those people or their networks. The article mentions Google public dns having this problem. If your customers are using them, and you're returning large DNS responses over ipv6, your customers will have trouble with resolving you names, and blame you, and you may not even be able to tell it's Google's fault.

Re: Dealing with IPv6 fragmentation in the DNS

#25

Post by wogna »

kevin_nisbet wrote: post #19
tinus_hn wrote: post #10

> another painful issue in today’s IPv6 Internet, namely that of network filters discarding ICMPv6 Packet Too Big messages. How about we just let the people who configure these filters solve their own problems?

I've actually had this conversation before, and it get's a bit tricky. 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 not perceived to be a problem. Most services just work, so TCP/…

> ICMP is dangerous, and needs to be blocked

I've fought this argument countless times and lost. Not being able to ping a server, check for "destination unreachable" messages, etc. leads to frustrating troubleshooting sessions.

Re: Dealing with IPv6 fragmentation in the DNS

#26

Post by rocqua »

the8472 wrote: post #8

> IPv6 Extension Headers require any transport protocol-sensitive functions in network switches to unravel the packet header’s extension header chain. This takes a variable number of cycles for the device and furthermore requires that the switch should recognise all the extension headers encountered on the header chain. This is anathema to a switch, in so far as it entails a variable amount of time to process. If it…

I agree that switches shouldn't care about TCP or UDP ports. That is a job for a firewall. However, that does not mean it is a good idea to have variable length headers in IPv6. In fact it seems like a singularly bad idea to me.

Regarding firewalls, I imagine it still sucks a firewall cannot judge each IP-packet separately but needs to deal with possible fragmented packets. Then again, that is the cost of being a firewall. You need to function at the application level and yet decide on the IP-packet level.

Re: Dealing with IPv6 fragmentation in the DNS

#28

Post by colmmacc »

rocqua wrote: post #26
the8472 wrote: post #8

> IPv6 Extension Headers require any transport protocol-sensitive functions in network switches to unravel the packet header’s extension header chain. This takes a variable number of cycles for the device and furthermore requires that the switch should recognise all the extension headers encountered on the header chain. This is anathema to a switch, in so far as it entails a variable amount of time to process. If it…

I agree that switches shouldn't care about TCP or UDP ports. That is a job for a firewall. However, that does not mean it is a good idea to have variable length headers in IPv6. In fact it seems like a singularly bad idea to me. Regarding firewalls, I imagine it still sucks a firewall cannot judge each IP-packet separately but needs to deal with possible fragmented packets. Then again, that is the cost of being a fir…

Switches use L4 ports to implement flow-switching. When multiple paths for a packet are available, it is convenient (it leads to less re-ordering) if the related packets from the same flow all choose the same path.

Re: Dealing with IPv6 fragmentation in the DNS

#29

Post by feld »

kevin_nisbet wrote: post #19
tinus_hn wrote: post #10

> another painful issue in today’s IPv6 Internet, namely that of network filters discarding ICMPv6 Packet Too Big messages. How about we just let the people who configure these filters solve their own problems?

I've actually had this conversation before, and it get's a bit tricky. 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 not perceived to be a problem. Most services just work, so TCP/…

> 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, echo, time exceeded)

ICMP6: 1,2,3,4,128,129,135,136 (unreachable, packet too big, time exceeded, parameter problem, echo request, echo reply, neighbor solicitation, neighbor advertisement)

See, that wasn't hard. These are the base requirements for you to have a reasonably functional IPv4 network, and the absolute minimum requirements for IPv6 to work properly.

Re: Dealing with IPv6 fragmentation in the DNS

#30

Post by avasylev »

colmmacc wrote: post #28
rocqua wrote: post #26

Earlier quoted context omitted.

I agree that switches shouldn't care about TCP or UDP ports. That is a job for a firewall. However, that does not mean it is a good idea to have variable length headers in IPv6. In fact it seems like a singularly bad idea to me. Regarding firewalls, I imagine it still sucks a firewall cannot judge each IP-packet separately but needs to deal with possible fragmented packets. Then again, that is the cost of being a fir…

Switches use L4 ports to implement flow-switching. When multiple paths for a packet are available, it is convenient (it leads to less re-ordering) if the related packets from the same flow all choose the same path.

It's not just convenience for anycast addresses, with multiple pathes and anycast if your round robin packets across different routes, you may end up receiving them in two different locations (ok for UDP, but TCP broken completely). Anycast is widely deployed now and imho ECMP support is now considered "standard". I'm not sure what are other alternative solution to ECMP that don't require looking into TCP headers.
Post reply on HN