Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

"Liubing (Leo)" <leo.liubing@huawei.com> Wed, 08 January 2014 13:39 UTC

Return-Path: <leo.liubing@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07C1AE3B4 for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2014 05:39:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level:
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 LU_e3xEPTDtW for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2014 05:39:51 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCF21AE33D for <v6ops@ietf.org>; Wed, 8 Jan 2014 05:39:50 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCH25444; Wed, 08 Jan 2014 13:39:40 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 13:39:15 +0000
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Jan 2014 13:39:39 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 8 Jan 2014 21:39:35 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance
Thread-Index: AQHPDEAXxSskx4jQs0+XEKzlvRgebpp6zyGg
Date: Wed, 08 Jan 2014 13:39:34 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7@nkgeml506-mbx.china.huawei.com>
References: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D827CF1@nkgeml506-mbx.china.huawei.com> <CAKD1Yr1i56skSnw+MzuYWsf97MwCfavgu2ADm5PyQBQSq4u+KA@mail.gmail.com>
In-Reply-To: <CAKD1Yr1i56skSnw+MzuYWsf97MwCfavgu2ADm5PyQBQSq4u+KA@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.132]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8283E7nkgeml506mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 13:39:55 -0000

Hi Lorenzo,

Thanks much for your review and comments.
Please see replies inline.

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Wednesday, January 08, 2014 3:06 PM
To: Liubing (Leo)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

Authors,

I see this document has a "Guidance for DHCPv6-only Deployment" section which mentions "DHCPv6-only configuration without RAs". Three points on that:

1. We had a discussion on this topic when discussing the problem statement draft a couple of weeks ago, and I thought we had agreed that a DHCPv6-only configuration without RAs doesn't do anything useful at all, and since it doesn't do anything useful at all, it should not be documented. See for example at http://www.ietf.org/mail-archive/web/v6ops/current/msg18231.html
[Bing] Yes I remember the discussion a couple of weeks ago. And the above sentence “this is an invalid use case” is just to reflect the discussion result.

If it's not documented in the problem statement document because it doesn't do anything useful, then it certainly should not be documented in the guidance to operators document. And in fact, the draft already states that "this is an invalid use case".

Can you remove it, then? As an operational group we don't want to provide guidance on invalid use cases. :-)
[Bing] I agree with you that “DHCPv6-only without RA” should not be identified as a valid use case. But in the document, what we want to caution the reader is that some operating systems would rely RAs to trigger DHCPv6. I think “RAs are necessary for IPv6 configuration”  and “RAs are necessary to trigger DHCPv6” are two different things in concept. We just want to emphasize the latter one. Maybe it is a little redundant in wording, but at least it is not harmful? Especially considering that in real practice, admins could enable routing configuration in DHCPv6 by private/customized extension (ISC dhcpd & dibbler both provide the capability) . I think maybe the redundancy wording could be useful for the situations.

Best Regards,
Bing

2. That section should also make it clear that in a DHCPv6-only deployment:

  *   If there is no RA, the addresses assigned by DHCPv6 cannot be used for anything at all.
  *   If there is an RA that specifies a default router but does not specify the on-link prefix, then all traffic, even between hosts on the same link, is routed at layer 3 by the default gateway.

3. Please do not cite [DHCPv6-ROUTE]. That document was so controversial that it was removed from the WG's charter and is no longer a WG item, so it is inappropriate to cite it in an operational guidance document.

Cheers,
Lorenzo

On Mon, Jan 6, 2014 at 4:59 PM, Liubing (Leo) <leo.liubing@huawei.com<mailto:leo.liubing@huawei.com>> wrote:
Hi Dear All,

In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem which indicated the hosts' behavior might varied on DHCPv6/SLAAC interaction caused by ambiguous standard definition. (The draft was adopted as ietf-v6ops-dhcpv6-slaac-problem after the meeting.)

Since the above draft is only filed as a Problem Statement document, as discussed in the meeting, the WG decided to initiate another draft to provide some operational guidance of what the administrators should do given the fact that the host behavior might varied in some situations.

So this is the 00 version. Hope you can read it and comment.
Your review and comments would be appreciated very much.

And a late happy new year to you all.

Best regards
Bing


> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>] On Behalf Of fred@cisco.com<mailto:fred@cisco.com>
> Sent: Wednesday, December 25, 2013 9:45 PM
> To: v6ops@ietf.org<mailto:v6ops@ietf.org>
> Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org<mailto:draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org>
> Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance
>
>
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. Please
> take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org<mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops