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

Mark Smith <> Wed, 11 December 2019 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F32871201AA; Tue, 10 Dec 2019 16:38:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZQB1LCv16Avn; Tue, 10 Dec 2019 16:38:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D339C12018B; Tue, 10 Dec 2019 16:38:22 -0800 (PST)
Received: by with SMTP id 77so17282750oty.6; Tue, 10 Dec 2019 16:38:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aFSl6I7rytE5EKtFSqL8epDa09BaWvpvD0m/8YUB27Y=; b=sbHaVZkpE+8tca7aFP6sA8x6hH8f12rvexLrJLOHXqu/bMCRunJvI2QuWcwcBD8/QJ KPENlCCiEkY5qGI9qMkQX2fRm/20AzxYRdXO+UGWvTAF2tamPiwCaLgKzsj9aceweloe K/TjRv8vO99/VKKQHmfW2hDvKZ38k6nwLr5hATf8HhuNB0pH7N3or2qgbE3ykhzCKrQj f3+/g0yyiVr7asviADR95jQ7I+YBdraVJTkes2WPrIOg0n6wovQng1Gc1TK/gCjHscIC 5OFXCZ7K02atNGFPCl2Pt6sl/TsjSWqxv8RkGP4vS54BNXgvm8mlNA5Z0GxzmpKno10X 4zCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aFSl6I7rytE5EKtFSqL8epDa09BaWvpvD0m/8YUB27Y=; b=HbM8k5exR9P8hkB61RaJOYz81wMAvwzcLg3Ay2blnnCK8j9dIylKmUuFqE1tOfECT6 qk6iEhvix5mxxft2dOUd/lxONBJ9XNeB9RQDdVpnfpczwcCNFWgO1EflVxZxNIhP/eRr c19+KYdyczRkekOQOjNXR1cMJe4PJoiiPEAT/AKMljPqDNTPWgkCZkv3pjDUVGUbx9Mm U8WWnfJwQ07YA0dpWd62ekQ7qfeNkHy36bHnYKWFQhmBq4YjfOV7NPcrK1qbgRGj/y4U ejDUBuSrdoM+yPtvj0wJ3Nh970GdtU7XsmizAsijj7vV5osGWs4TxIGisXwSHT5Bq79a 2mkw==
X-Gm-Message-State: APjAAAXrlgzlR0wA0B9HXBI+Tf2Mts7G7W8eLcv+IFgIdnwT+/I0EIfJ BwtVQLfTP3/D45WfQaACBYLDDfCWUZn1dwjeMrM=
X-Google-Smtp-Source: APXvYqwo+ZmTtX1QU4TLt9pMkVtM9s0ic/0iZCf/ALeZnCXNTKlip/DDerOQW35gLl5A+bj9ndTsb9VTz/PXZTmu3dY=
X-Received: by 2002:a05:6830:9:: with SMTP id c9mr458573otp.94.1576024702161; Tue, 10 Dec 2019 16:38:22 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <27448_1575983799_5DEF9AB7_27448_30_1_53C29892C857584299CBF5D05346208A48D245CD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Wed, 11 Dec 2019 11:37:56 +1100
Message-ID: <>
To: Robert Raszuk <>
Cc: Fernando Gont <>, Ron Bonica <>, SPRING WG <>, "" <>, Andrew Alston <>, rtg-ads <>, Bob Hinden <>, Suresh Krishnan <>, Bruno Decraene <>, Ole Troan <>, Brian E Carpenter <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
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-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Dec 2019 00:38:25 -0000

On Wed, 11 Dec 2019 at 10:39, Robert Raszuk <> wrote:
> Dear Fernando,
> Allow me to make something very clear here.
>> And, since we are at it, please let me know if IPv6 is and end to end
>> protocol. And, if it is, how does that e2e-ness work with inserting and
>> removing EHs on the path to the ultimate destination of a packet.
> The dream of IPv6 flat end to endless is long gone if it ever was even real.

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

> There is no end to end IPv6 or for that matter IPv4 delivery today across any network. Regardless if this is private or public network of any reasonable size and service portfolio.

I don't think you understand what end-to-end means with those assertions.

NAT breaks end-to-end.

If your assertion was true about IPv6, then you are asserting that
literally every IPv6 packet is going through NAT66 at some point.
That's certainly not happening.

> Some form of encapsulation or tunneling is used in enterprises, in ISPs, in SPs or even in largest public clouds.
> So if you think that you can send an IPv6 packet and that this packet will be delivered to its final destination without any encapsulation on the way - this is just unreal. And the sooner you and others like you realize this the better for everyone.
> Think about L3VPNs reachability segmentation, think about SFC/NSH, think about L2 transport emulation of your circuits, think about seamless mobility, LISP  ...
> Just a tiny reality check,
> Thx,
> R.
> _______________________________________________
> spring mailing list