-----Original Message----- From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] Sent: Monday, June 04, 2012 1:08 PM To: Templin, Fred L; nanog@nanog.org Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
As your proposal, too, gives up to have unique IDs, does that matter?
This is taken care of by rate limiting at the tunnel
No, I'm talking about:
Note that a possible conflict exists when IP fragmentation has already been performed by a source host before the fragments arrive at the tunnel ingress.
Note that, with your draft, a route change between two tunnels with same C may cause block corruption.
There are several built-in mitigations for this. First, the tunnel ingress does not assign Identification values sequentially but rather "skips around" to avoid synchronizing with some other node that is sending fragments to the same
I'm talking about two tunnels with same "skip" value.
There are several factors to consider. First, each tunnel ingress chooses its initial Identification value (or values) randomly and independent of all other tunnel ingresses. Secondly, the packet arrival rates at the various tunnel ingresses are completely independent and in no way correlated. So, while an occasional reassembly collision is possible the 32-bit Identification value would make it extremely rare. And the variability of packet arrivals between the tunnel endpoints would make it such that a string of consecutive collisions would never happen. So, I'm not sure that a randomly-chosen "skip" value is even necessary.
Secondly, the ingress chooses random fragment sizes for the A and B portions of the packet so that the A portion of packet 1 does not match up properly with the B portion of packet 2 and hence will be dropped.
You can do so with outer fragment, too. Moreover, it does not have to be random but regular, which effectively extend ID length.
Outer fragmentation cooks the tunnel egresses at high data rates. End systems are expected and required to reassemble on their own behalf.
Finally, even if the A portion of packet 1 somehow matches up with the B portion of packet 2 the Internet checksum provides an additional line of defense.
Thus, don't insist on having unique IDs so much.
Non-overlapping fragments are disallowed for IPv6, but I think are still allowed for IPv4. So, IPv4 still needs the unique IDs by virtue of rate limiting.
It is recommended that IPv4 nodes be able to reassemble as much as their connected interface MTUs. In the vast majority of cases that means that the nodes should be able to reassemble 1500. But, there is no assurance of anything more!
I'm talking about not protocol recommendation but proper operation.
I don't see any operational guidance recommending the tunnel ingress to configure an MRU of 1520 or larger. Thanks - Fred fred.l.templin@boeing.com
Masataka Ohta