On Fri, 13 Mar 2020, 02:36 Andrew Alston, <andrew.als...@liquidtelecom.com> wrote:
> Jim > > Given RFC2460 definition of a link I am wondering which “link” a loopback > 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. I would argue the answer to that is in the name – loopback > > > > Thanks > > > > Andrew > > > > > > > > *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Andrew Alston > *Sent:* Thursday, March 12, 2020 4:26 AM > *To:* Brian E Carpenter <brian.e.carpen...@gmail.com>; Darren Dukes > (ddukes) <ddu...@cisco.com>; Ron Bonica < > rbonica=40juniper....@dmarc.ietf.org> > *Cc:* spring@ietf.org; 6man WG <i...@ietf.org> > *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, > > > > 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/ > <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> > > > > 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 <brian.e.carpen...@gmail.com> > *Sent:* Thursday, 12 March 2020 00:30 > *To:* Andrew Alston <andrew.als...@liquidtelecom.com>; Darren Dukes > (ddukes) <ddu...@cisco.com>; Ron Bonica < > rbonica=40juniper....@dmarc.ietf.org> > *Cc:* spring@ietf.org; 6man WG <i...@ietf.org> > *Subject:* Re: Draft-ietf-spring-network-programming ipv6 addressing > architecture - was draft-ietf-6man-segment-routing-header-26 violating > RFC4291, IPv6 Addressing Architecture? > > > > On 12-Mar-20 09:53, Andrew Alston wrote: > > 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. > > 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 > > > > > > > > > Can we please have a proper discussion on this > > > > > > > > Thanks > > > > > > > > Andrew > > > > > > > > > > > > *From: *"Darren Dukes (ddukes)" <ddu...@cisco.com> > > *Date: *Wednesday, 11 March 2020 at 22:03 > > *To: *Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> > > *Cc: *Andrew Alston <andrew.als...@liquidtelecom.com>, 6man WG < > i...@ietf.org> > > *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=40juniper....@dmarc.ietf.org > <mailto:rbonica=40juniper....@dmarc.ietf.org>> 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 <ipv6-boun...@ietf.org <mailto:ipv6-boun...@ietf.org>> *On > Behalf Of *Darren Dukes (ddukes) > > *Sent:* Tuesday, March 10, 2020 12:07 PM > > *To:* ext-andrew.als...@liquidtelecom.com < > mailto:ext-andrew.als...@liquidtelecom.com > <ext-andrew.als...@liquidtelecom.com>> <andrew.als...@liquidtelecom.com > <mailto:andrew.als...@liquidtelecom.com > <andrew.als...@liquidtelecom.com%20%3cmailto:andrew.als...@liquidtelecom.com> > >> > > *Cc:* 6man WG <i...@ietf.org <mailto:i...@ietf.org>> > > *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://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 > > > > > > > > On Mar 9, 2020, at 3:18 PM, Andrew Alston <andrew.als...@liquidtelecom.com > <mailto:andrew.als...@liquidtelecom.com>> 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 > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > i...@ietf.org > > 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> > > -------------------------------------------------------------------- > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
