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
