RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

["Templin (US), Fred L" <[e-mail]>]

BTW, those who are reading Naveen's draft should first read 'draft-templin-6man-dhcpv6-ndopt'.
The ideas of including an identification and transaction ID are thoroughly discussed there, as are
several different options for an RS/RA-based prefix delegation service. In fact, Naveen's draft is
really just a sub-case of 'draft-templin-6man-dhcpv6-ndopt' except with the added ambition to
define protocol message exchanges, i.e., a new protocol.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Templin (US), Fred L
> Sent: Monday, November 19, 2018 7:42 AM
> To: Brian E Carpenter <[e-mail]>; Naveen Kottapalli <[e-mail]>
> Cc: 6man WG <[e-mail]>; v6ops list <[e-mail]>
> Subject: RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
> 
> About node identifiers, the only identifier available via RS/RA is the link-layer
> address, e.g., through included SLLAOs. But, DHCPv6 offers many types of
> identifiers, including link-layer address, link-layer address plus time, enterprise
> number, etc. And, it can be extended to support any potential future identifier
> type. This may be important in networks where there is a requirement to have
> an enterprise-specific manner of managing node identifiers.
> 
> About transaction IDs, DHCPv6 messages include a transaction ID in the
> message header whereas RS/RA could include a Nonce option and use
> that as a transaction ID. Here, there may be an advantage for RS/RA since
> the Nonce option can be arbitrarily long whereas the DHCPv6 transaction
> ID is only 24 bits. Is this important?
> 
> Thanks - Fred
> 
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:[e-mail]]
> > Sent: Sunday, November 18, 2018 11:34 AM
> > To: Naveen Kottapalli <[e-mail]>
> > Cc: Templin (US), Fred L <[e-mail]>; [e-mail]; v6ops list <[e-mail]>; 6man WG
> > <[e-mail]>
> > Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
> >
> > 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 <[e-mail]
> > > 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.
> >
> > > 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.
> >
> > >>
> > >> 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.
> >
> > > 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.
> >
> > >> (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.
> >
> >     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 <
> > >> [e-mail]
> > >>> 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:[e-mail]]
> > >>>>> Sent: Thursday, November 15, 2018 9:18 AM
> > >>>>> To: Brian E Carpenter <[e-mail]>
> > >>>>> Cc: Templin (US), Fred L <[e-mail]>;
> > >>>> [e-mail]; v6ops list <[e-mail]>; 6man WG <
> > >> [e-mail]>
> > >>>>> 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 <
> > >>>> [e-mail]<mailto:[e-mail]>> wrote:
> > >>>>> in line..
> > >>>>> On 2018-11-14 09:34, Templin (US), Fred L wrote:
> > >>>>>> Hi Brian,
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Brian E Carpenter [mailto:[e-mail]<mailto:
> > >>>> [e-mail]>]
> > >>>>>>> Sent: Tuesday, November 13, 2018 11:37 AM
> > >>>>>>> To: Templin (US), Fred L <[e-mail]<mailto:
> > >>>> [e-mail]>>; Ole Troan <[e-mail]<mailto:
> > >>>> [e-mail]>>
> > >>>>>>> Cc: v6ops list <[e-mail]<mailto:[e-mail]>>; 6man WG <
> > >>>> [e-mail]<mailto:[e-mail]>>
> > >>>>>>> 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:[e-mail]<mailto:
> > >>>> [e-mail]>]
> > >>>>>>>>> Sent: Tuesday, November 13, 2018 10:36 AM
> > >>>>>>>>> To: Templin (US), Fred L <[e-mail]<mailto:
> > >>>> [e-mail]>>
> > >>>>>>>>> Cc: Naveen Kottapalli <[e-mail]<mailto:
> > >>>> [e-mail]>>; 6man WG <[e-mail]<mailto:[e-mail]
> > >>>> ;
> > >>>> v6ops list <[e-mail]<mailto:[e-mail]>>
> > >>>>>>>>> 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 <
> > >>>> [e-mail]<mailto:[e-mail]>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> Ole,
> > >>>>>>>>>>
> > >>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>> From: Ole Troan [mailto:[e-mail]<mailto:
> > >>>> [e-mail]>]
> > >>>>>>>>>>> Sent: Tuesday, November 13, 2018 9:38 AM
> > >>>>>>>>>>> To: Templin (US), Fred L <[e-mail]<mailto:
> > >>>> [e-mail]>>
> > >>>>>>>>>>> Cc: Naveen Kottapalli <[e-mail]<mailto:
> > >>>> [e-mail]>>; 6man WG <[e-mail]<mailto:[e-mail]
> > >>>> ;
> > >>>> v6ops list <[e-mail]<mailto:[e-mail]>>
> > >>>>>>>>>>> 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 <
> > >>>> [e-mail]<mailto:[e-mail]>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Hi Ole,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>>>> From: Ole Troan [mailto:[e-mail]<mailto:
> > >>>> [e-mail]>]
> > >>>>>>>>>>>>> Sent: Monday, November 12, 2018 11:57 PM
> > >>>>>>>>>>>>> To: Templin (US), Fred L <[e-mail]<mailto:
> > >>>> [e-mail]>>
> > >>>>>>>>>>>>> Cc: Naveen Kottapalli <[e-mail]<mailto:
> > >>>> [e-mail]>>; 6man WG <[e-mail]<mailto:[e-mail]
> > >>>> ;
> > >>>> v6ops list <[e-mail]<mailto:[e-mail]>>
> > >>>>>>>>>>>>> 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
> > >>>>>>>> [e-mail]<mailto:[e-mail]>
> > >>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
> > >>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> v6ops mailing list
> > >>>>> [e-mail]<mailto:[e-mail]>
> > >>>>> https://www.ietf.org/mailman/listinfo/v6ops
> > >>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------