Subject: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

From: Andrew Alston <[email-masked]>
Date: Wed, 11 Mar 2020 20:53:05 +0000

Hi Spring WG

On the basis of the below – I must conclude that the issues relating the SID/IPv6 semantics have indeed not been dealt with by the spring working group in the context of the network programming draft – and I would now like to raise those issues in the context of that draft – and the fact that draft-ietf-spring-network-programming violates the address semantic specifications of RFC4291.

Can we please have a proper discussion on this

Thanks

Andrew

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wednesday, 11 March 2020 at 22:03
To: Ron Bonica <rbonica=[email-masked]>
Cc: Andrew Alston <[email-masked]>, 6man WG <[email-masked]>
Subject: Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

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?

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

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

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

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: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Mar 2020 10:30:03 +1300

> On the basis of the below – I must conclude that the issues relating the SID/IPv6 semantics have indeed not been dealt with by the spring working group in the context of the network programming dra…

I really think that this is subsidiary to RFC 8402 (a Proposed Standard):

   SR can be applied to the IPv6 architecture with a new type of routing
   header called the SR Header (SRH) [IPv6-SRH].  An instruction is
   associated with a segment and encoded as an IPv6 address.  An SRv6
   segment is also called an SRv6 SID.  An SR Policy is instantiated as
   an ordered list of SRv6 SIDs in the routing header.

I don't see anything in the SRH draft or the network-programming draft
that is not within that definition. Whether RFC 8402 contravenes RFC 4291
is worth discussing, I guess. The latter says:

   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.

However, I can't find anything in RFC 4291 that forbids addresses
having semantic meanings rather than being pure locators. It goes
against one of my design prejudices, but I can't find anything
resembling "Encoding semantics in address bits considered harmful"
in the RFCs.

In reality, there are lots of operational practices that amount to
giving semantic meanings to address bits.

   Brian

> *From: *"Darren Dukes (ddukes)" <[email-masked]>
> *Date: *Wednesday, 11 March 2020 at 22:03
> *To: *Ron Bonica <rbonica=[email-masked]>
> *Cc: *Andrew Alston <[email-masked]>, 6man WG <[email-masked]>
> *Subject: *Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
> 
>  
> 
>     On Mar 11, 2020, at 2:55 PM, Ron Bonica <rbonica=[email-masked] <mailto:rbonica=[email-masked]>> wrote:
> 
>      
> 
>     Darren,
> 
>      
> 
>     *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?
> 
>      
> 
>     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
> 
>      
> 
>         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.
> 
>          
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Mar 2020 18:44:55 -0300

On 11/3/20 18:30, Brian E Carpenter wrote:
[....]
> resembling "Encoding semantics in address bits considered harmful"

Didn't *you* write that document? ;-) : RFC7136

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Bob Hinden <[email-masked]>
Date: Wed, 11 Mar 2020 17:39:30 -0700

Brian,

> On Mar 11, 2020, at 2:30 PM, Brian E Carpenter <[email-masked]> wrote:
> 

RFC4291 in Section 2.5.4 does say:

   Except for the knowledge of the subnet boundary discussed in the
   previous paragraphs, nodes should not make any assumptions about the
   structure of an IPv6 address.

Bob

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Mar 2020 15:34:01 +1300

> Didn't *you* write that document? ;-) : RFC7136

Well yes, in the context of IIDs used for SLAAC etc. But that's a bit more
narrow than what we are discussing here, I think. I assume that SLAAC is
not involved.

Good catch, though ;-)

    Brian

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 12 Mar 2020 04:20:27 +0000

Correct Brian, no SLAAC.

Darren

> On Mar 11, 2020, at 10:34 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 12 Mar 2020 06:22:16 +0000

Hi Brian, I agree with your statement re operational practices.
Indeed this was mentioned on SPRING in the past, and at that time a couple RFC examples were given RFC6059, RFC7599. I'm sure there are others.

Andrew, are you providing any new technical information?

Darren

On Mar 11, 2020, at 5:30 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

  Brian

Thanks

Andrew

*From: *"Darren Dukes (ddukes)" <[email-masked]<mailto:[email-masked]>>
*Date: *Wednesday, 11 March 2020 at 22:03
*To: *Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
*Cc: *Andrew Alston <[email-masked]<mailto:[email-masked]>>, 6man WG <[email-masked]<mailto:[email-masked]>>
*Subject: *Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Darren

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

   Darren,

                                                                                          Ron

   *From:* ipv6 <[email-masked]<mailto:[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]> <mailto:[email-masked]> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
   *Cc:* 6man WG <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
   *Subject:* Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

   Darren

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

       Hi Darren

       Thanks

       Andrew

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Andrew Alston <[email-masked]>
Date: Thu, 12 Mar 2020 08:26:10 +0000

