Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

[Christian Huitema <[e-mail]>]

Fernando,

Your original question was "is IPv6 end to end".

For me, the practical test of end to end is, can it be encrypted? A
message is end-to-end if it can be sent from end point A to endpoint B
using encryption services so that it cannot be modified in transit, only
the intended destination can receive it, and that destination can verify
that it came from the specified origin. Under that definition, Quic or
TLS are end to end. UDP, TCP, IPv4 and IPv6 on which they are built, not
so much.

This may be a cynical point of view, but it matches what Bernard Aboba
mentions in his description of "tussle space". Experience shows that if
intermediaries gain benefits in messing around with data in transit,
they will. The IETF may send them RFC copies in triplicate, but that
won't stop them. In the absence of encryption, the only reason it is a
tussle and not a free for all is the fear of breaking existing
applications. The network operators will not deploy a middle-box that
breaks important services, because disruption will make them lose
customers or otherwise incur costs. Standards are helpful there, because
they constrain the players to remain within a plausible envelope. But
the strength of standards comes from their adoption, not from the ink on
the paper. For standards that are widely adopted and followed, the
players that try to deploy breakage will experience customer feedback
and lose their end of the tussle. But standards that have limited
adoption will not have that power.

You are mentioning segment routing variants. For me, they fall very much
in this tussle category. Network equipment makers believe that this
technology will make the network better in some ways -- maybe faster, or
maybe easier to manage. It is definitely a departure from Steve
Deering's IPv6 vision of a simple network happily forwarding IPv6
datagrams. But as long as the network provider maintains an end to end
IPv6 service, there probably won't be that much customer backlash. The
tussle will play elsewhere, for example if network providers try to move
from changing the implementation of the service to changing its
definition. We have seen that in the past with attempts at QoS
deployment that looked like trying to tax specific applications. Those
were rejected because the entire ecosystem believed that "a bit is a
bit". But of course, some players are going to try again.

-- Christian Huitema