At the recent ARIN XXX meeting in October 2012 I listened to a debate on a policy proposal concerning the reservation of a pool of IPv4 addresses to address critical infrastructure. The term "critical infrastructure" is intended to cover a variety of applications, including use by public Internet Exchanges and authoritative name servers for various top level domains. As far as I can tell, the assumptions behind this policy proposal includes the assumption that a top level authoritative name server will need to use IPv4 for the foreseeable future, so that an explicit reserved pool of these IPv4 addresses needs to be maintained for use by the authoritative name servers for these domain names.
Comments 1
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Geoff Huston •
Nothing is ever what it seems to be! Those strange ICMP6 packet too big messages that I thought were in response to a large TCP packet - well they weren't being generated by the TCP packet. I had thought that if my authoritative nameserver was sending out packets no larger than 1280 octets in UDP then any incoming ICMP6 Packet Too Big message could not be received from a UDP packet whose size was no larger than the minimum MTU defined in IPv6. After all IPv6 routers need to be able to carry without fragmentation a packet whose size is 1280 octets. But I was wrong. Alexander Gall kindly pointed out to me that if a certain vendor's firewall product was lagging from the current version of the vendor's software, then the firewall could indeed perform this feat and generate these strange ICMP6 packet too big messages in response to small-sized UDP packets! There is a sort-of-logical explanation of why the firewall is nominating a 1500 octet MTU as well. The firewall software evidently had a DNS ALG "feature". When this feature was turned on the firewall performed a reassembly of the UDP fragments of the DNS response. It then applied the firewall filter rules against the reassembled packet to see if the DNS response was acceptable. Now if the firewall decided that the DNS response was to be allowed through, it appears that it did not pass through the original UDP fragments of the DNS response, but attempted to pass through the reassembled UDP over IPV6 packet. At this point the forwarding engine could cope with this artificially large packet, and it performed a conventional IPv6 handling of a large packet: generating an ICMP6 packet too big message back to the sender and discarding the packet. And because the link uses a 1500 MTU, then it dutifully placed the value 1500 into the ICMP6 message. Now the resolver behind this oh-so-helpful firewall now sees no response whatsoever, and after a number of repeated queries it might time out and try TCP. But this time when the TCP response is sent back it generates no ICMP6 packet too big messages. In this case the authoritative nameserver sends the two TCP packets that carry the DNS response back to back, where the first packet is a full-size 1500 octet packet. But this large DNS response does not generate an ICMP6 packet too big response. Apparently the firewall has managed to do the correct thing in this case and forward on the TCP packets as received if it accepts the DNS response. So if you are the lucky owner of one of these firewalls, then perhaps you should look at the vendor's bug list and software versions and check if the version of SRX software you are running has had this bug in the IPv6 part of the DNS ALG "feature" corrected.