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

[Joe Touch <[e-mail]>]

On 3/29/2016 2:37 AM, Mark Smith wrote:
> 
> On 29 Mar 2016 7:31 PM, <[e-mail]
> <mailto:[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.

I presume then that you're then arguing that NATs shouldn't exist? (I'd
be glad if that were the case, but it's clear it's not).

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

Yes, but encapsulation performs a very similar function. That's why we
try very hard to avoid cross-layer dependencies (though the idea of a
pseudoheader in the checksum of transports breaks this) and why
intermediate devices shouldn't be peeking past layer 3.

So again, I'm interested to see this perspective on the "sanctity of the
header chain" when nearly every other presumably "immutable" field of
the header has been the subject of modification.

Joe