Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

On Fri, 13 Mar 2020, 01:41 Fernando Gont, <fgont@si6networks.com> wrote:

> On 11/3/20 23:34, Brian E Carpenter wrote:
> > On 12-Mar-20 10:44, Fernando Gont wrote:
> >> On 11/3/20 18:30, Brian E Carpenter wrote:
> >> [....]
> >>>
> >>> However, I can't find anything in RFC 4291 that forbids addresses
> >>> having semantic meanings rather than being pure locators. It goes
> >>> against one of my design prejudices, but I can't find anything
> >>> resembling "Encoding semantics in address bits considered harmful"
> >>> in the RFCs.
> >>
> >> Didn't *you* write that document? ;-) : RFC7136
> >
> > Well yes, in the context of IIDs used for SLAAC etc. But that's a bit
> more
> > narrow than what we are discussing here, I think. I assume that SLAAC is
> > not involved.
>
> Isn'tpart of the rationale for RFC7136 that there are actually so many
> different ways to configure addresses that you cannot even assume SLAAC?
> (e.g., see the example on /127s for point-to-point links)
>

Although SLAAC/EUI-64s might have triggered the work on what became
RFC7136, I've never seen it as SLAAC specific.

"

   In all cases, the bits in an IID have no generic semantics; in other
   words, they have opaque values.  In fact, the whole IID value MUST be
   viewed as an opaque bit string by third parties, except possibly in
   the local context.

"

RFC4291 is where forming addresses from EUI-64s is specified, and that
isn't SLAAC specific - there is no mention of SLAAC at all.

I've more generally thought that RFC7136 was saying that while a packet is
in-flight, the IID portion only has forwarding semantics, in addition to
the prefix and subnet fields, which is and makes it consistent with longest
match all 128 bits BCP 198 for unicast forwarding.

Any other semantics in addresses are limited to and shared by the original
packet source host and the final packet destination host. This, for
example, permits addresses to be used as anycast function identifiers once
the packet arrives at the final destination host.

So there is clear separation between the purpose of the network -
forwarding to reach the specified destination - and the destination host -
processing of the packet to serve the original, typically application,
purpose of the original source host sending it.

Regards,
Mark.

>
>
> > Good catch, though ;-)
>
> ;-)
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>