Brian,

Let me clarify a few things – for my own understanding – I am happy to be wrong here, and if I am just let me know (while what I am writing may come across as statements, it was easiest to write that way, consider the statements clarification questions) –

Firstly – let us consider the RFC8402 argument for a second – though I think we should probably consider this separately.  In reference to RFC8402 this draft states – in section 3:

When an SRv6 SID is in the Destination Address field of an IPv6
   header of a packet, it is routed through an IPv6 network as an IPv6
   address.

So – we establish that indeed – SRv6 SID’s are IPv6 addresses – there is no two ways about it – they go into the destination field.  This is contrary to what Robert argued in an email found at https://mailarchive.ietf.org/arch/msg/spring/u1AzYFpDe-AhIxXdih2BEIz65Bk/

Now, lets look at this draft specifically in reference to RFC4291.

Section 2 of RFC4291 states that IPv6 addresses are identifiers for interfaces and sets of interfaces – where an interface is defined in RFC2460 as a “node’s attachment to a link”.  This document creates SID’s that have no binding to any interface.  Section 3 of the NP draft explicitly refers to lookups that lookup SID’s (which we have already established are addresses) that have no interface bindings.

In section 3.1 – this talks about the Locator – this is entirely compliant with section 2.5 of RFC4291 – however – the function and arguments section of this – have no relation to interface ID’s – it is debatable if this is as a result of problems in RFC8402 or indeed, potentially both drafts – since it is this document that explicitly creates these function and argument sections independently of RFC8402 in section 3.1.

Indeed RFC3587 states in section 3:

[ARCH] also requires that all unicast addresses, except those that

   start with binary value 000, have Interface IDs that are 64 bits long

   and to be constructed in Modified EUI-64 format.  The format of

   global unicast address in this case is:

I fail to see how defining a function and arguments in the way this document describes are compliant with this.  Now, it can also be argued that there are many implementations that violate these specifications – Linux allows you to bind entire /64s to loopback addresses, however, I would argue that it is a very different case for an implementation to violate the specification as for an RFC to violate the specification and make it into a standard.

I will also note and acknowledge that some may think that I am being pretty pedantic here – but considering the context and the claims floating around about what other RFC’s say and don’t say – perhaps its time to start examining this whole thing with a fine tooth comb so that we can end up with a better result that works for everyone and doesn’t lead to unintended consequences.

Thanks

Andrew

From: Brian E Carpenter <[email-masked]>
Sent: Thursday, 12 March 2020 00:30
To: Andrew Alston <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]; 6man WG <[email-masked]>
Subject: Re: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Brian

> On Mar 11, 2020, at 2:55 PM, Ron Bonica <rbonica=[email-masked] <mailto:rbonica=[email-masked]<mailto:rbonica=[email-masked]%20%3cmailto:rbonica=[email-masked]>>> wrote:
>
>
>
> Darren,
>
>
>
> *From:* ipv6 <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> *On Behalf Of *Darren Dukes (ddukes)
> *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
> *Cc:* 6man WG <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
> https://trac.ietf.org/trac/6man/ticket/66<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_$<https://urldefense.com/v3/__https:/trac.ietf.org/trac/6man/ticket/66__;!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_$>>
>
>
>
> 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
>
>
>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>

---

From: [email-masked]
Date: Thu, 12 Mar 2020 09:44:42 +0100

IP addresses have been used outside of the strict "identifiers for interfaces".
Apart from being used for routing, as a locator and as an identifier of course.
Load-balancers / addresses for a service, NAT, NPT66, NAT66, MAP-E/T, anycast addresses...
I am sure there are plenty others.

Unless Andrew can justify the "better result that works for everyone",
I do not believe rehashing the architectural properties of IP addresses serves any useful purpose.

Best regards,
Ole

> On 12 Mar 2020, at 09:26, Andrew Alston <[email-masked]> wrote:
> 
> Brian,
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Mar 2020 10:00:35 +0100

Hi Andrew,

Please kindly observe that SID can be 16-bit ... how could it be an IP
address as defined today ?

REF:
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-04

Please also notice that SID can be of variable length too. How could it be
an IP address ?

