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

[Mark Smith <[e-mail]>]

On 30 March 2016 at 02:43, Joe Touch <[e-mail]> wrote:
>
>
> 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).
>

Yes.



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

I agree that encapsulation/tunnelling is performing that function. I'm
observing that when tunnelling occurs an additional source address
field is added that records the identity of the device that added the
tunnelling encapsulation. That address and the tunnelling protocol
creates a very clear boundary between what the original host sent and
what has been added and by whom during tunnelling/encapsulation.

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

So when packets are modified while they travel through the network,
the identity of the modifier isn't recorded, which makes
troubleshooting harder if the modifications fail. So my philosophy is
that packet modification in the network should be minimised as much as
possible, even though some fields are mutable because they're not
covered by e.g, TCP or UDP pseudoheader checksums.

That really only leaves the hop count field as one that is always
going to be modified. I think Flow label and TC are the other two that
are mutable. In the case of flow label, there are fairly strict rules
on when they can be modified by the network (if FL=0). TC has no
strict rules, however within in a network the devices that may modify
TC are usually limited to the edge and are well known as performing
that role, making them easier to identify if they're broken.


Regards,
Mark.




> Joe