RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 20 November 2018 20:42 UTC
Return-Path: <Fred.L.Templin@boeing.com>
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 DEB66130DC6; Tue, 20 Nov 2018 12:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 7OTHWrm7HxFq; Tue, 20 Nov 2018 12:42:41 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DA512785F; Tue, 20 Nov 2018 12:42:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id wAKKgetJ019982; Tue, 20 Nov 2018 13:42:40 -0700
Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id wAKKgVpK019938 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 20 Nov 2018 13:42:31 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 20 Nov 2018 12:42:30 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1367.000; Tue, 20 Nov 2018 12:42:30 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Naveen Kottapalli <naveen.sarma@gmail.com>
CC: Ole Troan <otroan@employees.org>, v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Subject: RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
Thread-Topic: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
Thread-Index: AQHUemuywmmsBQddKEW1fr9sznfAQqVMbZjAgAFwigCAAAgHoIAAmmKA//+EguCAAIuKgP//emnAgACWtgD//4eZIABeBgcLAACJLRABAKRRGQABPEAA
Date: Tue, 20 Nov 2018 20:42:30 +0000
Message-ID: <70511fed2c55446798ed7f5cd4e76e83@XCH15-06-08.nw.nos.boeing.com>
References: <154155148848.30897.17784898234776136208.idtracker@ietfa.amsl.com> <951A1E82-3BE3-456A-9992-32F6FFB78929@employees.org> <6c2f699aec1c4d1ebb76cb1b2bfe7d05@XCH15-06-08.nw.nos.boeing.com> <0F27B4DF-52FB-4C5A-BCDF-CFABD363F95D@employees.org> <a446f89d19954278a8ff09ac9850acd7@XCH15-06-08.nw.nos.boeing.com> <90b22d50-6100-a45c-1663-da80fede8126@gmail.com> <8d3cab11459e4276825c644154fd1b0e@XCH15-06-08.nw.nos.boeing.com> <c31171cd-8de1-d613-60fb-7b4c5d63c831@gmail.com> <CANFmOtmpNjxfpPF-2JL1QMEo2Dkh1owpVtgRxWtgve8-SmxT2A@mail.gmail.com> <7cfcb7b21b1f498e880d00d11b0adfad@XCH15-06-08.nw.nos.boeing.com> <79f505f6-94e6-4570-0e77-d21e0d7c77e1@gmail.com> <CANFmOtmu6jsSx6z3mZRTkM95D-c6i=D7OJTDKgYCuA76-N9qXQ@mail.gmail.com> <995ff903-1df6-225a-8aaa-813db45d1dd2@gmail.com> <CANFmOt=VYMgPTL1SH6hsBCDEtZBAL9v_1k5a2QW0M7A-TRaXPA@mail.gmail.com> <50c10934-6ca8-00d0-73bd-cc6cf19ed213@gmail.com> <CANFmOt=DSi0Y=jBoNJFtFaJHDzFJ+61ZAN0L2a94efnfMBMh1w@mail.gmail.com> <57b98143-1db3-9fcb-6d2b-4a0937ec00c9@gmail.com>
In-Reply-To: <57b98143-1db3-9fcb-6d2b-4a0937ec00c9@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 0BF1E23DE989C7FBE03F116145BF26D773422570426E535C02D30F9FC610BC5B2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/N56x6KCPI-96p-t0s_IBnFPIS3Y>
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: Tue, 20 Nov 2018 20:42:45 -0000
>> Naveen] That is what my draft is proposing. > > I must have missed that in the text. Which section? This has already been covered for a long time in 'draft-templin-6man-dhcpv6-ndopt', which Naveen's draft borrows from. From the introduction: 'This document proposes methods for combining stateless and stateful operations into a single, unified exchange based on IPv6ND messaging extensions. It notes that stateful exchanges should include: o an explicit request for stateful information o the identity of the requesting node o a transaction ID that the requesting node can use to match replies with their corresponding requests o any security parameters necessary for the requesting node to establish its authorization to receive stateful information' And, then in Section 3.3 it says: 'The RS message can include a Nonce option [RFC3971] to provide a transaction identifier for matching RS and RA messages.' Thanks - Fred > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, November 20, 2018 12:02 PM > To: Naveen Kottapalli <naveen.sarma@gmail.com> > Cc: Templin (US), Fred L <Fred.L.Templin@boeing.com>; Ole Troan <otroan@employees.org>; v6ops list <v6ops@ietf.org>; 6man WG > <ipv6@ietf.org> > Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt > > On 2018-11-21 07:08, Naveen Kottapalli wrote: > > Hello Brian, > > > > Comments inline. > > The same from me... > > > > > Yours, > > Naveen. > > > > > > On Mon, 19 Nov 2018 at 01:04, Brian E Carpenter <brian.e.carpenter@gmail.com> > > wrote: > > > >> On 2018-11-19 06:53, Naveen Kottapalli wrote: > >>> Hello Brian, > >>> > >>> Please find comments inline. > >>> > >>> Thanks & Regards, > >>> Naveen > >>> > >>> > >>> On Sun, 18 Nov 2018, 01:16 Brian E Carpenter < > >> brian.e.carpenter@gmail.com > >>> wrote: > >>> > >>>> On 2018-11-18 06:40, Naveen Kottapalli wrote: > >>>>> Hello Brian, > >>>>> > >>>>> Whether it's a prefix delegation or allocation, it's a resource > >>>> allocation > >>>>> from both the host / CPE or a router perspective. Do you see that > >> missing > >>>>> transaction ID in RS/RA as a mandatory requirement for SLAAC to > >> function > >>>>> even with proposed protocol? > >>>> > >>>> Yes. Without a transaction ID, a nonce, or some equivalent mecahnism > >>>> there is no way to correlate the request and response unambiguously. > >>>> In particular your proposal doesn't distinguish between an unsolicited > >>>> unicast RA announcing a prefix and a solicited unicast RA assigning a > >>>> prefix, which are totally different actions. > >>>> > >>> > >>> Naveen] Am not yet clear on why we should distinguish between unsolicited > >>> and solicited RA. Do we need to distinguish like that? As per my > >> current > >>> knowledge any prefix will be allocated or assigned only when RS is > >> received > >>> from node and didn't come across an use case of a router assigning the > >>> prefix unsolicited. > >> > >> Today, no prefixes are assigned on receipt of RS, so I don't understand > >> your argument. Prefixes are assigned either by configuration or > >> by DHCPv6-ND. > >> > > Naveen] I would see this as partially true. As one of the forum member > > mentioned, RA does more than advertising the prefix. Even in our gateway > > too prefixes are assigned to subscribers when a RS is received from devices > > directly tunneled over GRE. > > Can you explain that in more detail? Is that how a homenet would > get a /48 for example? > > > Consider the case of described in RFC8273, > > where the prefixes are assigned to devices upon receipt of RS. So, it > > needn't always be a configuration or DHCPv6 for the prefix allocation or > > assignment. > > There is a very fundamental difference between RFC8273 and your proposal. > In RFC8273 the target host *does not know* that the /64 prefix is > single-use. In no way is that prefix delegated to the host; it is > simply the prefix it may use for forming its own address. (It is not > even marked as an on-link prefix, since the L bit is specified to be > off.) > > >>> So, since both node and router will have context of > >>> prefix assigned, we can reserve constant numbers like 0 or 0xFFFFFFFF for > >>> nonces included in unsolicited RA. I can add a text saying the use of > >> this > >>> in next version of draft. > >> > >> But there is no field in an RA for a nonce. > >> > > Naveen] That is what my draft is proposing. > > I must have missed that in the text. Which section? > > > > >> > >>>> > >>>> Handing out resources with a single message exchange is bad practice > >>>> anyway; if the response is lost, the resource is lost for ever. You > >> really > >>>> need some kind of two-phase commit. > >>> > >>> > >>> Naveen] Do we really need this? There are equal amount of chances of > >> losing > >>> a RA or DHCPv6 Avertise / Reply. A two way commit will induce more delay > >>> in the resource allocation procedure and it might not be required as the > >>> retry mechanism is in place. > >> > >> A retry mechanism is not safe. It might lead to the same prefix being > >> allocated twice due to lost messages or a race condition. I suggest > >> that you read up on two-phase commit, which requires a minimum of > >> four messages. > >> > > Naveen] Agree that a two-phase commit is considerably safe. This can be a > > subject of future study. > > > >> > >>> I would rather say that the resource is never > >>> lost. That is because, from router perspective the resource is allocated > >>> even if the message doesn't reach the solicited node. A device will > >> anyway > >>> retry and a router will always sends a response with the same allocated > >>> prefix. > >> > >> But it never knows if the response was received, which is a requirement > >> for safe resource allocation. > >> > >>> > >>> The standard RA doesn't have this > >>>> problem because it's an *announcement* not an *assignment*, and it is > >>>> repeated at a reasonable frequency, so a lost message doesn't matter. > >>>> > >>> > >>> Naveen] I don't see a difference between the two in my draft. So, didn't > >>> want to distinguish between the two i.e. standard and the one proposed in > >>> this draft. What kind of difference do you see? > >> > >> As described above. An existing RA says "I route this prefix". > >> Your RA says "You can use this prefix." That is an utterly different > >> statement. > >> > > Naveen] As mentioned in above example, not all routers might not be > > eligible to say that "You can use this prefix" (for example, whoever didn't > > go for a < /64 prefix allocation). There must not be a big change in > > existing behavior. Can you please help me understand your comment? > > Only a router that owns a pool of prefixes can delegate them using > DHCPv6-PD, and I don't see why it would be any different for your > proposal. > > >> > >>>> (A device ID, as also used in DHCPv6, doesn't seem to be essential > >>>> in the same way, but would be needed if an authorisation or > >>>> logging mechanism is needed, i.e. to answer "Is it OK to give a /56 > >>>> prefix to this box?" or "Which box got that prefix?" you need an > >>>> identifier for the box.) > >>>> > >>> Naveen] This is mentioned in my draft about whether the routers > >>> configuration allows /56 prefix allocation or not. If not, a router can > >> log > >>> using the mac address of the device. We too do the same thing in our > >>> router. > >> > >> /56 is only an example of course. Any length prefix could be requested. > >> Yes, if you trust the MAC address you could use that as an ID. But > >> if you use DHCPv6 that problem is already solved. > > > > Naveen] As I mentioned earlier in my mail, DHCPv6 is not a usable solution > > in my case and across all platforms (might be for others too). That is > > reason we see so many drafts were invented by honorable members of the > > group to bridge the gap in SLAAC itself. > > If the need is to reproduce all DHCPv6 features inside RS/RA, is there > really a saving in complexity and footprint? > > Brian > > > > >> > >> Brian > >> > >>> > >>>> > >>>>> > >>>>> Also am not sure if am wrong in quoting that *delegation* is the term > >>>>> coined to mimic SLAAC behavior of prefix allocation from a sub pool. > >>>> > >>>> "Delegation", "allocation" or "assignment" are all fundamentally the > >>>> same, and are all different from the simple announcement function of a > >>>> normal RA. Your proposal changes an announcement protocol into a > >>>> management protocol. That's the thing that Ole is asking you to justify. > >>>> Why do that? > >>>> > >>>> Brian > >>>> > >>>>> > >>>>> Please correct me if am wrong. > >>>>> > >>>>> Thanks & Regards, > >>>>> Naveen > >>>>> > >>>>> On Fri, 16 Nov 2018, 01:07 Brian E Carpenter < > >>>> brian.e.carpenter@gmail.com > >>>>> wrote: > >>>>> > >>>>>> On 2018-11-16 06:43, Templin (US), Fred L wrote: > >>>>>>> Naveen, > >>>>>>> > >>>>>>> The idea of including a DHCPv6 message option in IPv6 ND RS/RA > >> messages > >>>>>> requires > >>>>>>> a *new option* to go along with an already existing protocol (namely, > >>>>>> DHCPv6). > >>>>>>> The idea your draft builds on uses an existing IPv6 ND option but > >>>>>> requires a > >>>>>>> *new protocol* that is not fully specified in your draft yet. My > >>>> feeling > >>>>>> is that once > >>>>>>> the new protocol is fully fleshed out it would look very much like > >>>>>> DHCPv6, and > >>>>>>> some people have said that they do not want new protocols. > >>>>>>> > >>>>>>> I am actually beyond the point of caring whether the protocol should > >> be > >>>>>> DHCPv6, > >>>>>>> but do we also need a new non-DHCPv6 protocol that looks a lot like > >>>>>> DHCPv6? > >>>>>> > >>>>>> I realised when looking at this draft that DHCPv6 has one property > >> that > >>>>>> RS/RA completely lacks: a transaction ID. I don't see how we can build > >>>>>> any kind of resource allocation mechanism without some form of > >>>>>> transactional > >>>>>> integrity. Prefix delegation is of course a form of resource > >> allocation. > >>>>>> So that is a fundamental difference between DHCPv6 and RS/RA. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>>> > >>>>>>> Thanks - Fred > >>>>>>> > >>>>>>> From: Naveen Kottapalli [mailto:naveen.sarma@gmail.com] > >>>>>>> Sent: Thursday, November 15, 2018 9:18 AM > >>>>>>> To: Brian E Carpenter <brian.e.carpenter@gmail.com> > >>>>>>> Cc: Templin (US), Fred L <Fred.L.Templin@boeing.com>; > >>>>>> otroan@employees.org; v6ops list <v6ops@ietf.org>; 6man WG < > >>>> ipv6@ietf.org> > >>>>>>> Subject: Re: [v6ops] New Version Notification for > >>>>>> draft-naveen-slaac-prefix-management-00.txt > >>>>>>> > >>>>>>> Hello all, > >>>>>>> > >>>>>>> To be honest, there is no intention to compete with other existing > >>>>>> protocols. I see that SLAAC has got some gaps w.r.t the functionality > >>>> and > >>>>>> the same is covered in the draft. And I see the cases where this > >> draft > >>>>>> solves real time problems where the existing bridge itself is not > >>>> usable. > >>>>>>> > >>>>>>> @Ole / @Fred / others: If a device soliciting something from the > >> router > >>>>>> using RS is considered as intruding into other territory, IMHO it's > >> very > >>>>>> unfair way of evaluating. For that matter whether a PIO is included > >> in > >>>> RS > >>>>>> or not, a device is soliciting the information from router. When this > >>>>>> draft solves the problems it cannot be put down just by saying it as a > >>>>>> redundant to another standard, while actually it is not. > >>>>>>> > >>>>>>> If a device soliciting required information using the existing > >> protocol > >>>>>> standards without new message types or option types or flags itself is > >>>>>> treated as a wrapper or redundant for other standards, aren't there > >>>>>> overlapping options in both SLAAC and DHCPv6 that can be sent to the > >>>>>> devices? For that matter what about the complete SLAAC and DHCPv6? > >> Am > >>>> I > >>>>>> wrong in quoting that both DHCPv6 and SLAAC are redundant protocols to > >>>> each > >>>>>> other? > >>>>>>> > >>>>>>> I also agree that multiple attempts were made by many respected > >> members > >>>>>> of the forum to bring in similar changes to whatever my current draft > >>>>>> suggested. But not sure why they couldn't become standards. It shows > >>>> the > >>>>>> need of devices that are looking for a solution and am sure people > >> keep > >>>>>> inventing round-about solutions for the same. > >>>>>>> > >>>>>>> If someone sees a problem in mentioning DHCPv6 inside the draft, > >> please > >>>>>> suggest another change for that. > >>>>>>> > >>>>>>> I understand that the forum has finite reservations on providing > >>>>>> extensions to existing protocols. But I request the forum and WG > >>>> chairs to > >>>>>> evaluate this draft fairly and technically. > >>>>>>> > >>>>>>> Yours, > >>>>>>> Naveen. > >>>>>>> > >>>>>>> > >>>>>>> On Wed, 14 Nov 2018 at 03:31, Brian E Carpenter < > >>>>>> brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> > >> wrote: > >>>>>>> in line.. > >>>>>>> On 2018-11-14 09:34, Templin (US), Fred L wrote: > >>>>>>>> Hi Brian, > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com > >> <mailto: > >>>>>> brian.e.carpenter@gmail.com>] > >>>>>>>>> Sent: Tuesday, November 13, 2018 11:37 AM > >>>>>>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto: > >>>>>> Fred.L.Templin@boeing.com>>; Ole Troan <otroan@employees.org<mailto: > >>>>>> otroan@employees.org>> > >>>>>>>>> Cc: v6ops list <v6ops@ietf.org<mailto:v6ops@ietf.org>>; 6man WG < > >>>>>> ipv6@ietf.org<mailto:ipv6@ietf.org>> > >>>>>>>>> Subject: Re: [v6ops] New Version Notification for > >>>>>> draft-naveen-slaac-prefix-management-00.txt > >>>>>>>>> > >>>>>>>>> On 2018-11-14 07:52, Templin (US), Fred L wrote: > >>>>>>>>>> HI Ole, > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Ole Troan [mailto:otroan@employees.org<mailto: > >>>>>> otroan@employees.org>] > >>>>>>>>>>> Sent: Tuesday, November 13, 2018 10:36 AM > >>>>>>>>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto: > >>>>>> Fred.L.Templin@boeing.com>> > >>>>>>>>>>> Cc: Naveen Kottapalli <naveen.sarma@gmail.com<mailto: > >>>>>> naveen.sarma@gmail.com>>; 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org > >>>>>> ; > >>>>>> v6ops list <v6ops@ietf.org<mailto:v6ops@ietf.org>> > >>>>>>>>>>> Subject: Re: [v6ops] New Version Notification for > >>>>>> draft-naveen-slaac-prefix-management-00.txt > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> On 13 Nov 2018, at 19:25, Templin (US), Fred L < > >>>>>> Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Ole, > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: Ole Troan [mailto:otroan@employees.org<mailto: > >>>>>> otroan@employees.org>] > >>>>>>>>>>>>> Sent: Tuesday, November 13, 2018 9:38 AM > >>>>>>>>>>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto: > >>>>>> Fred.L.Templin@boeing.com>> > >>>>>>>>>>>>> Cc: Naveen Kottapalli <naveen.sarma@gmail.com<mailto: > >>>>>> naveen.sarma@gmail.com>>; 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org > >>>>>> ; > >>>>>> v6ops list <v6ops@ietf.org<mailto:v6ops@ietf.org>> > >>>>>>>>>>>>> Subject: Re: [v6ops] New Version Notification for > >>>>>> draft-naveen-slaac-prefix-management-00.txt > >>>>>>>>>>>>> > >>>>>>>>>>>>> Fred, > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 13 Nov 2018, at 17:34, Templin (US), Fred L < > >>>>>> Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Ole, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: Ole Troan [mailto:otroan@employees.org<mailto: > >>>>>> otroan@employees.org>] > >>>>>>>>>>>>>>> Sent: Monday, November 12, 2018 11:57 PM > >>>>>>>>>>>>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto: > >>>>>> Fred.L.Templin@boeing.com>> > >>>>>>>>>>>>>>> Cc: Naveen Kottapalli <naveen.sarma@gmail.com<mailto: > >>>>>> naveen.sarma@gmail.com>>; 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org > >>>>>> ; > >>>>>> v6ops list <v6ops@ietf.org<mailto:v6ops@ietf.org>> > >>>>>>>>>>>>>>> Subject: Re: [v6ops] New Version Notification for > >>>>>> draft-naveen-slaac-prefix-management-00.txt > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Fred, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I agree to some extent that DHCPv6 is a format on wire. > >> But > >>>>>> am sure it would consume more resources at router to > >>>>>>>>> support > >>>>>>>>>>>>>>> DHCPv6 > >>>>>>>>>>>>>>>>> as a whole along with SLAAC. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Prefix delegation is quite different from SLAAC. > >>>>>>>>>>>>>>>>> Regardless this is water under the bridge. Since 2003. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> So I can understand this comment, the water under the bridge > >>>>>> refers to the > >>>>>>>>>>>>>>>> selection of DHCPv6 PD as the protocol for prefix > >> delegation. > >>>>>> Is that what > >>>>>>>>>>>>>>>> you were meaning to say? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Sure. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> OK, so you are saying that DHCPv6 is *the* chosen protocol for > >>>>>> Prefix Delegation > >>>>>>>>>>>>>> and there shall be no alternate IPv6 ND-based protocol in > >>>>>> addition to that. I don't > >>>>>>>>>>>>>> mind a statement like that, but would the community agree with > >>>> it? > >>>>>>>>>>>>> > >>>>>>>>>>>>> In general we as a community try to avoid providing multiple > >>>>>> equivalent solutions to the same problem. Sometimes we fail. > >>>>>>>>>>>> > >>>>>>>>>>>> But, do you assert that DHCPv6 is the one and only solution? > >>>>>>>>>>> > >>>>>>>>>>> I am saying that solving a problem that is already solved is a > >>>> waste > >>>>>> of time and resources. > >>>>>>>>>>> Now if you install could solve a problem where we don’t have a > >>>>>> satisfactory solution... > >>>>>>>>>> > >>>>>>>>>> OK, then I will say it - DHCPv6 is the one and only solution to > >>>>>> Prefix Delegation > >>>>>>>>>> *in cases where a dynamic Prefix Delegation protocol is needed*. > >> (I > >>>>>> add this > >>>>>>>>>> qualification because 'draft-templin-v6ops-pdhost' lists other > >>>>>> non-protocol > >>>>>>>>>> alternatives for a node receiving a prefix delegation.) > >>>>>>>>> > >>>>>>>>> I'm not disagreeing that DHCPv6-PD is the current IETF solution, > >> but > >>>>>> there > >>>>>>>>> are some subtleties: > >>>>>>>>> > >>>>>>>>> 1) Since there are no protocol police, you can't actually stop > >> people > >>>>>>>>> using some other method of prefix delegation, which would simply > >>>> appear > >>>>>>>>> to be an out-of-band or "manual" mechanism as far as the IETF > >>>> protocols > >>>>>>>>> are concerned. > >>>>>>>> > >>>>>>>> Right, I wanted to be careful in how I worded my message based on > >> our > >>>>>>>> knowledge of other non-router methods (including anima) which we > >>>>>>>> captured in 'draft-templin-v6ops-pdhost'. From that document: > >>>>>>>> > >>>>>>>> "10. Prefix Delegation Services > >>>>>>>> > >>>>>>>> Selection of prefix delegation services must be considered > >>>> according > >>>>>>>> to specific use cases. An example service is that offered by > >>>> DHCPv6 > >>>>>>>> [RFC3633]. An alternative service based on IPv6 ND messaging has > >>>>>>>> also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]. > >>>>>>>> > >>>>>>>> Other, non-router, mechanisms may exist, such as proprietary > >> IPAMs, > >>>>>>>> [I-D.ietf-anima-prefix-management] and > >>>>>>>> [I-D.sun-casm-address-pool-management-yang]." > >>>>>>>> > >>>>>>>> Does this still ring true, or do we need to make some adjustments > >>>> based > >>>>>>>> on these recent discussions? > >>>>>>> > >>>>>>> I think it's still true, although as Ole and I said, proposals such > >> as > >>>>>>> anima-prefix-management, CASM amd HNCP do recognize DHCPv6-PD as the > >>>>>>> boundary mechanism. On the other hand, naveen-slaac-prefix-management > >>>>>>> intentionally competes with DHCPv6-PD, which is a different > >>>> discussiion. > >>>>>>> > >>>>>>> Brian > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks - Fred > >>>>>>>> > >>>>>>>>> 2) We did think about this question a bit while developing > >>>>>>>>> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-07 > >>>>>>>>> (which is approved and in the RFC Editor queue waiting for missing > >>>>>>>>> references). The appendix A2 is supposed to show how a prefix > >>>>>>>>> management system would interface to DHCPv6-PD at the edges of an > >>>>>>>>> autonomic network. I think you'd find something similar in any sort > >>>>>>>>> of coordinated prefix management scheme. > >>>>>>>>> > >>>>>>>>> 3) A similar situation arises in HNCP: > >>>>>>>>> https://tools.ietf.org/html/rfc7788#section-6.3.4 > >>>>>>>>> > >>>>>>>>> Brian > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> The value proposition of something new, has to be different > >>>> than > >>>>>> “just different wrapping”. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> By "different wrapping", are you are talking about non-DHCPv6 > >>>>>> protocol proposals? > >>>>>>>>>>>>>> If not, if you mean to say that the idea of including a DHCPv6 > >>>>>> option in RS/RA messages > >>>>>>>>>>>>>> is "just a different wrapping", then that is not entirely > >> true. > >>>>>> By including both the IPv6 > >>>>>>>>>>>>>> ND and DHCPv6 functions in a single message exchange, there > >> are > >>>>>> fewer messages > >>>>>>>>>>>>>> and fewer round trips. That in itself is interesting. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Don’t really see that as interesting. You will not save a round > >>>>>> trip, since the two protocols don’t depend on each other. > >>>>>>>>>>>> > >>>>>>>>>>>> This gets us back to the M&O bits where there is a > >>>> cross-dependence > >>>>>> between the two > >>>>>>>>>>>> protocols. Historically, you are supposed to wait until the > >> RS/RA > >>>>>> exchange and check the > >>>>>>>>>>>> M&O bits before invoking DHCPv6 (two round trips). Are you > >> saying > >>>>>> that that is no longer > >>>>>>>>>>>> the case? Have we declared that the M&O bits are deprecated? > >>>>>>>>>>> > >>>>>>>>>>> DHCPv6 PD has never had any dependency on the M&O bits. PD is a > >>>>>> protocol between routers. > >>>>>>>>>> > >>>>>>>>>> OK, then let's ignore the M&O bits - I am fine with that. > >>>>>>>>>> > >>>>>>>>>>>> It is also important that there are fewer messages - two instead > >>>> of > >>>>>> four. That matters > >>>>>>>>>>>> a great deal on low end links. > >>>>>>>>>>> > >>>>>>>>>>> I would like to see the maths behind that. > >>>>>>>>>>> Use header compression then. > >>>>>>>>>> > >>>>>>>>>> It isn't only a question of how many bytes - the question is > >> moreso > >>>>>> how > >>>>>>>>>> many channel accesses are necessary. On some links, sending > >>>>>> everything in > >>>>>>>>>> a single channel access is less prone to collisions than requiring > >>>>>> multiple > >>>>>>>>>> channel accesses. > >>>>>>>>>> > >>>>>>>>>> Think about CB radio - after you say "breaker, breaker one-nine" > >> you > >>>>>> get > >>>>>>>>>> to say as much as you want (within reason) without having to > >> undergo > >>>>>>>>>> channel contention multiple times. (That is not to say that common > >>>>>> data > >>>>>>>>>> links function the same as CB radio, but they do have their CSMA > >>>>>> protocols > >>>>>>>>>> for making sure they don't step on someone else's transmission.) > >>>>>>>>>> > >>>>>>>>>>>>> Different wrapping. As in exactly same protocol semantics, just > >>>>>> options in ND instead of DHCP. > >>>>>>>>>>>> > >>>>>>>>>>>> No, the options in RS/RA are exactly DHCPv6 - they are not > >>>>>> different than DHCPv6. > >>>>>>>>>>>> That is the whole point. > >>>>>>>>>>> > >>>>>>>>>>> Right. I am sorry but I struggle getting why that is valuable. ND > >>>> is > >>>>>> also a one to many protocol. That’s not suitable for per-router > >>>>>>>>>>> delegation. > >>>>>>>>>> > >>>>>>>>>> IPv6 ND messages are permitted to be sent as unicast (one-to-one). > >>>> In > >>>>>> this > >>>>>>>>>> case, the presence of a DHCPv6 option in the RS message is > >>>> indication > >>>>>> that > >>>>>>>>>> the RA is to be returned via unicast. > >>>>>>>>>> > >>>>>>>>>> Thanks - Fred > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Cheers > >>>>>>>>>>> Ole > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks - Fred > >>>>>>>>>>>> > >>>>>>>>>>>>> Cheers > >>>>>>>>>>>>> Ole > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks - Fred > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> We are still struggling with “permissionless extensions” of > >> an > >>>>>> IPv6 network. Something that solved that problem, would be a > >>>>>>>>> lot > >>>>>>>>>>>>> more > >>>>>>>>>>>>>>> interesting to talk about. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Cheers, > >>>>>>>>>>>>>>> Ole > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> v6ops mailing list > >>>>>>>>>> v6ops@ietf.org<mailto:v6ops@ietf.org> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> v6ops mailing list > >>>>>>> v6ops@ietf.org<mailto:v6ops@ietf.org> > >>>>>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > >
- Fwd: New Version Notification for draft-naveen-sl… Naveen Kottapalli
- Re: New Version Notification for draft-naveen-sla… Fred Baker
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- Re: [v6ops] New Version Notification for draft-na… Fred Baker
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Fred Baker
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Fred Baker
- Re: [v6ops] New Version Notification for draft-na… Ted Lemon
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: New Version Notification for draft-naveen-sla… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- Re: [v6ops] New Version Notification for draft-na… Gert Doering
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Mikael Abrahamsson
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- RE: [v6ops] New Version Notification for draft-na… Mikael Abrahamsson
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Mikael Abrahamsson
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Mikael Abrahamsson
- Re: [v6ops] New Version Notification for draft-na… Mikael Abrahamsson
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Mikael Abrahamsson
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Michael Richardson
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- RE: [v6ops] New Version Notification for draft-na… Bernie Volz (volz)
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- Re: [v6ops] New Version Notification for draft-na… Fernando Gont
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- RE: [v6ops] New Version Notification for draft-na… Mikael Abrahamsson
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- Re: [v6ops] New Version Notification for draft-na… Ole Troan
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- RE: [v6ops] New Version Notification for draft-na… Templin (US), Fred L
- RE: [v6ops] New Version Notification for draft-na… Mikael Abrahamsson
- Re: [v6ops] New Version Notification for draft-na… Mark Smith
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Brian E Carpenter
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli
- Re: [v6ops] New Version Notification for draft-na… Alexandre Petrescu
- Re: [v6ops] New Version Notification for draft-na… Naveen Kottapalli