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

[Christian Huitema <[e-mail]>]

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 Huitema