Re: IPv6 day and tunnels

[Masataka Ohta <mohta () necom830 hpcl titech ac jp>]

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