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

[Naveen Kottapalli <[e-mail]>]

Fred,

Being a new entrant in the forum with my draft, I will always be grateful
and acknowledge all the contributions.  In fact when I shared the draft
with your for review before submission, I sent to other senior members of
the forum.  For that matter @Ole, @Brian and whoever contributes their
names will be mentioned in upcoming version of my draft.

The reason why the advice of a similar thing to DHCPv6 DUID not taken was,
there is a fundamental difference between your draft and mine.  Your draft
proposes an unified approach of using DHCPv6 inside RS/RA, whereas my draft
says things can be done without DHCPv6 and any other new options or flags
too.

As you suggested me to cite, 'draft-templin-v6ops-pdhost' was cited in
respective places of my draft.  I don't know how more to acknowledge your
inputs in my draft.  If you feel that you are not acknowledged well, please
let me know what citation changes I can do in my draft to make you happy.

Finally, I would like to use this forum to improvise the draft more
technically.  You can directly message me.

Yours,
Naveen.


On Wed, 21 Nov 2018 at 20:18, Templin (US), Fred L <
[e-mail]> wrote:

> Hi Naveen,
>
>
>
> Also the idea of including a PIO in an RS message was originally mine as
> documented
>
> in my draft. Others may claim that they brought up the idea first, in
> which case I
>
> would be happy to honor their drafts. Your contribution was to not include
> any
>
> special bits in the RS PIO, which I agree is a good contribution. But, in
> hindsight,
>
> the idea should have been offered as a contribution to my draft even if
> the new
>
> protocol were to be documented in a separate draft.
>
>
>
> Also, I told you that you need to say something about node identifiers that
>
> parallels the DHCPv6 DUID for client and server IDs. You did not take my
>
> advice, and so that is a missing aspect of your proposal. The only
> candidate
>
> I am aware of for RS/RA is the SLLAO option, but that only gives link-layer
>
> address, and not any of the other type of identifiers offered by DHCPv6.
>
>
>
> Finally, your use case is already covered by ‘draft-templin-v6ops-pdhost’,
>
> which shows that DHCPv6 is applicable for the needs. If you think there
>
> is something different about your use case, that would be useful input
>
> for ‘draft-templin-v6ops-pdhost’ – but not material for a new draft.
>
> In any case, your document needs to cite ‘draft-templin-v6ops-pdhost’.
>
>
>
> Thanks - Fred
>
>
>
> *From:* Naveen Kottapalli [mailto:[e-mail]]
> *Sent:* Tuesday, November 20, 2018 6:12 PM
> *To:* Templin (US), Fred L <[e-mail]>
> *Cc:* Brian E Carpenter <[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
>
>
>
> Fred,
>
>
>
> Am aware that there are many open source softwares available. But the use
> cases that I mentioned in my draft holds good with what I mentioned below.
>
>
>
> I agree you suggested to include Nonce in RS / RA. That's why your
> contribution is recognized and your name is mentioned in the draft under
> *contributors*. But the whole idea of doing something with just RS / RA
> with out the need of new option flags or message types was from me which we
> discussed in call. If you want we can take this discussion we can take
> offline.
>
>
>
> Thanks & Regards,
>
> Naveen
>
>
>
> On Wed, 21 Nov 2018, 00:22 Templin (US), Fred L <[e-mail]
> wrote:
>
> Hi Naveen,
>
>
>
> 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.
>
>
>
> I don’t understand that; there are a number of very good
> publicly-available DHCPv6
>
> implementations that support prefix delegation today. And, to instrument
> RS/RA to
>
> perform prefix delegation under a new protocol would require a non-trivial
> amount
>
> of new code. So, why not just use DHCPv6?
>
>
>
> Thanks - Fred
>
>
>
> PS Please also do not forget that the idea of using the Nonce as a
> transaction ID
>
>       vessel came from me.
>
>
>
> *From:* Naveen Kottapalli [mailto:[e-mail]]
> *Sent:* Tuesday, November 20, 2018 10:09 AM
> *To:* Brian E Carpenter <[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
>
>
>
> Hello Brian,
>
>
>
> Comments inline.
>
>
> 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.  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.
>
>
> > 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.
>
>
> >>
> >> 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?
>
>
> >> (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.
>
>
>     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
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>