RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

"Templin, Fred L" <> Mon, 13 November 2017 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12BED129B08; Mon, 13 Nov 2017 08:44:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HghYiaF-uVqm; Mon, 13 Nov 2017 08:43:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9AD7129B04; Mon, 13 Nov 2017 08:43:59 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vADGhxbl047312; Mon, 13 Nov 2017 09:43:59 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vADGhpB4047246 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 13 Nov 2017 09:43:51 -0700
Received: from (2002:8988:eede::8988:eede) by (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 13 Nov 2017 08:43:50 -0800
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 13 Nov 2017 08:43:50 -0800
From: "Templin, Fred L" <>
To: Lorenzo Colitti <>, Ted Lemon <>
CC: Fernando Gont <>, " WG" <>, "" <>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <>
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTXFfOF0lutU7PtESjw8Zn8vPUPqMSgHbw
Date: Mon, 13 Nov 2017 16:43:50 +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_6d7cbb0725b14a7bbe3755054c8a0971XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Nov 2017 16:44:02 -0000

This one needs a bit more discussion:

>But in the real world, that is a hard requirement for things to work, since in the real world, the DHCPv6 server is almost never in the client's first-hop router.

In my use case, the DHCPv6 server most definitely is on the Client’s first-hop router.
I do DHCPv6 PD, and everything gets set up correctly, including routing on the first
hop router.

But, what I would really like to get to is the ability to do everything in a single message
exchange. I don’t want to have to do two separate message exchanges (RS/RA followed
by DHCPv6 Solicit/Reply or vice-versa). So, what I would really like would be for the
DHCPv6 Reply to contain information normally found in an RA, e.g., default router
lifetime, default router preferences, link MTU, etc.

So, maybe what would satisfy it would be a new DHCPv6 option that embeds an IPv6
RA with all of its many features. Then, DHCPv6 servers that are known to be on the
same link as the client can include an RA in the DHCPv6 Reply and the client can do
all of its RA-style configurations without having to issue an RS/RA.

Failing that, there would need to be a way to embed information normally gotten
from DHCPv6 in an RA and then make RS/RA the only exchange.

This is very important for devices on which even a single message exchange is
expensive (e.g., airplanes with low-end data links) so I really need an all-in-one

Thanks - Fred

From: v6ops [] On Behalf Of Lorenzo Colitti
Sent: Monday, November 13, 2017 12:17 AM
To: Ted Lemon <>
Cc: Fernando Gont <>om>; WG <>rg>;; Van De Velde, Gunter (Nokia - BE/Antwerp) <>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

On Mon, Nov 13, 2017 at 5:04 PM, Ted Lemon <<>> wrote:
On Nov 13, 2017, at 4:00 PM, Lorenzo Colitti <<>> wrote:

  *   DHCPv6 PD has exactly the same problem.
DHCPv6 PD specifies a stateful mechanism for managing prefixes.

And it does not specify how those prefixes are pushed to routers between the requesting router and the DHCPv6 server. But in the real world, that is a hard requirement for things to work, since in the real world, the DHCPv6 server is almost never in the client's first-hop router.