RE: [v6ops] RFC7084

Wuyts Carl <Carl.Wuyts@technicolor.com> Wed, 11 December 2013 10:24 UTC

Return-Path: <Carl.Wuyts@technicolor.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 9E5541AD937 for <ipv6@ietfa.amsl.com>; Wed, 11 Dec 2013 02:24: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, SPF_PASS=-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 IGNJ4_O-WxIQ for <ipv6@ietfa.amsl.com>; Wed, 11 Dec 2013 02:24:57 -0800 (PST)
Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with ESMTP id 64A211ACC7D for <ipv6@ietf.org>; Wed, 11 Dec 2013 02:24:56 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUqg9cqmH7rF4a4yBq7YTQIDOMMTsjrIB@postini.com; Wed, 11 Dec 2013 02:24:52 PST
Received: from MOPESMAILHTC02.eu.thmulti.com (141.11.100.178) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 11 Dec 2013 11:20:11 +0100
Received: from MOPESMBX03.eu.thmulti.com ([169.254.2.32]) by MOPESMAILHTC02.eu.thmulti.com ([141.11.100.178]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 11:20:15 +0100
From: Wuyts Carl <Carl.Wuyts@technicolor.com>
To: "STARK, BARBARA H" <bs7652@att.com>, "<ipv6@ietf.org>" <ipv6@ietf.org>
Subject: RE: [v6ops] RFC7084
Thread-Topic: [v6ops] RFC7084
Thread-Index: Ac705Oox+bAOGgDPSBCf3B3p1FF6cAAA4TqgACKmQYAACU43hwAKwC6AAA1SIQAAGDm3EA==
Date: Wed, 11 Dec 2013 10:20:14 +0000
Message-ID: <96747494E3D74D41B20907035DB1E48DD4D4@MOPESMBX03.eu.thmulti.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> <2D09D61DDFA73D4C884805CC7865E611303B0E9F@GAALPA1MSGUSR9L.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303B0E9F@GAALPA1MSGUSR9L.ITServices.sbc.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.11.249.53]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 11 Dec 2013 10:24:59 -0000

Hi Barbara,

Nice summary indeed, however, as Ole mentioned already before, not ok for the WPD-4 req.  The rest is negotiable I'd say, we can cope with those.

But WPD-4 is not ok, for the simple reason that O=1 means stateless.  You now mandate to ask IA_PD always, and that it won't harm to do this, but stateless = information request, hence no solicit, hence no IA possible to request.  This is clear form RFC4861, which is a standard, not informational.
In this case, it's just ignoring the flags, nothing more, nothing less, and always run the full solicit-... state machine.  Although this is a possible approach (to not listen I mean), this would make information-requests obsolete, so I'd say this is changing the standards on DHCPv6 too.
So, as Ole says, this has been changed wrongly form RFC6204.  So, imho, this should be corrected (and not for me nor company, we can ignore flags if needed, but for the sake of clearness and standardization).  It's already difficult to have the IPv6 enabled at customers (although improving lately of couse), so let's try to make things as clear as possible.  Telling them they can sent whatever they want in flags doesn't seem to contribute to this.

Tx and regs
Carl

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of STARK, BARBARA H
Sent: woensdag 11 december 2013 0:38
To: <ipv6@ietf.org>
Subject: RE: [v6ops] RFC7084

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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------