REF: https://tools.ietf.org/html/draft-decraene-spring-srv6-vlsid-03

And to your complete surprise let me point out that the text:

When an SRv6 SID *is in the* Destination Address field of an IPv6 header of
a packet,

simply says that SID can be part of DA, not necessarily need to be a
complete DA therefore SR architecture still holds pretty well :)

Cheers,

R.

On Thu, Mar 12, 2020 at 9:26 AM Andrew Alston <
[email-masked]> wrote:

> Brian,
>
>
>
> Let me clarify a few things – for my own understanding – I am happy to be
> wrong here, and if I am just let me know (while what I am writing may come
> across as statements, it was easiest to write that way, consider the
> statements clarification questions) –
>
>
>
> Firstly – let us consider the RFC8402 argument for a second – though I
> think we should probably consider this separately.  In reference to RFC8402
> this draft states – in section 3:
>
>
>
> So – we establish that indeed – SRv6 SID’s are IPv6 addresses – there is
> no two ways about it – they go into the destination field.  This is
> contrary to what Robert argued in an email found at
> https://mailarchive.ietf.org/arch/msg/spring/u1AzYFpDe-AhIxXdih2BEIz65Bk/
>
>
>
> Section 2 of RFC4291 states that IPv6 addresses are identifiers for
> interfaces and sets of interfaces – where an interface is defined in
> RFC2460 as a “node’s attachment to a link”.  This document creates SID’s
> that have no binding to any interface.  Section 3 of the NP draft
> explicitly refers to lookups that lookup SID’s (which we have already
> established are addresses) that have no interface bindings.
>
>
>
> In section 3.1 – this talks about the Locator – this is entirely compliant
> with section 2.5 of RFC4291 – however – the function and arguments section
> of this – have no relation to interface ID’s – it is debatable if this is
> as a result of problems in RFC8402 or indeed, potentially both drafts –
> since it is this document that explicitly creates these function and
> argument sections independently of RFC8402 in section 3.1.
>
>
>
> I fail to see how defining a function and arguments in the way this
> document describes are compliant with this.  Now, it can also be argued
> that there are many implementations that violate these specifications –
> Linux allows you to bind entire /64s to loopback addresses, however, I
> would argue that it is a very different case for an implementation to
> violate the specification as for an RFC to violate the specification and
> make it into a standard.
>
>
>
> I will also note and acknowledge that some may think that I am being
> pretty pedantic here – but considering the context and the claims floating
> around about what other RFC’s say and don’t say – perhaps its time to start
> examining this whole thing with a fine tooth comb so that we can end up
> with a better result that works for everyone and doesn’t lead to unintended
> consequences.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
> *From:* Brian E Carpenter <[email-masked]>
> *Sent:* Thursday, 12 March 2020 00:30
> *To:* Andrew Alston <[email-masked]>; Darren Dukes
> (ddukes) <[email-masked]>; Ron Bonica <rbonica=
> [email-masked]>
> *Cc:* [email-masked]; 6man WG <[email-masked]>
> *Subject:* Re: Draft-ietf-spring-network-programming ipv6 addressing
> architecture - was draft-ietf-6man-segment-routing-header-26 violating
> RFC4291, IPv6 Addressing Architecture?
>
>
>
> > On the basis of the below – I must conclude that the issues relating the
> SID/IPv6 semantics have indeed not been dealt with by the spring working
> group in the context of the network programming draft – and I would now
> like to raise those issues in the context of that draft – and the fact that
> draft-ietf-spring-network-programming violates the address semantic
> specifications of RFC4291.
>
> > 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
> >
> >
> >
> >
> >
> >
> >
> > *To:* [email-masked] <
> mailto:[email-masked]
> <[email-masked]>> <[email-masked]
> <mailto:[email-masked]
> <[email-masked]%20%3cmailto:[email-masked]>
> >>
> > 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
> >
> >
> >
> > On Mar 9, 2020, at 3:18 PM, Andrew Alston <[email-masked]
> <mailto:[email-masked]>> wrote:
> >
> >
> >
> > Hi Darren
> >
> >
> >
> > 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: Mark Smith <[email-masked]>
Date: Thu, 12 Mar 2020 21:16:21 +1100

> serves any useful purpose.

I think it serves a very important purpose, which is why I raised it.

SRv6 SRH says IPv6 addresses can be assigned to nodes, contrary to RFC
4291. What is the Interface Identifier portion of the address called in
that case, and where is it specified?

