Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Fernando Gont <[e-mail]>]

Bruno,

On 5/12/19 12:15, [e-mail] wrote:
[....]>
> This email starts a two weeks Working Group Last Call on
> draft-ietf-spring-srv6-network-programming [1].
> 
>  
> 
> Please read this document if you haven't read the most recent version,
> and send your comments to the SPRING WG list, no later than December 20.
> 
>  
> 
> You may copy the 6MAN WG for IPv6 related comment, but consider not
> duplicating emails on the 6MAN mailing list for the comments which are
> only spring specifics.
> 
>  
> 
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
> 
> This may help avoiding that the thread become specific to this point and
> that other points get forgotten (or that the thread get converted into
> parallel independent discussions)

Penultimate Segment Popping describes/specifies the removal of a SRH at
a place other than the final destination of the packet.

Such behavior violates RFC8200, which specifies:

   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.

Note, of course, that the reference of "Destination Address" in RFC8200
is clearly the final destination of the packet -- for instance, RFC8200
does not specify any routing header type, and hence the meaning is
unambiguous (there's no destination other than the final destination of
the packet).

This is of course in line with IPv6 being and end-to-end protocol, and
crucial for other related mechanisms to work as expected (such as IPsec
AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.

So, in order to proceed with the document, there are multiple options
forward:

1) Just remove the corresponding text/behavior

2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,
re-encap)

3) Do the necessary standards work to update RFC8200, such that it
allows this sort of behavior, and only ship the network-programming
draft for publication when at least 6man has consensus to proceed on
that path.

P.S.: I will go through the document once again... but the same
reasoning should be applied to any EH-insertion/removal at a place other
than the source of the packet or its final destination.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492