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