Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
Naveen Kottapalli <naveen.sarma@gmail.com> Tue, 20 November 2018 18:15 UTC
Return-Path: <naveen.sarma@gmail.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 BB321130E79; Tue, 20 Nov 2018 10:15:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 clrRy6RsUBkI; Tue, 20 Nov 2018 10:14:58 -0800 (PST)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20444130DCD; Tue, 20 Nov 2018 10:14:58 -0800 (PST)
Received: by mail-lf1-x132.google.com with SMTP id p6so2039217lfc.1; Tue, 20 Nov 2018 10:14:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UEAyHwQmhhPn9u0PtYtLBNVmBW1cQXlZ11gqu+uABco=; b=BchFsRPql1yjc733RISQiKPcpNwt9wO0lqOV38Ps5thiTuXoLgcg0KZLrXeq9DX9rQ HzDnV5RePgpH+SvhFtgKr1JrxBoWoFc8CUqx3PRGk4QNzFunyS8urK0B68lnzUci7bl+ icDsUKrwtthEPkPXYAGDy6qZIqGd+oNWBdGKveIxDy+cUa0wvVmvyz2y+/NAXvnsR+gG MI6zJ71ief87TXtox2VABuoExJOcc3qCLqFNYlTYAAMfxrcaalWuErTcxVdJDZj9YkXT MtolBgNa4im2Gc7icLqbngfXgOzreQPh7Fht7tWW5u13cIT3MLIY60hbUha38DtFuRsQ QT/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UEAyHwQmhhPn9u0PtYtLBNVmBW1cQXlZ11gqu+uABco=; b=jDEvk/4qijXzu589GzxOT5Nlynr2C30+c9rcQhjNns7eMnFk2oB1uTP63TBdEBSd53 uozxPLEau7q+JB1dXGKhV7Nj7u5rfllckWW1KtxJh/gCc+gbYZkaSNwDyXdD5uIUsDT+ v7VmEzqKZlw89StHeCYEGfhTZ/8wpi5xs5Kha7AhUu54KmBuVLMBHRscHChu5b+2fC7b a9/J3zrD9tM+0Bfjl4GTwLDHn1HgOx4yFOLAfH1qI2H9BzjVTrIRoE75i/L2k6GKm+gp X+XJBsdSbBiLTolSAYrROnfkmbYq5V55t4e5YRTcixvmooxCqxzUTE+ZFUfDXFiAskV0 DjeA==
X-Gm-Message-State: AGRZ1gIl6R0ASq1WKvjeLXlB1zhmJwc/oAV+M0cBwe+SMYYWQhfhFBql oKGsadq7vt0OkmjMsao02k/5cStqvXcGtl1/Q6FqBw==
X-Google-Smtp-Source: AJdET5fAgmAN/EPwS4KJ+9I6XrwZ/HmoLGON7oo4Qr3bd0kYr0x/zf3VeK+uc2zVm4UlxR/lHb1zkid0kMisl7oZ1D0=
X-Received: by 2002:a19:26ce:: with SMTP id m197mr1648191lfm.23.1542737696024; Tue, 20 Nov 2018 10:14:56 -0800 (PST)
MIME-Version: 1.0
References: <154155148848.30897.17784898234776136208.idtracker@ietfa.amsl.com> <CANFmOt=sY78+OYQpwwrCcPwP1ecjCuUrrtLLLe0BL_TYCO_XWQ@mail.gmail.com> <50038373-104D-479D-BE31-07CA2E9D5B5B@employees.org> <c2596a17-c6fa-99ea-6cf0-92c561493e49@gmail.com> <ADD42674-A31C-4536-8C17-431C7E48CD8A@employees.org> <CANFmOtm368Q1v3yH1YbKFMyJLKHVpLC8SVxqy7UQSvNW4FhGxg@mail.gmail.com> <7649E237-F41D-40B6-AAD5-9E5B641706E7@employees.org> <1efa098f9864456da58a3cfacd38026f@XCH15-06-08.nw.nos.boeing.com> <877CC739-F893-4A97-82F0-EE2705511343@employees.org> <5896d18ef2a044c0ba3484326d515e9e@XCH15-06-08.nw.nos.boeing.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> <AC92D677-9C6D-4BE4-8031-784FC513A482@employees.org> <CANFmOt=L106rU856L+B8xo2QsNc1HJHLok8c2iFPK-AE_FDZ5w@mail.gmail.com> <5CC32CFB-9F35-429D-B85A-0C7A2358D7EA@employees.org> <CANFmOtnzdZmduVLZtEp5VG0eonK6DmdSgh5tpCU8QFsBw40vUQ@mail.gmail.com> <7374C275-3FF0-4A5B-9E9E-4D9AA1220B63@employees.org>
In-Reply-To: <7374C275-3FF0-4A5B-9E9E-4D9AA1220B63@employees.org>
From: Naveen Kottapalli <naveen.sarma@gmail.com>
Date: Tue, 20 Nov 2018 23:44:32 +0530
Message-ID: <CANFmOt=hEFTGshtESkXFW8Cz2VbhbZU1S66De1UADS3gsULemQ@mail.gmail.com>
Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
To: Ole Troan <otroan@employees.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Templin, Fred L" <Fred.L.Templin@boeing.com>, v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005a6bd6057b1c9c58"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/UQuhwghfSdEIzhuOnLZZJ2I42OU>
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 18:15:08 -0000
Hello Ole, Refined my problem statements below. Please let me know if this is okay. Yours, Naveen. On Sun, 18 Nov 2018 at 23:46, Ole Troan <otroan@employees.org> wrote: > Naveen, > > I don’t understand the problem description below, nor why it would require > a different solution than any of those we already have. > > Does anyone else understand and can translate? > > Cheers > Ole > > On 18 Nov 2018, at 18:51, Naveen Kottapalli <naveen.sarma@gmail.com> > wrote: > > Hello Ole, > > Please find comments inline. > > Thanks & Regards, > Naveen > > > On Sat, 17 Nov 2018, 23:05 Ole Troan <otroan@employees.org wrote: > >> Hi Naveen, >> >> While the purpose of the proposal might be obvious to you, it might not >> be for the rest of us. >> >> Can you please describe the problem you are trying to solve? >> > Naveen] Below is the description of problems that are being tried to solve: > 1. Soliciting any prefix of pre configured length using RS / RA is not > currently supported. Lack of this forces the devices to be at disposal of > routers. We can have it implemented in both of our CPE and router. But the > solution wouldn't be compliant or inter-operable. The reason why existing > solutions can't be used is mentioned below. > 2. Lingering SLAAC prefixes at router. Some of the prefixes that were > assigned to hosts by our router are lingering though the host interface is > brought down and the prefix isn't used anymore. > 3. Devices lose ongoing data connectivity when mobility happens. Hosts > during mobility are losing the existing ongoing traffic sessions due to > SLAAC prefix change. This is because when the gateway detects mobility to a > different tunnel the existing session will be cleared and a new session > entry is created. During this process there is no guarantee that the same > prefix will be assigned back to the device. > >> >> Can you please describe how existing solutions do not solve your problem? >> > Naveen] All the prefixes were assigned using SLAAC and there is no > solution till date to solicit or release a specific prefix. It's not just > specific prefix, but the only existing solution to get a non /64 prefix is > only through DHCPv6, which can't be done in the CPE. > >> >> Note, “PD is not supported in SLAAC” is not the problem description I am >> hoping for. >> > Naveen] Unfortunately yes for the use case where prefix length less than > 64. I see this as more like soliciting a prefix pool. All the host / CPE > does is soliciting a prefix of desired length by including existing options > in RS. But why a host or CPE soliciting a prefix (which is already done by > them) without introducing new message types or options should be a problem? > >> >> Cheers >> Ole >> >> On 17 Nov 2018, at 18:16, Naveen Kottapalli <naveen.sarma@gmail.com> >> wrote: >> >> Hello Ole, >> >> Following are the things that am trying to solve. >> >> 1. I can't sell oranges when apples are asked for. >> 2. Improving SLAAC as a protocol by providing options like soliciting a >> prefix of certain length; releasing or declining a prefix (this is equally >> more important for the protocol perspective itself as a prefix is an >> important resource for the router). >> >> Please let me know which of the above points you think are not valid. >> >> Thanks & Regards, >> Naveen >> >> >> On Fri, 16 Nov 2018, 00:21 Ole Troan <otroan@employees.org wrote: >> >>> Naveen, >>> >>> Let me quote from RFC1958: >>> >>> 3.2 If there are several ways of doing the same thing, choose one. >>> If a previous design, in the Internet context or elsewhere, has >>> successfully solved the same problem, choose the same solution unless >>> there is a good technical reason not to. Duplication of the same >>> protocol functionality should be avoided as far as possible, without >>> of course using this argument to reject improvements. >>> >>> >>> What problem are you trying to solve with your proposal which isn’t >>> covered by existing solutions? >>> >>> Cheers, >>> Ole >>> >>> > On 15 Nov 2018, at 18:17, Naveen Kottapalli <naveen.sarma@gmail.com> >>> wrote: >>> > >>> > 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> 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] >>> > >> Sent: Tuesday, November 13, 2018 11:37 AM >>> > >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; Ole Troan < >>> otroan@employees.org> >>> > >> Cc: 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-14 07:52, Templin (US), Fred L wrote: >>> > >>> HI Ole, >>> > >>> >>> > >>>> -----Original Message----- >>> > >>>> From: Ole Troan [mailto:otroan@employees.org] >>> > >>>> Sent: Tuesday, November 13, 2018 10:36 AM >>> > >>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com> >>> > >>>> Cc: Naveen Kottapalli <naveen.sarma@gmail.com>; 6man WG < >>> ipv6@ietf.org>; v6ops list <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> wrote: >>> > >>>>> >>> > >>>>> Ole, >>> > >>>>> >>> > >>>>>> -----Original Message----- >>> > >>>>>> From: Ole Troan [mailto:otroan@employees.org] >>> > >>>>>> Sent: Tuesday, November 13, 2018 9:38 AM >>> > >>>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com> >>> > >>>>>> Cc: Naveen Kottapalli <naveen.sarma@gmail.com>; 6man WG < >>> ipv6@ietf.org>; v6ops list <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> wrote: >>> > >>>>>>> >>> > >>>>>>> Hi Ole, >>> > >>>>>>> >>> > >>>>>>>> -----Original Message----- >>> > >>>>>>>> From: Ole Troan [mailto:otroan@employees.org] >>> > >>>>>>>> Sent: Monday, November 12, 2018 11:57 PM >>> > >>>>>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com> >>> > >>>>>>>> Cc: Naveen Kottapalli <naveen.sarma@gmail.com>; 6man WG < >>> ipv6@ietf.org>; v6ops list <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 >>> > >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > >>> >>> > > >>> > >>> > _______________________________________________ >>> > v6ops mailing list >>> > 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