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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 