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

[Tom Herbert <[e-mail]>]

On Thu, Feb 27, 2020, 4:27 PM Phillip Hallam-Baker <[e-mail]>
wrote:

>
>
> On Thu, Feb 27, 2020 at 5:44 PM Tom Herbert <[e-mail]> wrote:
>
>>
>>
>> On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker <[e-mail]>
>> wrote:
>>
>>> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert <[e-mail]> wrote:
>>>
>>>> Fernando,
>>>>
>>>> I think we need to be careful that IETF is labeled as a collection of
>>>> inflexible architectural purists. We know that standards conformance
>>>> is voluntary and we haven't seen the last time that someone, possibly
>>>> even a major vendor, will circumvent the system for their own
>>>> purposes.
>>>>
>>>
>>> IP end to end does not mean the IP address is constant end to end. It
>>> never has meant that and never will. An IP address is merely a piece of
>>> data that allows a packet to reach its destination. There is no reason to
>>> insist on it remaining constant along the path.
>>>
>>> The sooner people get over that fact the better.
>>>
>>> If an IPv4 device interacts with an IPv6 device, there will be address
>>> translation going on somewhere along the path. That is inevitable.
>>>
>>> We discovered that there were good reasons for NATing IPv4 besides
>>> address multiplexing. The topology of my network is none of your business.
>>>
>>> More generally, Internet standards only apply to the Inter-net, the
>>> network of networks. What happens inside the networks at either end is for
>>> the owners of those networks to decide. If we go back to the original
>>> Internet design, they didn't even need to run IP. IP end to end come later.
>>>
>>> So let us stop being dogmatic about things that don't actually matter.
>>> The only job of the network layer is to get packets from one end to
>>> another. The only job of the transport layer is to provide reliable
>>> streams. An application protocol that depends on the IP address remaining
>>> constant end to end is a bad protocol and should be rejected.
>>>
>>
>> So Authentication Header and any other sort of Inetwork layer
>> authentication are bad protocols that should be rejected?
>>
>
> The IPSEC authentication header is a complete failure of design. It is the
> reason IPSEC doesn't work in the real world and has been replaced by SSH.
>
> Stuff that doesn't work in the real world is just bad and should be
> rejected. I remember the security ADs of the time smirking as they said
> IPSEC not working with NAT represented a feature, not a bug. They were
> wrong then and you are wrong now.
>
Thanks for your opinion, but I see nothing of relevance here that is worth
a reply.


>