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

Ole Troan <otroan@employees.org> Wed, 07 November 2018 07:45 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 7C39E12785F; Tue, 6 Nov 2018 23:45:58 -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 D8p1Ugt0cMuu; Tue, 6 Nov 2018 23:45:55 -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 A7E95127333; Tue, 6 Nov 2018 23:45:55 -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 9A319FECBE55; Wed, 7 Nov 2018 07:45:54 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 379FE8B0631; Wed, 7 Nov 2018 14:45:50 +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: <CANFmOt=sY78+OYQpwwrCcPwP1ecjCuUrrtLLLe0BL_TYCO_XWQ@mail.gmail.com>
Date: Wed, 07 Nov 2018 14:45:50 +0700
Cc: 6man WG <ipv6@ietf.org>, v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <50038373-104D-479D-BE31-07CA2E9D5B5B@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>
To: Naveen Kottapalli <naveen.sarma@gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fSaFAm983fkbTln7QwWIDrzmHi4>
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 07:45:58 -0000

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