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

[Naveen Kottapalli <[e-mail]>]

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