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

Naveen,

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

Cheers,
Ole

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