There needs to be an update to RFC 4291 if IPv6 addresses can now be
assigned to nodes.

I think that RFC 4291 requires that SRv6 requires implementations configure
the SID prefix on a virtual or physical interface, rather than leaving it
to be an implementation choice.

It also means there is then no need for a special case SR FIB lookup
algorithm, as described in SRH ID 4.3, as the existing, general purpose and
all cases IPv6 FIB lookup will work without modification.

Regards,
Mark.

> > Let me clarify a few things – for my own understanding – I am happy to
> be wrong here, and if I am just let me know (while what I am writing may
> come across as statements, it was easiest to write that way, consider the
> > In section 3.1 – this talks about the Locator – this is entirely
> compliant with section 2.5 of RFC4291 – however – the function and
> arguments section of this – have no relation to interface ID’s – it is
> debatable if this is as a result of problems in RFC8402 or indeed,
> potentially both drafts – since it is this document that explicitly creates
> these function and argument sections independently of RFC8402 in section
> 3.1.
> >
> > To: Andrew Alston <[email-masked]>; Darren Dukes
> > Subject: Re: Draft-ietf-spring-network-programming ipv6 addressing
> > > On the basis of the below – I must conclude that the issues relating
> the SID/IPv6 semantics have indeed not been dealt with by the spring
> working group in the context of the network programming draft – and I would
> now like to raise those issues in the context of that draft – and the fact
> that draft-ietf-spring-network-programming violates the address semantic
> > > On Mar 11, 2020, at 2:55 PM, Ron Bonica <rbonica=
> [email-masked] <mailto:rbonica=[email-masked]>>
> wrote:
> > >
> > >
> > >
> > > Darren,
> > >
> > >
> > >
> > > *To:* [email-masked] <mailto:
> [email-masked]> <[email-masked]
> <mailto:[email-masked]>>
> > > https://trac.ietf.org/trac/6man/ticket/66<
> > > On Mar 9, 2020, at 3:18 PM, Andrew Alston <
> [email-masked] <mailto:[email-masked]>>
> wrote:
> > >
> > >
> > >
> > > Hi Darren
> > >
> > >
> > >

---

From: Sander Steffann <[email-masked]>
Date: Thu, 12 Mar 2020 12:00:28 +0100

Hi Mark,

> SRv6 SRH says IPv6 addresses can be assigned to nodes, contrary to RFC 4291. What is the Interface Identifier portion of the address called in that case, and where is it specified?
> 
> There needs to be an update to RFC 4291 if IPv6 addresses can now be assigned to nodes.
> 
> I think that RFC 4291 requires that SRv6 requires implementations configure the SID prefix on a virtual or physical interface, rather than leaving it to be an implementation choice.
> 
> It also means there is then no need for a special case SR FIB lookup algorithm, as described in SRH ID 4.3, as the existing, general purpose and all cases IPv6 FIB lookup will work without modification.

Sounds like decent engineering decisions befitting the E in IETF to me!

Cheers,
Sander

---

From: Andrew Alston <[email-masked]>
Date: Thu, 12 Mar 2020 11:09:06 +0000

Ole,

I agree – and I don’t think anyone is suggesting such.  Rather we are questioning if there should be a rehash of the documents that are rehashing the properties of IP addresses.

Regards,

Andrew

Best regards,
Ole

> On 12 Mar 2020, at 09:26, Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
>
> Brian,
>
> So – we establish that indeed – SRv6 SID’s are IPv6 addresses – there is no two ways about it – they go into the destination field. This is contrary to what Robert argued in an email found at https://mailarchive.ietf.org/arch/msg/spring/u1AzYFpDe-AhIxXdih2BEIz65Bk/<https://mailarchive.ietf.org/arch/msg/spring/u1AzYFpDe-AhIxXdih2BEIz65Bk>
>
> From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
> To: Andrew Alston <[email-masked]<mailto:[email-masked]>>; Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; 6man WG <[email-masked]<mailto:[email-masked]>>
> > https://trac.ietf.org/trac/6man/ticket/66<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_$<https://urldefense.com/v3/__https:/trac.ietf.org/trac/6man/ticket/66__;!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_$>>
> >
> >
> >
> > Darren
> >
> >
> >

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Mar 2020 11:40:35 -0300

> narrow than what we are discussing here, I think. I assume that SLAAC is

Isn'tpart of the rationale for RFC7136 that there are actually so many 
different ways to configure addresses that you cannot even assume SLAAC? 
(e.g., see the example on /127s for point-to-point links)

> Good catch, though ;-)

