Re: [dhcwg] DHCPv6 and IPv6ND

"Bernie Volz (volz)" <> Thu, 16 November 2017 06:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5E681294E8 for <>; Wed, 15 Nov 2017 22:50:37 -0800 (PST)
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 bjcDK7dU6kbY for <>; Wed, 15 Nov 2017 22:50:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CDB0129541 for <>; Wed, 15 Nov 2017 22:50:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9311; q=dns/txt; s=iport; t=1510815035; x=1512024635; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=McDZFrJsvhdRV3CazDpl77Z9KLprVHXBv9Qpn6BtBA0=; b=Jd4uoyJwHKtdThH1535xtd7lrN0em7WgzOb9G2DvfE3EKRYaBKykBbwr YJlEU4aAFQcLSFhCv7xkS/SyeR+u801tGG3Jfnc1xhwMnFk5hJgrrVcrg gla3Rz5jSTDO+cT1LNghgPormCgYz757j9hwX8DOeJ5xec6pT8WLvUiec s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AAB+NA1a/4oNJK0WBUMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgkRyZG4ng3+KH48ggVeJAog5hUmCEQojhRgCGoR3PxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUfBiNWEAIBCA4xAwICAh8RFBECBA4FiUBMAxUQhQqkN4Inhz0Ng?= =?us-ascii?q?0kBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYM0ggeDZwuCdoJrhUIxgjIFoXo9Aod?= =?us-ascii?q?riCCEeZNEjG86iFgCERkBgTgBHziBdHoVdgGCNoJcHIFndwGLKwEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,402,1505779200"; d="scan'208,217"; a="32165506"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2017 06:50:23 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vAG6oNPU001284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2017 06:50:23 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 16 Nov 2017 00:50:23 -0600
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 16 Nov 2017 00:50:23 -0600
From: "Bernie Volz (volz)" <>
To: Ted Lemon <>
CC: Alexandru Petrescu <>, dhcwg <>
Thread-Topic: [dhcwg] DHCPv6 and IPv6ND
Date: Thu, 16 Nov 2017 06:50:23 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_D787D5DC98E14205906A7D519E5797ECciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dhcwg] DHCPv6 and IPv6ND
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Nov 2017 06:50:38 -0000

See RFC 6459:

5.3<>.3>.  Prefix Delegation

   IPv6 prefix delegation is a part of Release-10 and is not covered by
   any earlier releases.  However, the /64 prefix allocated for each
   default bearer (and to the UE) may be shared to the local area
   network by the UE implementing Neighbor Discovery proxy (ND proxy)
   [RFC4389<>] functionality.

   The Release-10 prefix delegation uses the DHCPv6-based prefix
   delegation [RFC3633<>]3>].  The model defined for Release-10 requires
   aggregatable prefixes, which means the /64 prefix allocated for the
   default bearer (and to the UE) must be part of the shorter delegated
   prefix.  DHCPv6 prefix delegation has an explicit limitation,
   described in Section 12.1 of [RFC3633]<>.1>, that a prefix delegated to a
   requesting router cannot be used by the delegating router (i.e., the
   PDN-GW in this case).  This implies that the shorter 'delegated
   prefix' cannot be given to the requesting router (i.e., the UE) as
   such but has to be delivered by the delegating router (i.e., the
   PDN-GW) in such a way that the /64 prefix allocated to the default
   bearer is not part of the 'delegated prefix'.  An option to exclude a
   prefix from delegation [PD-EXCLUDE<>] prevents this problem.

Perhaps you are on an early Release?

- Bernie (from iPhone)

On Nov 16, 2017, at 2:40 PM, Ted Lemon <<>> wrote:

On Nov 16, 2017, at 2:38 PM, Alexandru Petrescu <<>> wrote:
If so, this entire issue about making DHCPv6 work on 3GPP networks should be forgotten.   It's impossible to make it work.

It is not impossible.   It is impossible for the IETF.

If you want to define a standard for 3GPP to do DHCP over a different port, that sounds fine.   But it's not an IETF thing—this is a specifically 3GPP problem, and it doesn't make any sense to write an IETF standard to work around it.   Suppose we did so: what advice would we give to implementors?