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 <[e-mail]>]

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
   headers.


...


5.1 <https://tools.ietf.org/html/rfc2473#section-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.

Best,
Robert