> -----Original Message----- > From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] > Sent: Monday, June 04, 2012 12:06 PM > To: nanog@nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > > Also, when > > IPv4 is used as the outer encapsulation layer, the 16-bit ID > > field can result in reassembly errors at high data rates > > [RFC4963]. > > As your proposal, too, gives up to have unique IDs, does that > matter?
This is taken care of by rate limiting at the tunnel ingress. For IPv4-in-(foo) tunnels, rate limit is 11Mbps which may be a bit limiting for some applications. For IPv6-in-(foo) tunnels, rate limit is 733Gbps which should be acceptable for most applications. > 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 (src,dst) pair. 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. 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. > > Additionally, encapsulating a 1500 inner packet in > > an outer IP header results in a 1500+ outer packet - and the > > ingress has no way of knowing whether the egress is capable > > of reassembling larger than 1500. > > Operators are responsible to have tunnel end points with > sufficient capabilities. 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! Thanks - Fred fred.l.temp...@boeing.com > >> (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte > >> MTU on the tunnel, fragment the outer packet, let the other end of the > >> tunnel do the reassembly. Not providing 1500 byte end-to-end (at least > >> with in the network I control) for IPv4 has proven to consume lots of > >> troubleshooting time; fragmenting the inner packet doesn't work unless > >> you ignore the DF bit that is typically set by TCP endpoints who want > >> to do PMTU discovery.) > > > > Ignoring the (explicit) DF bit for IPv4 and ignoring the > > (implicit) DF bit for IPv6 is what I am suggesting. > > > > Thanks - Fred > > fred.l.temp...@boeing.com > > > >>> I presume no one here would object to clauses 1) and 2). > >>> Clause 3) is obviously a bit more controversial - but, > >>> what harm would it cause from an operational standpoint? > >> > >> -- Brett > > > > > > >
