IPv6 day and tunnels

Masataka Ohta mohta at necom830.hpcl.titech.ac.jp
Mon Jun 4 19:05:55 UTC 2012


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?

Note that, with your draft, a route change between two
tunnels with same C may cause block corruption.

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

> 
>> (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.templin at 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
> 
> 
> 





More information about the NANOG mailing list