Re: End-to-end (was Re: Non-Last Small IPv6 Fragments)

[Tom Herbert <[e-mail]>]

On Tue, Jan 15, 2019 at 1:15 PM Christian Huitema <[e-mail]> wrote:
>
> On 1/14/2019 11:20 AM, Nick Hilliard wrote:
>
> Brian E Carpenter wrote on 14/01/2019 19:47:
>
> On 2019-01-15 07:47, Nick Hilliard wrote:
>
> End-to-end died the day the IETF published rfc1631.
>
>
> The IETF didn't publish RFC1631. The RFC Editor published it. Although
> the Independent Submissions stream hadn't been formally named at that
> time, that's what this was.
>
>
> several people commented on this privately. The point I was trying to make to Bjoern was that the end-to-end principal ended a long time ago - certainly more than the 25 years ago that this rfc was published.  The large address space of IPv6 will not make it return.
>
> Actually, the pendulum went from "everything end-to-end" to "lots of processing in the middle", and it is now swinging back. Developers have realized that if they want to keep a particular function "end-to-end", they should use encryption. For example, using HTTPS instead of HTTP prevents intermediaries from messing with the content of the pages. Using QUIC instead of TCP prevents intermediaries from messing with the transport headers.
>
> Of course, the IP header itself is not encrypted, so encryption does not prevent NAT. That's why encrypted transports run over UDP. A side-effect of that is that UDP does expose the L4 ports, which sort of meets the requirement of intermediaries that run packet classifiers.
>
> PMTU discovery finds itself at the border between the clear text IPv6 header and the encrypted transports. It is sort of solved by declining to use fragmentation, and sending end-to-end encrypted probes to reliably discover the current PMTU. If an encrypted message of length end arrives to the other end and is acknowledged, the peers know that the PMTU is at least L.
>
> End to end PMTU probing is not perfect. It requires sacrificial probes, which has some overhead. It also requires guesswork to discover when a PMTU decreases. This is an area that would benefit from some innovation. For example, instead of requiring fragmentation support, it might be tempting to use truncation, so the truncated packet arrives to the other end. Of course, supporting truncation would require changes in routers and changes in the way transports deploy encryption. But that's probably the best long term way to solve the issues with fragmentation and reassembly.
>
Christian,

The only thing worse than intermediate nodes inspecting packets in
non-standard ways is when they modify packets in non-standard ways. A
better approach might be draft-hinden-6man-mtu-option where the
application can probe the path with small packets before sending big
packets. This uses a modifiable HBH options and is completely
idependent of the transport layer.

Tom

> -- Christian Huitema
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------