Re: Network Programming - Penultimate Segment Popping

Tom Herbert <tom@herbertland.com> Sat, 07 December 2019 16:26 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3311207FF for <ipv6@ietfa.amsl.com>; Sat, 7 Dec 2019 08:26:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 uDpmxFTSL5Uo for <ipv6@ietfa.amsl.com>; Sat, 7 Dec 2019 08:26:42 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 10F5F1200C5 for <6man@ietf.org>; Sat, 7 Dec 2019 08:26:42 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id v16so8625312edy.6 for <6man@ietf.org>; Sat, 07 Dec 2019 08:26:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mibFHzrwe3OxuuURRUrp9AkQ6XcDENjJhr0bYyh82ho=; b=qFWIKmdRMmcnAXUP88djYt2W5Ox9UJ+QgYvFtMUnayFdhf9dIHusHmg9reDv1yaXBj fQcONfWE3bruP7o/daOysrfOUnbt8tJYLPDULkFRhSM8/b3a5qui0GS+NU4vtzvj1bAu YEwiU+BCsB/xozfFrPw77/6e12DiYgufasY17rjWELaqcs7FBFvTZ6aLHLbO+NynqZXi WICG582gOD57rSn3/XqcehbbFV0G+iCAMtcOjqqqaXunKpyE3DlK5gNNqNUAJnYOdF0j oFCfVEz2bPaet40chYjj4fSiPz3MDDta3PirZGTCXTeHfcI02lm9gERbRftpPPruy+jR 3swQ==
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:content-transfer-encoding; bh=mibFHzrwe3OxuuURRUrp9AkQ6XcDENjJhr0bYyh82ho=; b=r8C9VCdA3sU01kBeI1XoF6IwOdvli3wMH29llU5Ui/jnZ2LrpxzZ9DeJUXJa3neFiS 0BX2UA2+Ix4+nq+aF+E6qpl9uKWdgym5VRqfLZNOZhOO7dSA3orhKALMf4UGzw3/HObD bm6rGxAg+u02xc3rqXlMwhuC1FrCkEz2PASv9HLknj48iDB5D6lXJl6M/1nBv7f630QU Jx9Tf1LaMC1GmzOv2cED/TDAxaTQmBpXEsP6CxCDDQNP8t0DCuToedfoOcK+brDoPzMy sjsBV/Zj6nqVfQQphD08ktc0kbSE6LJs3i0RaxOaRIe7qozfhqIkmsxisXSE+h07QbBE 09Zw==
X-Gm-Message-State: APjAAAW8XVnXE80OvtoplqMj27cWp/Fxs0BL22erK2wD0ppJ3qYzx+X4 sMLvtfSIn1UPxs8sxwmp9Qs4JNGF3X3y+POljc5EOw==
X-Google-Smtp-Source: APXvYqweMnUxVEPbaJ10PFlLm6axA4OGDwcazM3CBZomwMOeoZAamF4fP+aWRl/oSxDwZm0SoX/jEFvu2xcA9fxpwAs=
X-Received: by 2002:a17:906:a444:: with SMTP id cb4mr22258376ejb.42.1575736000415; Sat, 07 Dec 2019 08:26:40 -0800 (PST)
MIME-Version: 1.0
References: <BN7PR05MB56998A05469327E759B5B671AE5D0@BN7PR05MB5699.namprd05.prod.outlook.com> <3AD3BD11-8C34-41FE-B88F-49A9F2561D78@cisco.com> <BN7PR05MB569946D6AA5C6B78AFC05F6BAE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <D6B1AED6-0AB2-4394-9503-7A1885BC8B40@cisco.com> <BN7PR05MB5699C73EF0EE1F8E7A96C738AE5F0@BN7PR05MB5699.namprd05.prod.outlook.com> <7B7CFEB8-80F0-4690-9BE3-8D5F935E148A@cisco.com>
In-Reply-To: <7B7CFEB8-80F0-4690-9BE3-8D5F935E148A@cisco.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 07 Dec 2019 08:26:29 -0800
Message-ID: <CALx6S375sPG3jNybNbyA5eAUKTefGy_=LKBcmhfEhc5-B4e1OQ@mail.gmail.com>
Subject: Re: Network Programming - Penultimate Segment Popping
To: "Darren Dukes (ddukes)" <ddukes@cisco.com>
Cc: Ron Bonica <rbonica@juniper.net>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/9fOD5CAA6utAQ-Ke46dF_hY9Ouo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2019 16:26:44 -0000

On Sat, Dec 7, 2019 at 7:10 AM Darren Dukes (ddukes) <ddukes@cisco.com> wrote:
>
> Ron, you say
> >>  RFC 8200 addresses extension header insertion and deletion identically, in the same sentence.
>
> This sentence you refer to clearly permits PSP as defined in network programming:
>    Extension headers (except for the Hop-by-Hop Options header) are not
>    processed, inserted, or deleted by any node along a packet's delivery
>    path, until the packet reaches the node (or each of the set of nodes,
>    in the case of multicast) identified in the Destination Address field
>    of the IPv6 header.
>
> Clearly we process the SRH at the node identified in the destination address field of the IPv6 header.
> With PSP we remove the SRH at the node identified in the destination address field of the IPv6 header.
>
Darren,

I believe you are assuming a very liberal interpretation of the
wording in RFC8200. If intermediate hosts in the routing list are able
to add or remove SRH per RFC8200, then they are allowed to add or
remove any and all extension headers per the same interpretation. I do
not believe that is at all the intent of RFC8200. Also note that the
liberal interpretation it would validate other cases of arbitrary
extension header manipulation like in NAT devices for instance.

Tom

> I think it’s clear we can conclude this thread.
>
> Darren
>
>
>
> On Dec 6, 2019, at 5:01 PM, Ron Bonica <rbonica@juniper.net> wrote:
>
> >> I have observed, in your original post, the conflation of SRH insertion within an SR Domain with the PSP behavior defined in network programming.
> >> Whether this was intentional or not, I do not know.
> >> Regardless, it is wrong.
>
> Darren,
>
> We clearly disagree.  RFC 8200 addresses extension header insertion and deletion identically, in the same sentence.
>
>
>                                                        Ron
>
>
>
>
>
>
> Juniper Business Use Only
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------