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

From: Mark Smith <[email-masked]>
Date: Sat, 7 Mar 2020 14:32:38 +1100

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.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 9 Mar 2020 14:28:34 +0000

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 <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Sander Steffann <[email-masked]>
Date: Mon, 9 Mar 2020 16:22:41 +0100

Hi,

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

That doesn’t make it less of a good idea ;)

I would definitely urge my vendors to implement it in the way that Mark describes.

Cheers,
Sander

---

From: Andrew Alston <[email-masked]>
Date: Mon, 9 Mar 2020 19:18:09 +0000

Hi Darren

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

Can we get a reference to these discussions please - would just be useful to back and refresh memories and wasn’t able to find them

Thanks

Andrew

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 10 Mar 2020 16:06:58 +0000

Hi Andrew please see issue #66 for the closure record.

https://trac.ietf.org/trac/6man/ticket/66

Darren

On Mar 9, 2020, at 3:18 PM, Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:

Hi Darren

Thanks

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Mar 2020 11:25:18 +1300

Darren,

Does that ticket mean that the issue was fixed in version -14 or version -15? I can't see anything in the diffs for those versions that relates to RFC4291, and it isn't in the references.

In any case, I don't think the target for this issue should be the 6MAN document. It should be RFC8402, which says:
   An instruction is
   associated with a segment and encoded as an IPv6 address.
This train left the station when RFC8402 was approved.

Regards
   Brian Carpenter

On 11-Mar-20 05:06, Darren Dukes (ddukes) wrote:
>> On Mar 9, 2020, at 3:18 PM, Andrew Alston <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Darren
>>
>>  > association with RFC4291 and closed it with
>>  > the text in the document.
>>

---

From: Andrew Alston <[email-masked]>
Date: Wed, 11 Mar 2020 07:32:16 +0000

I am also a little confused about this –

Because I went through those versions and I don’t see anything changing – furthermore – the issue was closed does not contain any record of the discussion under which it was closed.

I also can’t find any references on the list – though there has been so much email on there its entirely possible I’m missing something – so – if there was discussion around this, again, can we get some references from the lists?

Andrew

From: Brian E Carpenter <[email-masked]>
Sent: Wednesday, 11 March 2020 01:25
To: Darren Dukes (ddukes) <ddukes=[email-masked]>; Andrew Alston <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Darren,

Regards
Brian Carpenter

On 11-Mar-20 05:06, Darren Dukes (ddukes) wrote:
> https://trac.ietf.org/trac/6man/ticket/66<https://trac.ietf.org/trac/6man/ticket/66>
>
> Darren
>
>> On Mar 9, 2020, at 3:18 PM, Andrew Alston <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:
>>
>> Hi Darren
>>
> [email-masked]<mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Mar 2020 18:55:01 +0000

Darren,

Didn't we agree to close issue 66 because draft-ietf-6man-segment-routing header contains no text regarding SID/IPv6 address semantics. If that's the case, how can you say that closing issue 66 implies WG consensus around SID/IPv6 address semantic proposed in draft-ietf-6man-network-programming?

                                                                                       Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Tuesday, March 10, 2020 12:07 PM
To: [email-masked] <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

https://trac.ietf.org/trac/6man/ticket/66<https://urldefense.com/v3/__https:/trac.ietf.org/trac/6man/ticket/66__;!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_$>

Darren

Hi Darren

 > the text in the document.

Can we get a reference to these discussions please - would just be useful to back and refresh memories and wasn't able to find them

Thanks

Andrew

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 11 Mar 2020 19:03:04 +0000

Hi Ron, I made no comment in this thread on draft-ietf-spring-network-programming.

Darren

On Mar 11, 2020, at 2:55 PM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Darren,

Didn’t we agree to close issue 66 because draft-ietf-6man-segment-routing header contains no text regarding SID/IPv6 address semantics. If that’s the case, how can you say that closing issue 66 implies WG consensus around SID/IPv6 address semantic proposed in draft-ietf-6man-network-programming?

                                                                                       Ron

Juniper Business Use Only
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Darren Dukes (ddukes)
Sent: Tuesday, March 10, 2020 12:07 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Darren

Hi Darren

Thanks

Andrew

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 16 Mar 2020 16:34:28 +0000

Ron, I missed answering your question on semantics and SIDs.  The answer is in RFC8754 and RFC8402 and their discussion of SID semantics:
- RFC8402 tells us an SRv6 SID is an IPv6 address.
- RFC8754 section 1 defines SRv6 and its instantiation in the IPv6 dataplane, along with SID terminology
- RFC8754 section 2 defines Segment List as a list of IPv6 addresses
- RFC8754 section 3.3 defines an SR segment endpoint node, making the distinction between "segment or local interface."
- RFC8754 section 4.3 describes processing at segment endpoint node for either; a fib entry representing a locally instantiated SRv6 SID, or a local interface not instantiated as a SRv6 SID.
- RFC8754 section 5 describes the Intra-SR-Domain deployment model, where:
  - within the SR domain "Allocate all the SIDs from a block S/s"
  - within the SR domain “Assign all interface addresses from prefix A/a"
  - At node k [within the SR domain], all SIDs local to k are assigned from prefix Sk/sk

Darren

On Mar 11, 2020, at 3:03 PM, Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>> wrote:

Darren

Darren,

                                                                                       Ron

Darren

Hi Darren

Thanks

Andrew