draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

[Mark Smith <[e-mail]>]

Just to pull it out of my last response to Joel for discussion,

"It only occurred to me yesterday that SRH/SRv6 might also be violating
RFC 4291, as it seems that when SIDs are transformed into IPv6
addresses, those IPv6 addresses aren't assigned to interfaces but
rather nodes:

RFC 4291:

"2.1.  Addressing Model

 IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node."


draft-ietf-6man-segment-routing-header-26:

"4.3.  SR Segment Endpoint Node

 When an SRv6-capable node receives an IPv6 packet, it performs a
   longest-prefix-match lookup on the packets destination address.  This
   lookup can return any of the following:

       * A FIB entry that represents a locally instantiated SRv6 SID
       * A FIB entry that represents a local interface, not locally
                                       instantiated as an SRv6 SID
       * A FIB entry that represents a non-local route
       * No Match"

It would seem to me that the first match bullet point is effectively a
node IPv6 address match.

[...]"

Compliance with RFC4291 could be achieved by assigning a prefix to a
virtual interface, effectively assigning all of the addresses within
the prefix to the virtual interface.

I've proposed that sort of thing in "4. Addressing Tunnel Endpoints"
of "Skinny IPv6 in IPv6 Tunnelling" -
https://tools.ietf.org/id/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00.html#rfc.section.4.
I also discussed some issues related to address selection in that
situation.

A significant operational advantage of assigning a SID prefix to a
virtual interface would be that then all of the things that use an
interface as a handle becomes available e.g. interface packet counters
and being able to query them via SNMP, interface assigned packet
filters/ACLs, etc.

Early Cisco and Linux crypto/IPSec implementations didn't use virtual
tunnel interfaces to represent IPsec tunnels. They became much more
operator friendly when they did.

Regards,
Mark.