[153282] in North American Network Operators' Group
Re: IPv6 day and tunnels
daemon@ATHENA.MIT.EDU (Masataka Ohta)
Mon Jun 4 15:07:45 2012
Date: Tue, 05 Jun 2012 04:05:55 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
To: nanog@nanog.org
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65D374A8312@XCH-NW-01V.nw.nos.boeing.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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@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
>
>
>
