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 <> Sat, 07 December 2019 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 814AD12082B for <>; Sat, 7 Dec 2019 10:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F4KifophjE8q for <>; Sat, 7 Dec 2019 10:40:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6804120828 for <>; Sat, 7 Dec 2019 10:40:55 -0800 (PST)
Received: by with SMTP id c16so1069739qko.6 for <>; Sat, 07 Dec 2019 10:40:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LHgHs6F00en7DabbyeqyMLAgwsiLMPmqh1KB6cDTclU=; b=ZDyBH1aNQ24gVdV5hodKpTmZi99sFDyRpfW/qJCRkyCYdR7Bj8tSQCqQ506bHSnWqq PgcIwp0zthapxrnKX6CMG8Au+yFUedw36Fctz0e44PkKmhXWkLuJjQEWTNwYdxb9r3lB wYe3oqHOwnWwSIAq7NwFDnJMO1INYt5sUH5V+fiOP8wAw8BCkxLsT7yuSO/VJ5nZxggI 0oG+cP7e+76mjdv6vP9mqhHRzIX16an9YGgawnknWwc7UiF0yRobJNo6D16n2I27xWUJ /tCaTvSZhYvTXJAjMTXDYPDEdq8dy+gsVN8XfVK3E5u10wxmDUggFg8TqC/LNEwL9Miw Ly/Q==
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=LHgHs6F00en7DabbyeqyMLAgwsiLMPmqh1KB6cDTclU=; b=sCnfLs2u28/4T48CnLkq623OrMfyG4rXydpUv+znFhNgPM4sxJTPa39+ohlChnXHrb a8M4kgjPb4S6vw/TATjBLqMl+PrLp4gbpKsTG/d/8xfOECC9Wl7WD3Gnny5LeeIJbMyB MMxVJ3qOEenbX6hTm3gqHR7uU5kMI38MVb1BoVy/ha611g9rKHhqtQh8f3fOVlikgKSm z1L6eoJVRSJW7O3Rb75/iVXPHpZHphrq98cO0NLz+EfjnMZwGODSE3t0rSrV5MYm79QU z41caK8MKowzJdvNBiZAyywiaH2ABDE2PcsdEYhUB7zMMeWgZQ+rx+6mOscpnIUpdJYc l2NA==
X-Gm-Message-State: APjAAAVShhuOpogwJdAtfGfJd6+5P2eQO2PtGlba+892NbVTJJLLsNPk E3s/CeD2xIdLaA2e0v4R0Jo2GZVuWrKV3iNMcWC8qA==
X-Google-Smtp-Source: APXvYqwNTf/7N5zD6gjdoGE3flUMlfD94VdCdug0XdfDfqTBx03fyEn5OMsbQaQENLAf4kaO8GXcsyNaUTHJRIQKIbk=
X-Received: by 2002:a37:4a0a:: with SMTP id x10mr13083061qka.302.1575744054627; Sat, 07 Dec 2019 10:40:54 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sat, 7 Dec 2019 19:40:46 +0100
Message-ID: <>
To: Fernando Gont <>
Cc: Suresh Krishnan <>, SPRING WG <>, Ron Bonica <>, "" <>, Andrew Alston <>, rtg-ads <>, Bob Hinden <>, Ole Troan <>, Brian E Carpenter <>
Content-Type: multipart/alternative; boundary="000000000000a2230c059921807f"
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: Sat, 07 Dec 2019 18:40:59 -0000

Hi Fernando,

> The online possible instantiation of "Destination Address" as in RFC8200
> is the final destination of the packet.

No. That is incorrect.

Hint: Please read carefully RFC2473.

Please focus on sections: 3.1, 3.2, 3.3, 5.1 etc ...

Kindly read this part of section 3.2 at least few times:

a tunnel Destination Options extension header is processed *at the
tunnel exit-point node.*

. . .

   Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel
   exit-point node, its IPv6 protocol layer processes the tunnel


5.1 <> Tunnel IPv6
Extension Headers

   Depending on IPv6 node configuration parameters, a tunnel entry-point
   node may append to the tunnel IPv6 main header one or more IPv6
   extension headers, such as a Hop-by-Hop Options header, a Routing
   header, or others.


Then you may continue with your appeal.

- - -

Darren and others,

While this is clear for most folks I see that perhaps any SRv6 spec (NP in
particular) should clearly distinguish the notion of final packet
destination address from segment endpoint destination address inserted in
the encapsulation header.

Today document only defines  "DA: Destination Address" - I can see why this
may confuse some folks as it is used interchangeably with original
destination address.

IMO it would be a good change to redefined "DA" as "Segment Endpoint
Destination Address" and when referring to original packet destination
address perhaps call it Original DA (O-DA) and original source address
(O-SA). That way there would be no confusion at all (one may hope ;-).

Just a hint.