;-)

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: James Guichard <[email-masked]>
Date: Thu, 12 Mar 2020 15:33:37 +0000

Hi Andrew,

Given RFC2460 definition of a link I am wondering which “link” a loopback interface attaches to in your opinion?

Jim

From: spring <[email-masked]> On Behalf Of Andrew Alston
Sent: Thursday, March 12, 2020 4:26 AM
To: Brian E Carpenter <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]; 6man WG <[email-masked]>
Subject: Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Brian,

So – we establish that indeed – SRv6 SID’s are IPv6 addresses – there is no two ways about it – they go into the destination field.  This is contrary to what Robert argued in an email found at https://mailarchive.ietf.org/arch/msg/spring/u1AzYFpDe-AhIxXdih2BEIz65Bk/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2Fu1AzYFpDe-AhIxXdih2BEIz65Bk%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932632328&sdata=kN2%2FKe5EHt1bWtcK9f0zQq07mMLQVK4HIZ5spUNEHzY%3D&reserved=0>

Thanks

Andrew

Brian

> https://trac.ietf.org/trac/6man/ticket/66<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2F6man%2Fticket%2F66&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932632328&sdata=QkZQTC9gfA7bjmANWqUIhQk4%2Fr5ECkz1hXkUbIMeHxw%3D&reserved=0> <https://urldefense.com/v3/__https:/trac.ietf.org/trac/6man/ticket/66__;!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_$<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftrac.ietf.org%2Ftrac%2F6man%2Fticket%2F66__%3B!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932642321&sdata=KAJ6gn4hxCzDjblX8IigFrkB2J8uIz%2BesLVfPWqTXqk%3D&reserved=0>>
>
>
>
> Darren
>
>
>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932652318&sdata=9pahh101WJHVw5AQrT8lBMawkyZzHXOsVvK5VIk%2B82A%3D&reserved=0>

---

From: Andrew Alston <[email-masked]>
Date: Thu, 12 Mar 2020 15:35:45 +0000

Jim

I would argue the answer to that is in the name – loopback

Thanks

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Andrew Alston
Sent: Thursday, March 12, 2020 4:26 AM
To: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Brian,

Thanks

Andrew

Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 Mar 2020 07:00:56 +1100

> (e.g., see the example on /127s for point-to-point links)

Although SLAAC/EUI-64s might have triggered the work on what became
RFC7136, I've never seen it as SLAAC specific.

"

   In all cases, the bits in an IID have no generic semantics; in other
   words, they have opaque values.  In fact, the whole IID value MUST be
   viewed as an opaque bit string by third parties, except possibly in
   the local context.

"

RFC4291 is where forming addresses from EUI-64s is specified, and that
isn't SLAAC specific - there is no mention of SLAAC at all.

I've more generally thought that RFC7136 was saying that while a packet is
in-flight, the IID portion only has forwarding semantics, in addition to
the prefix and subnet fields, which is and makes it consistent with longest
match all 128 bits BCP 198 for unicast forwarding.

Any other semantics in addresses are limited to and shared by the original
packet source host and the final packet destination host. This, for
example, permits addresses to be used as anycast function identifiers once
the packet arrives at the final destination host.

So there is clear separation between the purpose of the network -
forwarding to reach the specified destination - and the destination host -
processing of the packet to serve the original, typically application,
purpose of the original source host sending it.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 Mar 2020 07:20:53 +1100

