Re: [dhcwg] 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'

"Bernie Volz (volz)" <> Mon, 18 September 2017 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3C2F132320 for <>; Mon, 18 Sep 2017 12:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R3izx7I4IGLZ for <>; Mon, 18 Sep 2017 12:31:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C7811321D8 for <>; Mon, 18 Sep 2017 12:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=38732; q=dns/txt; s=iport; t=1505763079; x=1506972679; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EegrA1zAs90YCyu+FabSQZZCr2e5cQunNzjNVKzx2XY=; b=exvO06RhnSZprULQgrKJsc5XrbzQwHNSJm4NkbF9f8T9FtP6P82royy6 SxkP/3l/q8O3pmfu2XB3WgCLqCPPecxhR+4L3WgVKzhvgbCOvZUklXw6y YhwpgJOJ1WBoIRHEVbRnIZat56N7TLNDUYFOa9bI2MVPJlSNMR6RhckJG w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.42,414,1500940800"; d="scan'208,217";a="286566964"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 19:31:18 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v8IJVIYI010036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Sep 2017 19:31:18 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 18 Sep 2017 14:31:17 -0500
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Mon, 18 Sep 2017 14:31:17 -0500
From: "Bernie Volz (volz)" <>
To: "Templin, Fred L" <>, Suresh Krishnan <>
CC: "" <>
Thread-Topic: [dhcwg] 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'
Thread-Index: AdMdAAkfD4sQrO/BQ3+nFUZgsVrgiwA3VgYAAAldv1AEFjUMUACT6LkAAAI612A=
Date: Mon, 18 Sep 2017 19:31:17 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_f7b194cff6164424b3110cdfad78ec39XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dhcwg] 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Sep 2017 19:31:22 -0000

Hi Fred:

I did notice your draft and haven’t read it in detail (yet).

I do agree that unique prefix per host and PD are two different things. I agree that both may well have their place.

Again, the unique prefix per host requires nothing of the host (it is a way to operate a network) whereas PD does.

-          Bernie

From: Templin, Fred L []
Sent: Monday, September 18, 2017 2:30 PM
To: Bernie Volz (volz) <>; Suresh Krishnan <>
Subject: RE: [dhcwg] 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'

Hi Bernie,

I am not opposing this draft going forward, but it is not the same thing as prefix
delegation. The document is about a router advertising a unique prefix per host,
whereas true prefix delegation is from a delegating router to a requesting router.
This is true even if the “requesting router” is an end system, as in:

I think both of these mechanisms will have their respective use cases. Please
have a look at the above document and share your thoughts here.

Thanks - Fred

From: Bernie Volz (volz) []
Sent: Friday, September 15, 2017 12:57 PM
To: Templin, Fred L <<>>; Suresh Krishnan <<>>
Subject: RE: [dhcwg] 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'

Hi Fred:

My personal view is …

While many of us would have liked to see DHCPv6 PD used in this situation, I think this work is a nice practical solution without requiring new functionality in hosts. It is a deployment document (hence why it is in v6ops) – anyone can do this without requiring anything from the hosts that they don’t already support. That isn’t the case with DHCPv6 PD (most hosts don’t support this).

-          Bernie

From: dhcwg [] On Behalf Of Templin, Fred L
Sent: Friday, August 25, 2017 11:45 AM
To: Suresh Krishnan <<>>
Subject: Re: [dhcwg] 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'

Hi Suresh,

My intent on posting was to make the dhc community aware that there is a
BCP document in the publication queue that makes statements about DHCPv6.
My point about IA_PD concerns the following draft text:

   o  M-flag = 0 (UE/subscriber address is not managed through DHCPv6),
      this flag may be set to 1 in the future if/when DHCPv6 prefix
      delegation support is desired)

I find the text “may be set to 1 in the future if/when DHCPv6 prefix delegation
support is desired” to sound as if it is casting doubts on whether that future will
ever arrive. Can this WG live with text of this nature going forward in a BCP?

I do not have any specific comments on IA_NA; my area of interest is IA_PD.
But, others in this community may want to have a look.

Thanks - Fred

From: Suresh Krishnan []
Sent: Friday, August 25, 2017 6:05 AM
To: Templin, Fred L <<>>
Subject: Re: [dhcwg] 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'

Hi Fred,

On Aug 24, 2017, at 1:42 PM, Templin, Fred L <<>> wrote:

Have people in this community seen the following document that is working
its way through the publication process in the 'v6ops' working group:

It seems to make some very limiting statements about DHCPv6 in a similar
spirit as was done in RFC7934 (the limiting statements apply to both IA_NA
and IA_PD).

There are a couple of references to DHCPv6 in the draft. I do not see any limitation to the use of IA_PD.

There is a recommendation against a IA_NA *only* network that is a straight reference to RFC7934 and nothing additional

"an IA_NA-only network is not recommended per RFC7934<> [RFC7934] section 8<>"

I have asked for the motivation for the text (See my ballot at

"however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address”

Is there some specific text you are concerned about?