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

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

>> 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:[e-mail]]
> Sent: Tuesday, November 20, 2018 12:02 PM
> To: Naveen Kottapalli <[e-mail]>
> Cc: Templin (US), Fred L <[e-mail]>; Ole Troan <[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-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 <[e-mail]>
> > 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 <
> >> [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.
> >>
> > 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 <
> >>>> [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
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >