IETF Logo Mail Archive

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

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

Return-Path: <hallam@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09A03A0C86; Fri, 28 Feb 2020 09:20:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 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_H2=-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 U_D2XaTpiJeh; Fri, 28 Feb 2020 09:20:01 -0800 (PST)
Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) (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 220653A0C8C; Fri, 28 Feb 2020 09:20:00 -0800 (PST)
Received: by mail-oi1-f194.google.com with SMTP id v19so3515969oic.12; Fri, 28 Feb 2020 09:20:00 -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=iuwyW1f4sqbHT0sThfnqfsz1WCiF++s6d9KzJrxFz+8=; b=uICVIq0EvQx1jRTobN0ZwZsUpRuI1CZvYydG7FwZEztV2vXp2bG0Pz56Rrq6mjtKpW F7huIxT9J/I7E5EshLQokNLTtOMCvORLMsW63XDPIMG2+lTOeEyCmpEqLDafBz/0LzT7 PiAQbkrjuFvH2cjbrTd77aL0H1JUVxKxFabFXxy9NZ22S7p2UFeHp1bZOYhi8DYu/QTO Kl+WmeHJ3Gab8lX5OSRR1SRKqagVYpgFHIYoj8QOjYnAEKexqApzHNIVl7jLwHlqtX82 yQtb74+XnNbQAdEKawDEG91ArE3S8TplfY62wMH8llNL7PlXEiGO1beQXLSAVy/9XfXb rzXg==
X-Gm-Message-State: APjAAAUYqlqd/l4t+9P/TqeK6ihjAUjOQU6pWO1Jy38gugbtxVcgDVd7 fIDLRBa94mqnTG3ONLNtrbESdtwa3R2fyB4/u7c=
X-Google-Smtp-Source: APXvYqzwEHmtvgzLQ4IRxwPqbzymspYHZ500XIjbARL+3aopqT1KD4JXhARpBj59QcXWzv57WVIcjFN1B6e74tODmm4=
X-Received: by 2002:a05:6808:45:: with SMTP id v5mr3776515oic.90.1582910399679; Fri, 28 Feb 2020 09:19:59 -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> <8d3e7b714666db00e0c05a2e06959da6@strayalpha.com> <CAMm+LwjYeSTro_TJujtRPDfVKtVMg7JbDL6A5V3Tj447c2E7nA@mail.gmail.com> <74763844-FA56-43DC-981E-E366E2C24758@strayalpha.com> <CAMm+LwjeWXUmOEzvbUhrG1H8OMqG9EhcF3TzdZBA61LnySSPqw@mail.gmail.com> <CALx6S35ko4zfCWwtR+LTKR6NdH86pVx7E-JoF0Cf4RVZOSJtkA@mail.gmail.com>
In-Reply-To: <CALx6S35ko4zfCWwtR+LTKR6NdH86pVx7E-JoF0Cf4RVZOSJtkA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 28 Feb 2020 12:19:48 -0500
Message-ID: <CAMm+LwjxxTQmJMPxydMGC5GByHu2qkbd_+W1and=xOMhq2RV6g@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Joseph Touch <touch@strayalpha.com>, Internet Architecture Board <iab@iab.org>, architecture-discuss@iab.org, Internet Area <int-area@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001595dc059fa60cb0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/9b2p7orlngYkj72gWS8MBweX1J8>
Subject: Re: [Int-area] [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 17:20:07 -0000

On Fri, Feb 28, 2020 at 11:14 AM Tom Herbert <tom@herbertland.com> wrote:

> On Fri, Feb 28, 2020 at 5:32 AM Phillip Hallam-Baker
> <phill@hallambaker.com> wrote:
> >
> >
> >
> > On Thu, Feb 27, 2020 at 11:36 PM Joseph Touch <touch@strayalpha.com>
> wrote:
> >>
> >>
> >>
> >> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker <
> phill@hallambaker.com> wrote:
> >>
> >>> IP end to end does not mean the IP address is constant end to end. It
> never has meant that and never will.
> >>>
> >>>
> >>> Actually, that's the only thing it ever meant and always will. When
> addresses change, *by definition*, the*ends* change (and yes, that's what
> NATs do - they create end-to-end CONTENT transfer over separate end-to-end
> Internets).
> >>
> >>
> >> By whose definition? Not by mine.
> >>
> >>
> >> I’d start with RFCs 791 and 1122, but there’s also the pseudo header in
> RFC 793, to be very specific.
> >>
> >> TCP and TLS give me a reliable end-to-end stream. The fact that the IP
> address is exposed is merely an unfortunate defect in the legacy APIs.
> >>
> >> As the application layer designer, I am the customer here. I do not
> care about the IP address.
> >>
> >>
> >> Hmmm. By what value do you call  TCP endpoint?
> >>
> >> You must have magic sockets that don’t actually refer to IP addresses.
> >
> >
> > I have a library that implements RFC6763. So my application code doesn't
> actually consider IP addresses.
> >
> It's great that _you_ have a solution, but not everyone does. The
> standard says that a TCP connection endpoint is defined by a 4-tuple
> of source address, destination address, source port, destination port.
> It is an invariant that we have forty years of operational experience
> with. If you think that design decision is obsolete or should be
> revisited, then by all means propose an alternative in tsvwg.
>
> Tom
>

That is a TCP connection. Applications don't deal in TCP connections, they
deal in sockets.

Its called abstraction. All that complexity belongs in a box that the
application programmer doesn't need to open.

Now current practice is that people use the gethostbyname() call to do DNS
resolution and so they end up being unable to make use of DNS properly. But
that is a problem with the 40 year old legacy API which can be changed or
circumvented entirely

RFC6763 is what the application layer should use.

v2.23.0 | Report a Bug | By Email