Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

[Nick Hilliard <[e-mail]>]

Joel M. Halpern wrote on 13/10/2021 04:52:
> 1) Does the placement of a list of sids in the IPv6 DA field change the 
> IPv6 architectural description of that field.

the draft, as I understand it, specifies that inside the srv6 limited 
domain, the DA is overwritten in-flight with a locator of configurable 
mask length, followed by a stack containing CSIDs.

On each node that the packet passes through, the router left-shifts the 
stack of CSIDs by a number of bits, which causes an implicit stack pop 
of the CSID list.  The locator remains unchanged.

Once the stack is empty, the DA field is reverted to the original DA.

The question from the point of view of IPv6 architecture is whether the 
modified DA a) represents the ipv6 address of an interface (rfc4291, 
section 2.1) and b) represents the "128-bit address of the intended 
recipient of the packet" (rfc8200, section 3).

The answer to both of these questions seems to be no.

--

If we take the examples in draft-clad-spring-srv6-srh-compression-illus, 
the locator is 2001:db8:000b (block length 48), normally written as 
2001:db8:b::/48.

At no point is there necessarily a node in the network with an interface 
which which is bound to an ip address constructed as 
[locator].[csid1]..[csidN].  It might happen that there was such an 
interface, but this is not necessary for the protocol to function as 
specified.

 From this point of view, the draft does not appear to comply with the 
definition of the destination address field of the ipv6 header, as 
defined in rfc8200.

--

Question b (i.e. whether the address represents the "128-bit address of 
the intended recipient of the packet").  It is presumed that the address 
space carved out by the operator allocates a unique block of IP 
addresses for the locator.  The modified DA will not generally (and 
probably not ever) represent the intended recipient of the packet, so on 
this basis it seems that the draft introduces a semantic change to the 
addressing architecture of ipv6 as defined in rfc4291.

--

In simple terms, the srh compression draft appears to repurpose the ipv6 
DA field as a temporary storage stack.  This changes the semantics of 
the DA field into something different that rfc8200 / rfc4291 aren't 
aware of.

Some people have brought up NAT and mutable ipv6 header fields.  I don't 
see an issue with modifying source or destination IP addresses / ports 
in-flight, as long as they represent actual endpoints as defined in 
rfc8200/4291.  We have 25 years of precedent in the form of NAT, so this 
simply isn't a problem.

What is a problem is changing the semantics of a well-known field to 
mean something else other than what's defined in 8200/4291.  The 
rationale for doing this is not relevant.

On a constructive point, I have no doubt that the authors need space to 
store the SID stack, so it may be better for them to consider using an 
EH for this purpose.  If this were handled in a similar way to how 
standard SRv6 forwards packets using EHs for SID lists, I don't believe 
that there would be an issue for 6man to be concerned about, and as 
there is already running code which uses EHs to determine next-hops for 
SRv6 packets, there is no reason not to do something similar for C-SIDs.

> 2) Does the operation of shifting information around in the IPv6 
> destination address field represent a modification or extension of the 
> IPv6 data plane.

Although the syntax remains the same, the draft proposes that the 
semantics of the ipv6 header be modified.  In a SRv6 domain, a packet 
modified as described will do one thing, and outside the domain it mean 
something quite different.

Rather than answering this question directly, let's take the 
heterogeneous brown-field network example provided in:

https://mailarchive.ietf.org/arch/msg/ipv6/LQyfNkJjCEijP0v8mHYIQPBT7-A/

In this network, if a packet has its DA modified as described in this 
draft, then the packet would not necessarily arrive at its endpoint if 
it needed to traverse a section of the network which wasn't srv6 aware. 
If no modification had been made to the ipv6 data plane, then the packet 
would be expected to arrive at its destination.

This is in contrast with standard srv6, which can apparently support 
this style of configuration.

It is true that SRv6 is defined only in terms of its rfc8799 limited 
domain and you could argue that as the limited domain is not properly 
specified according to what the I-D authors intended, that this is a 
configuration problem rather than a protocol problem.

Flip side, this example describes what happens when limited domains hit 
operational reality, i.e. this is an interesting example of why 
modifying data plane semantics is considered to be a red-flag issue from 
the point of view of baseline protocol semantics - things break.

Nick