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

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 28 February 2020 00:27 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007263A0A11; Thu, 27 Feb 2020 16:27:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Level:
X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKWBHH0Reg6i; Thu, 27 Feb 2020 16:27:54 -0800 (PST)
Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF73B3A0A12; Thu, 27 Feb 2020 16:27:54 -0800 (PST)
Received: by mail-ot1-f53.google.com with SMTP id r16so1047684otd.2; Thu, 27 Feb 2020 16:27:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I7EJiQgN10DRsEZihzbK4/8wIKUvJXpq/NcQY7yOPm8=; b=ilGsEGNLmJymyY4hJGUi0R1Iapy02svY+z0sJaYYVGRQjw90nO4KEz86Rq2KBcpI6R csn0vRNCJETIV9T7IVlMCdBLO4MaCI66NMwuxME8JhJq80d2IA4JRfN1bwTRLxEiZL39 UltU/Lbvvl6WhiWHkewU45VM4oeueMMzkqRYNJBRyWtDsgLL/4iI1tatSLDkbF4YtxRC ZY8LRoFI41gUTnUOZfYjYNvVS5Ce7w8iiAPzYQzhX8uiaf1JdrRvdU1PdggNdFA8kZXs lJyo9h2fuoPEaeAqmPg+lCcDkQ3mcxtaeI5+y76O3noVoA1tcqFs0ziohEtVMJxhbtYF uYEg==
X-Gm-Message-State: APjAAAX1AtpFEeLBjmJ44kFbdrPGajaX2v/haL0qL+XZNJ7zMaqyxbt+ tFTz5jzIMkEWZ/HN4j1qwbK/r9B4u1eQTEPqOks=
X-Google-Smtp-Source: APXvYqy94Szh5ibyPFdBR0boturKsH4XJ2TOQFFt+ethUyiquKeIaR82xdYUA+SzeUF0P25nx1T2Gwa1OaJGFzE1ouU=
X-Received: by 2002:a05:6830:154a:: with SMTP id l10mr1276285otp.44.1582849673998; Thu, 27 Feb 2020 16:27:53 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> <CALx6S36wN7VEi_rxLC1ETcTvkGaPhs20KhQrGWAGGTrCL5OT+g@mail.gmail.com> <CAMm+Lwg+4xMv=EKLfvmZMCgrQz31+38Fv0bYKeJ0fTB5vbXiaw@mail.gmail.com> <CALx6S36QNm4fjWMefCr2qOPvm3QwnFmj__Sqdu3NrDMNepXYQg@mail.gmail.com>
In-Reply-To: <CALx6S36QNm4fjWMefCr2qOPvm3QwnFmj__Sqdu3NrDMNepXYQg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 27 Feb 2020 19:27:41 -0500
Message-ID: <CAMm+LwhMxUBZ-OUHVX5JgYWYbdj-fzhkqPa310uvEkBfNk3LLA@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Fernando Gont <fgont@si6networks.com>, architecture-discuss@iab.org, Internet Architecture Board <iab@iab.org>, Internet Area <int-area@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008d348d059f97e816"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/DRg5V2op90qA24CcYWOc2VL6Mjc>
Subject: Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 00:27:56 -0000

On Thu, Feb 27, 2020 at 5:44 PM Tom Herbert <tom@herbertland.com> wrote:

>
>
> On Thu, Feb 27, 2020, 2:26 PM Phillip Hallam-Baker <phill@hallambaker.com>
> wrote:
>
>> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert <tom@herbertland.com> 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.