Re: Tussles in IPv6 Land

[Lee Howard <[e-mail]>]

On 6/13/17, 6:50 AM, "ipv6 on behalf of Mark Smith" <[e-mail]
on behalf of [e-mail]> wrote:

>On 10 June 2017 at 11:33, Brian E Carpenter <[e-mail]>
>wrote:
>> Hi,
>>
>>That's because inserting stuff (any stuff, not just this header)
>> in a packet changes its length and thereby breaks all known methods of
>>determining
>> the maximum packet size allowed on a given path across the Internet.
>>
>
>I think it is more significant than that.
>
>It's
>
>(A) ignoring statements in a very widely implemented and deployed
>protocol specification that has existed for more than 20 years.
>RFC1883 contains the text about not processing EHs in the network.
>
>(B) ignoring the interoperability goal of protocol specifications,
>meaning that new implementations' features interoperate with existing
>implementations without significantly impacting their operation.
>Inserting EHs contradicts Postel's "Be conservative with what you
>send" because existing implementations aren't expecting in-flight
>inserted EHs, and that is because that action is not specified as a
>possibility in RFC2460.

If you only insert and process EHs inside your network, then you can
reasonably assume that they are expected. Strip EHs at your borders and
everyone’s happy.

>
>(C) ignoring the fundamental and foundation principles of layers and
>encapsulation/de-encapsulation to add or remove information to
>existing protocol data units

You think?
Is routing information the same layer as the network layer, or higher or
lower? Adding headers outside the IP headers seems to me to preserve the
spirit of layering.
An alternative would be to formalize a path layer, using MPLS as one model.

>
>(D) ignoring the operational consequences of making protocols and
>devices harder to troubleshoot and rectify because it breaks source
>address field semantics while the inserted EH is present.

Yet operators are doing this now. Sounds like a tussle.

> Despite
>theoretical claims, in practice the inserted EH may not be removed at
>the edge of the insertion domain because of device misconfiguration,
>implementation bugs or partial device failures, so troubleshooting may
>be occurring outside of the domain that inserted the EH. The operator
>who decided to insert the EH may not be the operator dealing with its
>consequences and having to troubleshoot and rectify it.

Yes, that could be a problem. Do we have a documented BCP to drop packets
with unexpected EH outbound and inbound? *IS* that the BCP?

>
>
>If we believe network operator's needs are the most important, we'll
>have forgotten who network operators exist to serve and more broadly,
>who IPv6, the IETF and the Internet exists to serve.

To summarize a point I made yesterday:
The network serves whoever pays for the network. Not all networks are for
individual consumers.

Lee