Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

[Mark Smith <[e-mail]>]

On 29 Mar 2016 8:51 PM, <[e-mail]> wrote:
>
> > > >> Yes. It's a bug in RFC2460 that this ambiguity arises.
> > > >
> > > > I took it as a feature. IMO, the idea of a chain enables this
feature,
> > > > and I don't think it should be so quickly dismissed as potentially
useful.
> > > >
> > > > I appreciate that not everyone agrees, though.
> > >
> > > It does break PMTUD though.
> > >
> >
> > Which I think is because of an expectation that the device identified
in the packet source address (the "sender") is responsible for creating the
whole packet. It can't be a "unicast source address" field if there are
multiple sources of the information in the packet.
> >
> > It also breaks troubleshooting methods and assumptions about the source
address field that have been true for IPv6, IPv4 and many, if not all, past
layer 3 protocols.
> >
> > One perspective on tunneling is that when it modifies the packet, it
adds another source address field to record that another device,  other
than the original packet source device, has made additions to the packet.
>
> indeed, and is why 2460 bis states:
>    "Extension headers must never be inserted by any node other than the
>    source of the packet.  IP Encapsulation must be used to meet any
>    requirement for inserting headers, for example, as defined in
>    [RFC2473]."
>

I suppose given Joe's example experimental RFC, 2460bis should also be
explicit about EHs not being able to be deleted on the trip too.

Regards,
Mark.

> cheers,
> Ole