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

["Darren Dukes (ddukes)" <[e-mail]>]

Hi Mark, the working group discussed the association with RFC4291 and closed it with the text in the document.

Besides, and as you note with your IPSec reference, this is a local implementation decision.

Darren

> On Mar 6, 2020, at 10:32 PM, Mark Smith <[e-mail]> wrote:
> 
> 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.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------