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

Ole Troan <otroan@employees.org> Wed, 07 November 2018 09:29 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8053128CB7; Wed, 7 Nov 2018 01:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQAN3tl0xVGf; Wed, 7 Nov 2018 01:29:35 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266FE1286D9; Wed, 7 Nov 2018 01:29:35 -0800 (PST)
Received: from astfgl.hanazo.no (dhcp-8190.meeting.ietf.org [31.133.129.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 5C886FECBE7C; Wed, 7 Nov 2018 09:29:34 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id EC8278B2BBB; Wed, 7 Nov 2018 16:29:30 +0700 (+07)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
From: Ole Troan <otroan@employees.org>
In-Reply-To: <c2596a17-c6fa-99ea-6cf0-92c561493e49@gmail.com>
Date: Wed, 07 Nov 2018 16:29:30 +0700
Cc: Naveen Kottapalli <naveen.sarma@gmail.com>, v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADD42674-A31C-4536-8C17-431C7E48CD8A@employees.org>
References: <154155148848.30897.17784898234776136208.idtracker@ietfa.amsl.com> <CAFMMc+KPoBeBmW_AQ+A7S2SZz+ohNEev_UwHQ05Gm3+rg6Zj8g@mail.gmail.com> <CANFmOt=sY78+OYQpwwrCcPwP1ecjCuUrrtLLLe0BL_TYCO_XWQ@mail.gmail.com> <50038373-104D-479D-BE31-07CA2E9D5B5B@employees.org> <c2596a17-c6fa-99ea-6cf0-92c561493e49@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7libA1Jb6TfQ3b4wPKAL2NMoHSk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 09:29:38 -0000

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