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

Hello Ole,

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.

Yours,
Naveen.

On Wed, 7 Nov 2018 at 14:59, Ole Troan <otroan@employees.org> wrote:

> >> We have been down this road before with
> >> https://tools.ietf.org/html/draft-haberman-ipngwg-auto-prefix-02
> >> Which is what led to RFC3633.
> >> Is your main motivation for this that there are some platforms that
> don’t implement DHCP PD?
> >
> > For what is worth: there are some platforms that do not and will not
> implement DHCPv6 PD.
>
> And I’m sure platforms that will not implement this…
> DHCPv6 PD is just a wire format specified between a requesting router and
> a delegating router directly connected.
> If you cannot implement that, it’s going to be hard to justify
> implementing the exact same, just with different naming.
>
> Ole
>
> >> Seems like the simple solution is to get those to implement it, rather
> than proposing a redundant standard that no-one has implemented yet.
> >> Unless I am misunderstanding where you want to go with this?
> >> Cheers,
> >> Ole
> >>> On 7 Nov 2018, at 07:59, Naveen Kottapalli <naveen.sarma@gmail.com>
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> IPv6 StateLess Address AutoConfiguration (SLAAC) in its current form
> doesn't offer following services like:
> >>>
> >>> 1. Soliciting a prefix of specific length.  The length could be of
> either /64 bit prefix (which would generally be solicited by nodes) or non
> /64 bit prefix (which would generally be solicited by either CPE or
> downstream routers).
> >>> 2. Releasing the prefixes that are no more used by the device.  This
> could be equally important for the routers who assigned the prefix to make
> the unused prefixes available for other nodes.
> >>>
> >>> To achieve the above objectives, a ND based message protocol is
> introduced in the below draft that does what a DHCPv6 node do; without
> introducing any new message types or new option types or flag types.
> >>>
> >>> Can you all share your thoughts on the draft?
> >>>
> >>> Thanks & Regards,
> >>> Naveen
> >>>
> >>>
> >>> ---------- Forwarded message ---------
> >>> From: <internet-drafts@ietf.org>
> >>> Date: Wed, Nov 7, 2018 at 6:14 AM
> >>> Subject: New Version Notification for
> draft-naveen-slaac-prefix-management-00.txt
> >>> To: Naveen Kottapalli <nkottapalli@benu.net>
> >>>
> >>>
> >>>
> >>> A new version of I-D, draft-naveen-slaac-prefix-management-00.txt
> >>> has been successfully submitted by Naveen Kottapalli and posted to the
> >>> IETF repository.
> >>>
> >>> Name:           draft-naveen-slaac-prefix-management
> >>> Revision:       00
> >>> Title:          IPv6 Stateless Prefix Management
> >>> Document date:  2018-11-06
> >>> Group:          Individual Submission
> >>> Pages:          15
> >>> URL:
> https://www.ietf.org/internet-drafts/draft-naveen-slaac-prefix-management-00.txt
> >>> Status:
> https://datatracker.ietf.org/doc/draft-naveen-slaac-prefix-management/
> >>> Htmlized:
> https://tools.ietf.org/html/draft-naveen-slaac-prefix-management-00
> >>> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-naveen-slaac-prefix-management
> >>>
> >>>
> >>> Abstract:
> >>>    The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a
> >>>    provision for the hosts to request for a specific IPv6 address and
> >>>    manage the same, whereas the StateLess Address AutoConfiguration
> >>>    (SLAAC) doesn't have such a provision.  Also, unavailability of
> >>>    DHCPv6 across all OS platforms has limited the IPv6 nodes to not use
> >>>    features like soliciting a prefix of desired length and lifetime,
> >>>    renewing, releasing / declining a prefix, etc.  This document
> >>>    proposes IPv6ND extensions for enabling SLAAC devices to solicit
> >>>    prefix information as a hint PIO in RS and other methods like
> >>>    renewing or releasing or declining a prefix without introducing any
> >>>    new ICMPv6 message or option types.
> >>>
> >>>
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time of
> submission
> >>> until the htmlized version and diff are available at tools.ietf.org.
> >>>
> >>> The IETF Secretariat
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> v6ops@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
>
>