Re: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
otroan@employees.org Thu, 12 March 2020 08:44 UTC
Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853983A135E; Thu, 12 Mar 2020 01:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7ff9GoOL8jZ; Thu, 12 Mar 2020 01:44:47 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B863A1389; Thu, 12 Mar 2020 01:44:47 -0700 (PDT)
Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id E96934E11BBD; Thu, 12 Mar 2020 08:44:45 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 24A972DCA1D6; Thu, 12 Mar 2020 09:44:43 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
From: otroan@employees.org
In-Reply-To: <DBBPR03MB541585909C4D92325A69F1EFEEFD0@DBBPR03MB5415.eurprd03.prod.outlook.com>
Date: Thu, 12 Mar 2020 09:44:42 +0100
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Darren Dukes (ddukes)" <ddukes@cisco.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B50496C-F75D-4858-8FAA-947E2A38136B@employees.org>
References: <4F4FF5EC-690F-4C09-9101-98AB2DDFDE0C@liquidtelecom.com> <a38c3197-2513-4af6-cb4f-a0a96c082cb9@gmail.com> <DBBPR03MB541585909C4D92325A69F1EFEEFD0@DBBPR03MB5415.eurprd03.prod.outlook.com>
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/WGxBGfoArKFN47xz3yqSg82NtmM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 08:44:57 -0000
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 <Andrew.Alston@liquidtelecom.com> 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: > > 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 <brian.e.carpenter@gmail.com> > Sent: Thursday, 12 March 2020 00:30 > To: Andrew Alston <Andrew.Alston@liquidtelecom.com>; Darren Dukes (ddukes) <ddukes@cisco.com>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> > Cc: spring@ietf.org; 6man WG <ipv6@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)" <ddukes@cisco.com> > > *Date: *Wednesday, 11 March 2020 at 22:03 > > *To: *Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> > > *Cc: *Andrew Alston <Andrew.Alston@liquidtelecom.com>, 6man WG <ipv6@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.net@dmarc.ietf.org <mailto:rbonica=40juniper.net@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-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>> *On Behalf Of *Darren Dukes (ddukes) > > *Sent:* Tuesday, March 10, 2020 12:07 PM > > *To:* EXT-Andrew.Alston@liquidtelecom.com <mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com <mailto:Andrew.Alston@liquidtelecom.com>> > > *Cc:* 6man WG <ipv6@ietf.org <mailto:ipv6@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://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 <Andrew.Alston@liquidtelecom.com <mailto:Andrew.Alston@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 > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- Draft-ietf-spring-network-programming ipv6 addres… Andrew Alston
- Re: [spring] Draft-ietf-spring-network-programmin… Fernando Gont
- Re: Draft-ietf-spring-network-programming ipv6 ad… Brian E Carpenter
- Re: [spring] Draft-ietf-spring-network-programmin… Bob Hinden
- Re: [spring] Draft-ietf-spring-network-programmin… Brian E Carpenter
- Re: [spring] Draft-ietf-spring-network-programmin… Darren Dukes (ddukes)
- Re: Draft-ietf-spring-network-programming ipv6 ad… Darren Dukes (ddukes)
- RE: Draft-ietf-spring-network-programming ipv6 ad… Andrew Alston
- Re: Draft-ietf-spring-network-programming ipv6 ad… otroan
- Re: [spring] Draft-ietf-spring-network-programmin… Robert Raszuk
- Re: Draft-ietf-spring-network-programming ipv6 ad… Mark Smith
- Re: [spring] Draft-ietf-spring-network-programmin… Sander Steffann
- RE: Draft-ietf-spring-network-programming ipv6 ad… Andrew Alston
- Re: [spring] Draft-ietf-spring-network-programmin… Fernando Gont
- RE: Draft-ietf-spring-network-programming ipv6 ad… James Guichard
- RE: Draft-ietf-spring-network-programming ipv6 ad… Andrew Alston
- Re: [spring] Draft-ietf-spring-network-programmin… Mark Smith
- Re: [spring] Draft-ietf-spring-network-programmin… Mark Smith
- Re: Draft-ietf-spring-network-programming ipv6 ad… Brian E Carpenter