RE: [v6ops] RFC7084

"STARK, BARBARA H" <bs7652@att.com> Tue, 10 December 2013 23:38 UTC

Return-Path: <bs7652@att.com>
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 A449A1ADF30 for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2013 15:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 USx9TaMOTzNe for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2013 15:38:58 -0800 (PST)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 039161ADE89 for <ipv6@ietf.org>; Tue, 10 Dec 2013 15:38:56 -0800 (PST)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id b06a7a25.0.1450016.00-2321.3776231.nbfkord-smmo05.seg.att.com (envelope-from <bs7652@att.com>); Tue, 10 Dec 2013 23:38:52 +0000 (UTC)
X-MXL-Hash: 52a7a60c62fdedfb-5abf074a96cf56598a1363b59b3018b313bc4338
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBANcpmQ018545 for <ipv6@ietf.org>; Tue, 10 Dec 2013 18:38:51 -0500
Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBANci52018517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipv6@ietf.org>; Tue, 10 Dec 2013 18:38:48 -0500
Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (GAALPA1MSGHUB9D.itservices.sbc.com [130.8.36.90]) by alpi132.aldc.att.com (RSA Interceptor) for <ipv6@ietf.org>; Tue, 10 Dec 2013 23:38:27 GMT
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 18:38:27 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: "<ipv6@ietf.org>" <ipv6@ietf.org>
Subject: RE: [v6ops] RFC7084
Thread-Topic: [v6ops] RFC7084
Thread-Index: Ac705Oox+bAOGgDPSBCf3B3p1FF6cAAA4TqgACKmQYAAC3HrgAAIU+gAAAzbOYAAAHjyYA==
Date: Tue, 10 Dec 2013 23:38:26 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E611303B0E9F@GAALPA1MSGUSR9L.ITServices.sbc.com>
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>
In-Reply-To: <52A74C8D.3050302@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.34.61]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=QYzRSLnv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=ofMgfj31e3cA:10 a=s6lyBf4fuNYA:10 a=BLceEmwcHowA:10 a=kj9]
X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=tsOF2_MBX]
X-AnalysisOut: [109Z9UbNrIA:9 a=CjuIK1q_8ugA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <bs7652@att.com>
X-SOURCE-IP: [144.160.229.23]
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:38:59 -0000

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.
Barbara