IETF Logo Mail Archive

DHCPv6 PD and IPv6 ND unification ((RE: L=0 [was draft-pioxfolks-6man-pio-exclusive-bit-02.txt])

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 01 February 2018 19:39 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 5EA9012EC87 for <ipv6@ietfa.amsl.com>; Thu, 1 Feb 2018 11:39:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 zGmrMEMOxq6x for <ipv6@ietfa.amsl.com>; Thu, 1 Feb 2018 11:39:12 -0800 (PST)
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 903D312EC84 for <ipv6@ietf.org>; Thu, 1 Feb 2018 11:39:12 -0800 (PST)
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 w11JdBDC059072; Thu, 1 Feb 2018 12:39:11 -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 w11Jd9XQ059032 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 1 Feb 2018 12:39:09 -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.1347.2; Thu, 1 Feb 2018 11:39:08 -0800
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.1347.000; Thu, 1 Feb 2018 11:39:08 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
CC: 6man WG <ipv6@ietf.org>
Subject: DHCPv6 PD and IPv6 ND unification ((RE: L=0 [was draft-pioxfolks-6man-pio-exclusive-bit-02.txt])
Thread-Topic: DHCPv6 PD and IPv6 ND unification ((RE: L=0 [was draft-pioxfolks-6man-pio-exclusive-bit-02.txt])
Thread-Index: AdObk8sYTbsNjEvkTWWp+W+XphU4VA==
Date: Thu, 01 Feb 2018 19:39:08 +0000
Message-ID: <086f874f250e46a5bdf7429b14e3fd87@XCH15-06-08.nw.nos.boeing.com>
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.136.248.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sVfGl6uyO4Syl_-IVHQoXHprCrQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 01 Feb 2018 19:39:14 -0000


> -----Original Message-----
> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
> Sent: Thursday, February 01, 2018 11:07 AM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> Cc: 6man WG <ipv6@ietf.org>
> Subject: RE: L=0 [was draft-pioxfolks-6man-pio-exclusive-bit-02.txt]
> 
> On Thu, 1 Feb 2018, Templin, Fred L wrote:
> 
> > I get your frustration, but I believe DHCPv6PD works if the implementer
> > simply follows the specs.
> 
> Didn't we just agree that DHCPv6-PD and relays was blatantly obvious and
> didn't need spec:s?

I mean the specs that tell how the client and server regard lease lifetimes
for IA_PDs, and how messages like Rebind, Renew, Release and Reconfigure
affect them. All the Relay has to do is understand how the lease lifetimes
are handled at the end systems so it can do the right thing as a man in the
middle.

> >> So your proposal of tunneling DHCPv6 inside RS/RA and if that means we get
> >> operational guidance such as "zero lifetime in the RA means deprecate all
> >> DHCPv6 resources you have" and similar, would help a long way.
> >
> > Do we want to put some energy behind this?
> 
> I'd prefer if we took some of DHCPv6 option space, some of the state
> machines, and ditched the rest, and explained how this was done using
> something else, for instance ND.
> 
> But short of that yes, there should be operational documents (in v6ops
> perhaps) that tells implementors how SLAAC and DHCPv6 works together, and
> what certain SLAAC messages means for DHCPv6 based resources.

Let's start with embedding DHCPv6 PD messages in IPv6 ND RS/RA options
and see where that takes us.

Thanks - Fred

> --
> Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email