Re: [v6ops] RFC7084

Sander Steffann <> Tue, 10 December 2013 23:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BE4D31ADEA0 for <>; Tue, 10 Dec 2013 15:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.194
X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wSFRbv4aa97G for <>; Tue, 10 Dec 2013 15:45:30 -0800 (PST)
Received: from ( [IPv6:2001:9e0:803::6]) by (Postfix) with ESMTP id ACAF01ADE89 for <>; Tue, 10 Dec 2013 15:45:29 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE2203A; Wed, 11 Dec 2013 00:45:23 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MQyUz5SCkRw1; Wed, 11 Dec 2013 00:45:21 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTPSA id BDECC34; Wed, 11 Dec 2013 00:45:21 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: [v6ops] RFC7084
From: Sander Steffann <>
In-Reply-To: <>
Date: Wed, 11 Dec 2013 00:45:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.1822)
Cc: "<>" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Dec 2013 23:45:31 -0000

Hi Barbara,

Op 11 dec. 2013, om 00:38 heeft STARK, BARBARA H <> het volgende geschreven:

> I understand that Ole wants to end this discussion, but I think there were a few key points made.
> 1. RFC6204 and RFC7084 both have WAA-6 that requires the CE router to request IA_NA when RA has M=1. This has been a CE router requirement for years now. Whether or not someone interprets M as also potentially meaning other things, it does not seem unreasonable (to me) for access networks to expect this of CE routers wanting to attach to them.
> 2. There is nothing in RFC6204 or RFC7084 that prohibits a CE router from always requesting IA_NA, no matter what M is, and no matter if there is even an RA. Both RFCs allow the CE router to always request IA_NA. Just (in RFC7084) not more frequently than SOL_MAX_RT, if it isn't assigned IA_NA.
> 3. WPD-4 changed from RFC6204 to RFC7084. RFC6204 required DHCPv6 to always occur and IA_PD to always be requested. RFC7084 backs off from this and only requires IA_PD to always be requested if M=1 or O=1.
> 4. There is nothing in RFC7084 that prohibits the CE router from always requesting IA_PD, no matter what (as in RFC6204). If IA_PD is simply always requested (with or without even waiting for RA), and an RA happens to appear with M=1 or O=1, the CE router has successfully met the RFC7084 WPD-4. If the RA never appears or has M=O=0, then the IA_PD request is still perfectly fine.
> 5. Since the CE router is still free to function as in RFC6204 WPD-4, this loosening of the requirement only really impacts CE routers that for some reason feel obligated or otherwise have a strong desire *not* to request IA_PD if M=O=0. For example, if the network operator they are developing CE routers for asks them to do this. [Note that BBF TR-124 requires the CE router always to request IA_PD and IA_NA, independent of whether an RA was received or what RA flags might be set, so a BBF TR-124 CE router cannot opt not to request when M=O=0; CableLabs eRouter may have different expectations, but that's not for me to say.]
> 6. The access network operator could be seen as being impacted by this change. Previously (under RFC6204), the network operator could assume the CE routers would always request IA_PD. [Under both RFCs, the network operator could only assume the CE router would request IA_NA if M=1. The CE router might go ahead and request IA_NA no matter what, but this couldn't be assumed.] The network operator who cared about IA_PD but not IA_NA could be completely unconcerned about the setting of RA M/O flags. But the reality is that all network operators who intend to send RA messages and provide IA_PD by DHCPv6 are setting either M=1 or O=1. So this didn't change anything for them and there's no real impact to them. 
> The end effect is that some operators now have the freedom to ask their CE router vendors not to do DHCPv6 when the RA has M=O=0, and they can still claim compliance with RFC7084. And since BBF TR-124 didn't change, I think this might suggest that the desire for this change didn't come from operators who make use of BBF TR-124.

Thank you for this nice summary!