About IPv6 address semantic

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Miya, 6man WG,

I had some impression about the “address semantic violation” on 6man WG before, and have seen similar arguments many times in recent few days, but when reading your points below, seems like it may be the root cause of the years of confusion and argument about how to correctly/better use IPv6 address “semantic”!?

The said “violation” to IPv6 address semantics seems to be “SRv6 SID” defined in RFC8402 ----SRv6 SID is an IPv6 address explicitly associated with the segment.
The said “address semantic” seems to be the “IPv6 address” defined in RFC4291----IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces


Firstly, Let me share some various kinds of “interface” I have seen:
An “interface” could be a configured one with a name, like “interface Ethernet1/0/1”, “interface GbE1/0/1”, “interface loopback12345678”.
An “interface” could be a dynamically created one with a name like “mtunnel0”, you can even show the statistics of this interface using its name “display interface mtunnel0”. This is a logical P2MP-interface as the abstraction of “a full-mesh P2MP-trees” for RFC6037.
An “interface” could be even more “implicit”, for example, using RSVP-TE signaling to carry a name “tunnel-2020” from PE1 to PE2 through P1, and you can “display interface tunnel-2020” or maybe “display tunnel tunnel-2020” on P1, which does not have an “interface” configuration or creation at all. This is a logical P2P-interface name representing an LSP scattered through the network.

An SRv6 SID makes no difference than them IMO. Every “SRv6-SID” is a “128-bits IPv6 address” and could be “128-bit identifiers for an interface” if one like.
For example, the following is a configuration example of SRv6 locator and functions:
SRv6 locator loc1 2001:db8:3:4::64
  Function loc1 end ::1   ## This SRv6-SID “2001:db8:3:4::1” is a 128-bit IPv6 address.
  Function loc1 end-dt4 ::2  ## This SRv6-SID “2001:db8:3:4::2” is another 128-bit IPv6 address.

If one would like, one can assign a name for each of the SRv6-SID, for example, one may name it “interface-SRv6-SID:2001:db8:3:4::1”.
One can then use “display interface interface-SRv6-SID:2001:db8:3:4::1” for IPv6 address management and maintenance.

As I read RFC4291 further, the “IPv6 address” is nothing more than a 128-bits, and the “interface” is nothing more than a part of the 128-bits:
----Interface identifiers in IPv6 unicast addresses are used to identify interfaces.
----[My read] Interface ID is nothing more than “part” of the 128-bits IPv6 address.


Secondly, let me share some of the various “semantics” of an IPv6 address I have seen:
An IPv6 address could be used to identify/represent a router (similar to router-id), for example, RFC7794.
An IPv6 address could embed the 32-bit Multicast group ID into a 128-bit IPv6 address, RFC3307.
An IPv6 address could embed the 32-bit unicast IPv4 address into a 128-bit IPv6 address, RFC3956.
One may easily extended this to:
An IPv6 address could be used to identify a router with some “instruction”.
An IPv6 address could embed the 32-bit VPN ID into a 128-bit IPv6 address.
An IPv6 address could embed the 24-bit VNI ID into a 128-bit Ipv6 address.
An IPv6 address could embed the 16-bit, 20-bit or 32-bit of Tag into a 128-bit IPv6 address.

They could each be a “128-bit identifier for interface” if you like to manage the IPv6-address as an “interface”.
Seems to me it’s nothing more than a style of “management” of the huge IPv6 address space a node owns.

As I read RFC4291 further, the RFC4291 says an IPv6 address could have “internal structure”, seems to me very similar meaning as “semantics”.
   Though a very simple router may have no knowledge of the internal
   structure of IPv6 unicast addresses, routers will more generally have
   knowledge of one or more of the hierarchical boundaries for the
   operation of routing protocols.


Maybe it could be concluded by 6man WG whether there is “address violation” in SRv6 SID [RFC8402], or whether 4291 address is better than non-4291 address ?
I think that may be a great help to the folks from worrying about the (ab)use of IPv6 address “semantics”, or the “the evolution of IPv6”.

Thanks
Jingrong


From: ipv6 [mailto:[e-mail]] On Behalf Of Miya Kohno
Sent: Thursday, May 28, 2020 11:56 PM
To: Fernando Gont <[e-mail]>
Cc: IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Fernando,

Thanks. There was a bit of leap.

In support, for example, the argument that CRH is better because there is no address semantic violation. These discussions are scattered and hard to reference, but it's summarized here.

p.24-
https://pc.nanog.org/static/published/meetings/NANOG77/2080/20191029_Bonica_Srv6__v1.pdf<https://pc..nanog.org/static/published/meetings/NANOG77/2080/20191029_Bonica_Srv6__v1.pdf>

Miya
>
> - And more importantly, it interferes the evolution of IPv6.
>    -- There is a simpler, more scalable way to do it, but CRH can delay it, sticking to the existing convention.
>    -- This can take away the potential of IPv6 itself.
>    -- IPv6 should evolve. Otherwise, we have no choice but to give way to the new Non-IP or IPvx proposals.