> interface attaches to in your opinion?
RFC 4291 provides a definition.

  "The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
   It may be used by a node to send an IPv6 packet to itself.  It must
   not be assigned to any physical interface.  It is treated as having
   Link-Local scope, and may be thought of as the Link-Local unicast
   address of a virtual interface (typically called the "loopback
   interface") to an imaginary link that goes nowhere."

Regards,
Mark.

>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Andrew Alston
> *Sent:* Thursday, March 12, 2020 4:26 AM
> *To:* Brian E Carpenter <[email-masked]>; Darren Dukes
> (ddukes) <[email-masked]>; Ron Bonica <
> rbonica=[email-masked]>
> *Subject:* Re: [spring] Draft-ietf-spring-network-programming ipv6
> addressing architecture - was draft-ietf-6man-segment-routing-header-26
> violating RFC4291, IPv6 Addressing Architecture?
>
>
>
> Brian,
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2Fu1AzYFpDe-AhIxXdih2BEIz65Bk%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932632328&sdata=kN2%2FKe5EHt1bWtcK9f0zQq07mMLQVK4HIZ5spUNEHzY%3D&reserved=0>
>
>
>
> (ddukes) <[email-masked]>; Ron Bonica <
> rbonica=[email-masked]>
> > https://trac.ietf.org/trac/6man/ticket/66
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2F6man%2Fticket%2F66&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932632328&sdata=QkZQTC9gfA7bjmANWqUIhQk4%2Fr5ECkz1hXkUbIMeHxw%3D&reserved=0>
> <
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftrac.ietf.org%2Ftrac%2F6man%2Fticket%2F66__%3B!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932642321&sdata=KAJ6gn4hxCzDjblX8IigFrkB2J8uIz%2BesLVfPWqTXqk%3D&reserved=0>
> >
> >
> >
> >
> > Darren
> >
> >
> >
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932652318&sdata=9pahh101WJHVw5AQrT8lBMawkyZzHXOsVvK5VIk%2B82A%3D&reserved=0>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Mar 2020 15:49:14 +1300

(General comment: I am disciplining myself to minimise responses on this topic.)

> So – we establish that indeed – SRv6 SID’s are IPv6 addresses – there is no two ways about it – they go into the destination field.  This is contrary to what Robert argued in an email found at http…

So it seems. But the term "SID" seems a bit slippery, even in its definition in RFC8402. However, as far as the IPv6 routing system goes, an address is 128 bits long and cannot be otherwise.

> Section 2 of RFC4291 states that IPv6 addresses are identifiers for interfaces and sets of interfaces – where an interface is defined in RFC2460 as a “node’s attachment to a link”.  This document c…

Yet the packet has been delivered to the host via an interface, which means that it must be associated with that interface in some other node's neighbour cache. That's how it works for any address, even if it's associated with the loopback interface.

I think that what may be going on here is that the implementations implicitly handle SID-addresses exactly as if they were associated with the loopback interface, because they have to, otherwise nothing would work. But once the SID gets into the NP logic, it's no longer viewed as an IP address at all, because it might just as well have come from SRV-over-MPLS or something. Maybe. Just hand-waving here.
 
> In section 3.1 – this talks about the Locator – this is entirely compliant with section 2.5 of RFC4291 – however – the function and arguments section of this – have no relation to interface ID’s –…

Well, interface IDs are actually invisible in the routing system anyway. Ultimately we route on (the longest match with) 128 bits.
  
>    global unicast address in this case is:

I wonder why that informational RFC isn't Historic? The current standards-track text on that point is in RFC4291, but is updated by RFC7136 to make EUI-64 optional and by RFC8064 to make EUI-64 a SHOULD NOT. It's just a shame that we couldn't agree on the wording of 4291bis.
 
> I fail to see how defining a function and arguments in the way this document describes are compliant with this.  Now, it can also be argued that there are many implementations that violate these sp…

As somebody else pointed out, RFC7136 is pretty emphatic that the bits in an IID should have no semantics. But (as far as I know) that isn't how IPv6-SIDs work. As long as the routing protocols can treat them as opaque /128 values, it seems OK.

Regards
    Brian
 
> *From:*Brian E Carpenter <[email-masked]>
> *To:* Andrew Alston <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
> *Subject:* Re: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
> 
>  
> 
>> *From: *"Darren Dukes (ddukes)" <[email-masked] <mailto:[email-masked]>>
>> *To: *Ron Bonica <rbonica=[email-masked] <mailto:rbonica=[email-masked]>>
>> *Cc: *Andrew Alston <[email-masked] <mailto:[email-masked]>>, 6man WG <[email-masked] <mailto:[email-masked]>>
>> On Mar 11, 2020, at 2:55 PM, Ron Bonica <rbonica=[email-masked] <mailto:rbonica=[email-masked] <mailto:rbonica=[email-masked]%20%3cmailto:rbonica=[email-masked]>>> wrote:
>>
>>  
>>
>> Darren,
>>
>>  
>>
>> *From:* ipv6 <[email-masked] <mailto:[email-masked] <mailto:[email-masked]%20%3cmailto:[email-masked]>>> *On Behalf Of *Darren Dukes (ddukes)
>> *To:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <[email-masked] <mailto:[email-masked] <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>> *Cc:* 6man WG <[email-masked] <mailto:[email-masked] <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>> 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]>