RE: [v6ops] RFC7084

"STARK, BARBARA H" <bs7652@att.com> Wed, 11 December 2013 15:02 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 E320D1ADEBF for <ipv6@ietfa.amsl.com>; Wed, 11 Dec 2013 07:02:46 -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 jXtxg3mLueJt for <ipv6@ietfa.amsl.com>; Wed, 11 Dec 2013 07:02:44 -0800 (PST)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 64E7F1ADE88 for <ipv6@ietf.org>; Wed, 11 Dec 2013 07:02:44 -0800 (PST)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id e8e78a25.0.1716564.00-2367.4488423.nbfkord-smmo07.seg.att.com (envelope-from <bs7652@att.com>); Wed, 11 Dec 2013 15:02:39 +0000 (UTC)
X-MXL-Hash: 52a87e8f72957ff8-d9079d70dc94e630137ecd5e186c1ff6cfbfbc22
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 rBBF2bTx019574; Wed, 11 Dec 2013 10:02:38 -0500
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBBF2WFt019542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 10:02:33 -0500
Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (GAALPA1MSGHUB9A.itservices.sbc.com [130.8.36.87]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 11 Dec 2013 15:02:23 GMT
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 10:02:23 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: Wuyts Carl <Carl.Wuyts@technicolor.com>, "<ipv6@ietf.org>" <ipv6@ietf.org>
Subject: RE: [v6ops] RFC7084
Thread-Topic: [v6ops] RFC7084
Thread-Index: Ac705Oox+bAOGgDPSBCf3B3p1FF6cAAA4TqgACKmQYAAC3HrgAAIU+gAAAzbOYAAAHjyYAAjQ1MAAANM5fA=
Date: Wed, 11 Dec 2013 15:02:22 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E611303B13A7@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> <2D09D61DDFA73D4C884805CC7865E611303B0E9F@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DD4D4@MOPESMBX03.eu.thmulti.com>
In-Reply-To: <96747494E3D74D41B20907035DB1E48DD4D4@MOPESMBX03.eu.thmulti.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.63.176]
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=Qo7pKyOd c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=ofMgfj31e3cA:10 a=QweXHwsXL-EA:10 a=BLceEmwcHowA:10 a=kj9]
X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA]
X-AnalysisOut: [AAA:8 a=UOweGUpmPwxku8grnJ8A:9 a=CjuIK1q_8ugA:10 a=6bWLPKo]
X-AnalysisOut: [vLjuN-eut:21 a=X2L9TJMYNBljwvVp:21]
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: Wed, 11 Dec 2013 15:02:47 -0000

> But WPD-4 is not ok, for the simple reason that O=1 means stateless.  

Per RFC4861 "When set, it [the O flag] indicates that other configuration information is available via DHCPv6."
The word "stateless" is not present. As has been discussed, the word "addresses" in the M-flag definition is interpreted differently by different people, and some think it includes prefixes and some don't. My interpretation of "other" in the O-flag definition is everything other than "addresses". Therefore, I disagree that your interpretation of the words "addresses" and "other" is necessarily the only or the correct interpretation.

> You now mandate to ask IA_PD always, 

No, RFC6204 *previously* mandated always doing IA_PD. RFC7084 changes this by allowing IA_PD *not* to be requested when M=O=0. Note RFC4861 says "If neither M nor O flags are set, this indicates that no information is available via DHCPv6." For me, this is a fairly unambiguous statement. I'm not aware of multiple interpretations of "no information". Therefore, I see no problem with allowing providers who explicitly want their routers to interpret M=O=0 as meaning "don't do DHCPv6, because there's no information available."

> 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, 

I disagree with your interpretation of "other" == "stateless". These 2 words are neither equal nor equivalent. Therefore I disagree that your interpretation that "other" == "stateless" is somehow "clear" from 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.

No, it's not changing DHCPv6 standards and it's not obsoleting information-request. It does mean that a RFC7084 CE router will never send information-request. But RFC7084 has absolutely no influence on the vast majority of IP-capable devices.
BTW, I think it's also important to note that the service provider is free to set M=1 and then not offer IA_NA. Just because the CE router is going to ask for it, doesn't mean it has to be offered. So if you or anyone else wants to use M=1 to indicate availability of IA_PD without IA_NA, go for it. This will work.
Now if you want to design a CE router that doesn't do IA_PD when it has been statically configured with a prefix, that's fine, and it can still be an RFC7084 CE router, as long as it has the logic to request IA_PD either always or at the very least when M=1 or O=1 when no prefix is configured. The RFC7084 logic is not intended to prevent static configuration from being able to disable the capabilities it specifies.
Also, since RFC7084 is informational, there is absolutely no requirement that IETF places upon you to design a CE router per its guidance.

> So, as Ole says, this has been changed wrongly form RFC6204.  

I read Ole as saying that it was right to always request IA_PD, no matter the RA flags (the original RFC6204 language). I read you as saying that it's *not* right to request any stateful option if M=0 and O=1.  It seems like you would also then object to requesting stateful options when M=O=0, but I'm not clear if you think that. As I mentioned, the effect of the change is that it's now allowed not to do IA_PD when M=O=0. So your objecting to the change to me suggests that you believe there should be IA_PD when M=O=0. And it really confuses me as to the logic of "do IA_PD when M=O=0, but not when M=0 and O=1". In either case, you are disagreeing with Ole. I do not read Ole as saying that there should be no IA_PD when M=0 and O=1.

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

Since I don't see it as an error nor as causing any problems, I disagree. But if you want to create a draft proposing this and try to get support for your draft -- that is of course something you can do. I will not be in favor of changing this yet again. There were several ISPs who felt very strongly that they needed the freedom to specifically ask their CE routers (CE routers that meet not only RFC7084 but also their more specific requirements) not to do any DHCPv6 when they set M=O=0. They insisted on this change (allowing CE routers not to do any DHCPv6 when M=O=0) over Ole's objections. However, I think it's safe to say there was agreement among the authors that there is widespread disagreement regarding the precise DHCPv6 options implied by M and O bits. It is widely recognized that many people do not agree that O means "stateless".  Therefore, getting consensus that RFC4861 somehow forbids or mandates any particular client behavior in response to M or O flag values is, IMO, highly unlikely and will take someone really committed to getting rid of the current ambiguity. And as long as nothing is breaking (and I'm not convinced that http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-00 suggests a problem with these flags that's worth solving, especially in the context of RFC7084), then I don't see a real need to change RFC4861 or its flags. It's not yet clear to me that anything is really broken (in a way that will impact the average consumer). So I have no desire to spend effort fixing it.
Barbara