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 not 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.

I received a comment soon after I posted this article, which I thought would provide some further insight to the WCIT process, so here is the comment and some further thoughts on the topic.

The comment was in the form of a report from a preparatory meeting for WCIT that evidently there is a mood within certain parts of the ITR drafting process to simply say: “The ITRs should apply to the Internet in full, because the Internet is nothing more than a telecom service and should be treated that way.”

In one sense its true that the Internet is nothing more than a telecommunications service, but in the same way that the post, radio, television, and of course the telephone are also all just telecommunications services. But the nature of the particular service has many consequences, and the attempt to lump telephony and the Internet into the same form of regulatory handling is at best a somewhat misguided effort.

I truly wonder if, more than a century ago, the counterparts of today’s government delegates, in a meeting of that august body, the Universal Postal Union, would’ve argued that a telephone conversation was just an exchange of letters without the artifice of paper, and that the telephone was indeed just a part of the postal service, because its just “a communications service.” Indeed I’m pretty sure their counterparts did precisely that and for the next 80 years or more in many countries the Postmaster General operated the telephone service, and operated the wireless spectrum administration and regulated radio and television broadcasts, as well as operating the national postal service, the telegraph service and telex services, all because “its all just communications.”

But, ultimately we changed all this. We created distinct entities to administer different communications media and services because its actually not all just communications and its not all just telecoms, and effective regulatory handling of these different communications mechanisms, using distinct forms of investment and finances, and at times entirely distinct regulatory frameworks and often distinct organisations and associated participatory arrangements allows us to realise the true potential of these various services and do so efficiently and effectively. This recognition of a need for distinction in the regulatory frameworks for various services avoids the unfortunate situation of the stultifying dead hand of history misapplying one form of regulation on an entirely distinct and very different medium.

I suspect the best thing the postal folk, in the form of the UPU, ever did was to tell the telephone folk “hail and farewell” and let them get on with their role using an organisation specifically designed to meet their collective needs in supporting telephony.

It may be well and truly time for the telephone folk, in the form of the ITU, to come to a similar arrangement in its dealings with the Internet!

I am all for beginning with the end in mind and building a comprehensive solution from day one. It will take time to roll any solution out to a majority of homes and thus should last once there (we’ve been on the current model of Modem-CPE-LAN for approaching 20 years now). So if site-multihoming will become common in that time frame, it should be included. I am just not sure that the average, 80%, home user is really going to adopt a dual-ISP approach, given the complication and cost involved.

~Chris

This is because what I have perceived from the concept of RBridge is that a new a device, indeed it is, with the features of Layer-2 (framing) and Layer-3 (routing) being merged, and if these devices replace the existing switches (the newer one i.e. L2 and L3) with the RBrigdge WHAT WILL HAPPEN TO A ROUTING AND SWITCHING ENGINEER?

Can some tell me the differences between using GMPLS and MPLS-TP? All the functionalities done by GMPLS-TP can be done by GMPLS also? Please highlight key differences..

(There are already equipmet vendors like Ciena, Nortel who already have transport products using OTN/SONET/SDH/potonics using GMPLS)

Please connect the big picture.