Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

Robert Raszuk <robert@raszuk.net> Wed, 11 December 2019 00:54 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E23120219 for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 16:54:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 bmoIHcZYPIqD for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 16:54:03 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 DE63512008C for <spring@ietf.org>; Tue, 10 Dec 2019 16:54:02 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id w47so4697432qtk.4 for <spring@ietf.org>; Tue, 10 Dec 2019 16:54:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jux0n1il3knLwRVc9WoQn4vtE7pM8yBOef2CaPg5HdU=; b=Rs4miCGOStO9goQ8dUWHjjTbU8dhUVdQRA4tuYv3dujcfh5Qqa4QdLUPtukkuwGlbH r/nMU4ngyv1MAqtooZSufp3INqzJP01DYRcMmqTlw4dCg4kEZKkHrYy7/S+YVfTyRe8Q QeLFddG9wixXPvmTfDlST2OUlqh62CaiLcRnLtCte0INlv4LeP/WUY9iBnnUDHy0FSSK kpcqjzqhD+fzk7KEnM2Jr2U/ijHs7mZlo6BWKKWATvtafxB8wJxhhdM/0+wnr8sXfJnA a498DeUTvoM2q4RPnvkvl3iTSTkIXZhzBm7IUknWKfU2IFxfiQMQYDBjTSTlfBcEtq5y jqzQ==
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=jux0n1il3knLwRVc9WoQn4vtE7pM8yBOef2CaPg5HdU=; b=jwLRCsI/94G/bM7mmGfjRhphCYGqgoBva1XC2YbgEsT9OPDkTLtFItHTxQz9ZC7S5V yLXDwmQLIshkUwSemgGL9ii+Xf4tycdnqeEiFZZLrmLfa9fSBkQeCbvYdaZMP2RBpZtf ntpGFsDJ4tqRefbNT9Hy5KVcePkAXqLv3vv4NQL5o8UuaTc7dzsGLYfhPT48ffPnF36j UXrL2adF40pB9wY131rfA9x37LyU9TvoQ3PnG8VcpvNtoExzaWP23txLmCrMN3VjiWvX gfdAT2Y1miQx3FDYIw/Zr2TRZXzi4lgdvuHukRglHgtec4z3ga0GvYYHmfqJq5osPkVq dHWg==
X-Gm-Message-State: APjAAAVuZBfGi6lYlUrLwDh3f6oJxs600ZatwbDaP6w1J/elXrF8v6zo EvypmcgpWuiNqFv9jBlcfshJSTKlS96qCVCx2QOS3A==
X-Google-Smtp-Source: APXvYqzbuwetzjNu6ULLzsd1yrig7+YipH47NwaGDbFBzGN9t6nAIQoDNPQ/BWnO2WFUkrHo4mamSUK+kzMUxU3e3x0=
X-Received: by 2002:ac8:5245:: with SMTP id y5mr619066qtn.343.1576025641942; Tue, 10 Dec 2019 16:54:01 -0800 (PST)
MIME-Version: 1.0
References: <f2a0ad13-0eba-6f5a-1d3c-e45e2780f201@si6networks.com> <D666EA6E-E8E9-439A-9CDE-20857F03CB65@employees.org> <4255AD3B-379C-45BF-96E1-D3D9141A684F@liquidtelecom.com> <d59de54e-c7f8-be67-1e77-b051735d40a6@gmail.com> <3bce7b18-ea45-d29f-5dfb-1d3258b07d1e@si6networks.com> <c6e1f690-b0bf-9f45-8fa7-92ed182c5b04@gmail.com> <a2cc5cbd-ac06-e193-307c-3ffe5b21b0b1@si6networks.com> <80A78F48-9802-4DA9-B264-1A8920C1DDF9@kaloom.com> <c727fb5e-015d-90e2-9860-6c48ce021ac4@si6networks.com> <CAOj+MMEyMDHULL7Pr=QmucTJy9b=3ph9TgTZ7koi9BBLkFCJ6g@mail.gmail.com> <bb767aff-8737-a749-2f99-ac350f66def5@si6networks.com> <CAOj+MMEjzxrEbmKbUn11EsTSnVOZC0cKZhAeXapV2vW++g0ZdA@mail.gmail.com> <885c9ad6-ddd2-392a-7e9f-722509753e2d@si6networks.com> <27448_1575983799_5DEF9AB7_27448_30_1_53C29892C857584299CBF5D05346208A48D245CD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <5b0f37d2-56a3-5f7f-ab29-7d6ebc2367d5@si6networks.com> <CAOj+MMHoAap_7XZs5HSO+a1C18guFzkg1fkov8Wo6ZqHj=xeHQ@mail.gmail.com> <CAO42Z2zu7YC6gY3-Uin=5KsdG0=Zc8rPwbPHekKu4t=s7duNZQ@mail.gmail.com>
In-Reply-To: <CAO42Z2zu7YC6gY3-Uin=5KsdG0=Zc8rPwbPHekKu4t=s7duNZQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 11 Dec 2019 01:53:50 +0100
Message-ID: <CAOj+MMEawGamUPaY=AMAk3n1k1Rviva1jh2f8MMJ=AckEQOywA@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, rtg-ads <rtg-ads@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Suresh Krishnan <Suresh@kaloom.com>, Bruno Decraene <bruno.decraene@orange.com>, Ole Troan <otroan@employees.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008b973e05996310ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/wm4m_37wNrJ1wlRYbiotuoaeRuY>
Subject: Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2019 00:54:04 -0000

> I would have to question your understanding of the term "end to end"
> if you're make such an assertion.
>

My description of end to end purity of IPv6 is based on Fernando's
comments. In his view if packet gets encapsulated with an arbitrary header
and if that header changes hop by hop end to end property of IPv6 is
violated.

NAT breaks end-to-end.
>

Of course ... and I would agree with that. But if so this entire discussion
of quote "violation of Internet Standard" just because outer header changes
is pure waist of time.

And I think it would be best for those from 6man who understand what IPv6
end to end is to chim in and comment on such emails like we have seen
earlier today.

Many thx,
R.