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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 07 November 2018 09:10 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 6405B128CF2; Wed, 7 Nov 2018 01:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 L7fScTXmdaRg; Wed, 7 Nov 2018 01:10:53 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC3C128CB7; Wed, 7 Nov 2018 01:10:52 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wA79AjGw056447; Wed, 7 Nov 2018 10:10:45 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 15CC32025A5; Wed, 7 Nov 2018 10:10:45 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 01CAA2024CF; Wed, 7 Nov 2018 10:10:45 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wA79Aig9000416; Wed, 7 Nov 2018 10:10:44 +0100
Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
To: Ole Troan <otroan@employees.org>, Naveen Kottapalli <naveen.sarma@gmail.com>
Cc: v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <c2596a17-c6fa-99ea-6cf0-92c561493e49@gmail.com>
Date: Wed, 07 Nov 2018 10:10:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <50038373-104D-479D-BE31-07CA2E9D5B5B@employees.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/huQKct3uWLmBE2OfdN181rUJR64>
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:10:56 -0000


Le 07/11/2018 à 08:45, Ole Troan a écrit :
> Naveen,
> 
> 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.

Alex

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