Re: [v6ops] RFC7084

Sander Steffann <sander@steffann.nl> Tue, 10 December 2013 23:45 UTC

Return-Path: <sander@steffann.nl>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4D31ADEA0 for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2013 15:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.194
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSFRbv4aa97G for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2013 15:45:30 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id ACAF01ADE89 for <ipv6@ietf.org>; Tue, 10 Dec 2013 15:45:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id CE2203A; Wed, 11 Dec 2013 00:45:23 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQyUz5SCkRw1; Wed, 11 Dec 2013 00:45:21 +0100 (CET)
Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (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 <sander@steffann.nl>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303B0E9F@GAALPA1MSGUSR9L.ITServices.sbc.com>
Date: Wed, 11 Dec 2013 00:45:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D9DBE30-1927-468A-BDCC-B41376E5544A@steffann.nl>
References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <alpine.DEB.2.02.1312100803370.24602@uplift.swm.pp.se> <F92E1B55-C74B-400C-B83E-6B50D175D121@steffann.nl> <52A74C8D.3050302@gmail.com> <2D09D61DDFA73D4C884805CC7865E611303B0E9F@GAALPA1MSGUSR9L.ITServices.sbc.com>
To: "STARK, BARBARA H" <bs7652@att.com>
X-Mailer: Apple Mail (2.1822)
Cc: "<ipv6@ietf.org>" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 10 Dec 2013 23:45:31 -0000

Hi Barbara,

Op 11 dec. 2013, om 00:38 heeft STARK, BARBARA H <bs7652@att.com> 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!
Sander