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

[Brian E Carpenter <[e-mail]>]

Ted,

On 15-Oct-21 23:39, Ted Hardie wrote:
> On Thu, Oct 14, 2021 at 10:06 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 14-Oct-21 22:41, Ted Hardie wrote:
>     > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>     >
>     >
>     >
>     >     Including semantics *of any kind* in an IP address is a very fundamental
>     >     change to the concept of IP.<https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>>
>     >
>     >
>     > Would you mind elaborating what you mean by semantics in the statement above?  Clearly there are semantics in things like the IPv4 multicast and experimental address ranges (aka "Class D" and "Class E"); especially for the multicast case, the very fundamental semantics of the distribution are signalled using the address and there has been significant 
deployment using those semantics.  Isn't that semantics in the meaning above?
> 
>     Yes, I should have restricted my remark to *unicast* addresses. But 
there
>     is a difference, I think, between semantics that describe the *type 
of address* and semantics that actively describe *what the recipient is going to do*. It's the latter that I was getting at.
> 
> 
> Thank you for the clarification, though I'm still struggling a bit with 
understanding your concern.  Since we use address ranges for scope semantics (e.g. ULAs for administratively determined scopes) even within unicast addressing, I'm not quite seeing the line you are yet.


I definitely did not express myself clearly enough. I want to draw a distinction between unicast address bits that are arbitrary numbers as far as 
the routing system is concerned -- such as the classical IID bits in IPv6 
unicast addresses, or the prefix bits following fc00::/7 -- and address bits that are meaningful to the routing system, such as fe80::/10 (which means "do not route this packet").

A glance at https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml shows that this distinction is not mathematically rigid, because of oddities like 100::/64, but I think it's generally valid.

Within an SRV6 domain, with RFC8986 and the current draft, we see something new: a field which has classically been an arbitrary 64-bit number for 
the routing system (the IID field) becomes meaningful to the routing system. That's an architectural change, and definitely was not envisaged by the IPv6 address architecture.

So, IMHO, the question behind SPRING's question to 6MAN is not whether there is an architectural change, but whether this changes matters. In particular, will it have impact on legacy devices and software within the SRV6 domain, and will it do any damage if it leaks outside the domain?

(To a certain extent, this question is linked to draft-bourbaki-6man-classless-ipv6.)

> 
>> (This applies to Carsten's comment too. Port numbers or multiple addresses per host are not actively describing what the recipient will do; they're just numbers.)
> 
> While this may theoretically be true, we actually associate significant 
semantics with port numbers, both in the end hosts (e.g. the ports below 1024 being privileged ports) and in the network (where firewalls use ports to start the process of analyzing the permissibility of a flow).  A specific port number very much describes what the host will do:  port 25 will link to the SMTP service, for example.  So I guess I'm not following this parallel too well either.


I hope that it's clearer now that I'm making a distinction between bits that do or do not convey a semantic meaning to unicast routing mechanisms. 
What happens inside the destination host is really a different matter.

Regards,
   Brian

> 
> regards,
> 
> Ted
>  
> 
> 
>     Also, I tried not to express shock and horror at the notion of semantics in address, but concern about how this will impact existing hardware and software.
> 
>     >
>     > Thanks for any clarification,
>     >
>     > Ted
>     >
>