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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
