RE: Prefix delegation based on standard IPv6 ND messaging

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 02 October 2018 15:11 UTC

Return-Path: <Fred.L.Templin@boeing.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 4F94A130E9F for <ipv6@ietfa.amsl.com>; Tue, 2 Oct 2018 08:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wgUnSpKcOptU for <ipv6@ietfa.amsl.com>; Tue, 2 Oct 2018 08:11:01 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 3ED2F130E8F for <ipv6@ietf.org>; Tue, 2 Oct 2018 08:11:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w92FB0Zb043522; Tue, 2 Oct 2018 08:11:00 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w92FAwTN043490 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 2 Oct 2018 08:10:58 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 2 Oct 2018 08:10:57 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1367.000; Tue, 2 Oct 2018 08:10:57 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Brian Haberman <brian@innovationslab.net>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: Prefix delegation based on standard IPv6 ND messaging
Thread-Topic: Prefix delegation based on standard IPv6 ND messaging
Thread-Index: AdRV0LEa4XEpTHSRQqqO3G1bHWMbpAExruOAAA4p+gA=
Date: Tue, 02 Oct 2018 15:10:56 +0000
Message-ID: <26b45db4fcc9464daadc2381d6a958b5@XCH15-06-08.nw.nos.boeing.com>
References: <7b026bffbb804b6aa408bc5f5ad2b99c@XCH15-06-08.nw.nos.boeing.com> <efecad88-23ac-5daf-a7d8-6a86e36dcca8@innovationslab.net>
In-Reply-To: <efecad88-23ac-5daf-a7d8-6a86e36dcca8@innovationslab.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 8044799B96746930680EECE49A45F0AEEBB1CDE7A6BCBD910CA1FCF6F9F427AB2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5EN1bDK9bHKer8ieVhVvEw2eVC0>
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: Tue, 02 Oct 2018 15:11:03 -0000

Hi Brian,

Those drafts go back a few years, and I did not see them. My draft proposes
four different possibilities for IPv6 ND-based prefix delegation (see below).
Please let me know your thoughts.

Fred
fred.l.templin@boeing.com

---

2.  DHCPv6 Options in IPv6 ND Messages

- in this section, the design of a new NDP option is proposed, where the option is
  identical to a DHCPv6 message. The DHCPv6 message option is included in RS
  messages to solicit a prefix and in RA messages to delegate a prefix. All other
  DHCPv6 messages (Renew/Rebind/Release/etc.) are supported through their
  inclusion in RS/RA messages. I have not seen other documents suggest including
  a DHCPv6 message within an IPv6 ND message.

3.  PIO Options in RS Messages

- In this section, it is proposed to include a PIO option with the "X" bit set within an
  RS message to solicit a prefix delegation from a router acting as specified in
  'draft-pioxfolks-6man-pio-exclusive-bit'. I have not seen other documents
  suggest including a PIO option with the X bit set in RS messages.

4.  Embedded Prefix Assertion

- In this section, it proposes to include an IPv6 prefix embedded within the interface
   identifier within the link-local source address of an RS message. The delegating
   router examines the link-local source address to determine the IPv6 prefix, and
   injects the prefix into the routing system. Neither the RS nor the RA carry any
   options pertaining to the prefix delegation.

5.  Out-of-Band Network Login Messaging

- This section suggests a Layer 2 (L2) message exchange between the requesting
   router and the network, which causes the delegating router to return an RA.
   No options pertaining to prefix delegation are included in the RA message.

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman
> Sent: Tuesday, October 02, 2018 7:33 AM
> To: ipv6@ietf.org
> Subject: Re: Prefix delegation based on standard IPv6 ND messaging
> 
> Hi Fred,
>      Would be curious about views as to how this approach differs
> significantly from previous attempts to create a non-DHCP-based prefix
> delegation protocol.
> 
> https://tools.ietf.org/html/draft-kaiser-nd-pd-01
> https://tools.ietf.org/html/draft-bykim-ipv6-hpd-01
> https://tools.ietf.org/html/draft-haberman-ipngwg-auto-prefix-02
> 
> None of those are mentioned in your draft.
> 
> Regards,
> Brian
> 
> On 9/26/18 3:54 PM, Templin (US), Fred L wrote:
> > Hi, we have come up with a "new" way of coordinating prefix delegation without
> > DHCPv6 messaging and without requiring any new IPv6 ND options nor modifications
> > to existing options or messages. The method applies only to environments where a
> > node has been administratively assigned an IPv6 prefix by the administrative authority
> > for the network. The prefix length must also be the same (e.g., /56, /60, etc.) for all
> > nodes that connect to the network.
> >
> > Given the above requirements, the node can insert its network prefix into the
> > IPv6 source address of a Router Solicitation (RS) using the AERO address format.
> > In this format, if the node holds the prefix 2001:db8:1:2::/64 then the corresponding
> > AERO address is fe80::2001:db8:1:2. The node then sends the RS to either the
> > all-routers multicast address or to the unicast address of a specific router.
> >
> > When the router(s) receives the RS message, it first determines the node's
> > authority to use its claimed prefix. The router(s) then injects the prefix
> > 2001:db8:1:2/64 into the routing system and returns an RA message to
> > the node.
> >
> > When the node receives the RA message, it uses the default router lifetime
> > as the time before which it must perform an additional RS/RA message in
> > order for the network to retain its routing state. Everything is coordinated
> > by standard RS/RA messaging.
> >
> > This system is documented in Section 4 of the following document:
> >
> > https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/
> >
> > We are interested in receiving your comments.
> >
> > Fred
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >