[v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

"Liubing (Leo)" <leo.liubing@huawei.com> Tue, 22 October 2013 06:50 UTC

Return-Path: <leo.liubing@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0345B11E8481 for <v6ops@ietfa.amsl.com>; Mon, 21 Oct 2013 23:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.179
X-Spam-Level:
X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YklyL6cK94JG for <v6ops@ietfa.amsl.com>; Mon, 21 Oct 2013 23:50:18 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F05DC11E816D for <v6ops@ietf.org>; Mon, 21 Oct 2013 23:50:17 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXA96610; Tue, 22 Oct 2013 06:50:06 +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.146.0; Tue, 22 Oct 2013 07:48:29 +0100
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 07:49:27 +0100
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 14:49:22 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
Thread-Index: AQHOzltsXXG/hvZHw0OAdgyFq+29zZoAR9Tw
Date: Tue, 22 Oct 2013 06:49:21 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CBF49@nkgeml506-mbx.china.huawei.com>
References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com>
In-Reply-To: <201310211245.r9LCj0B29668@ftpeng-update.cisco.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>
Subject: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 22 Oct 2013 06:50:23 -0000

Hi, Chairs & All

The draft (http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem) is about the SLAAC/DHCPv6 interaction problems might cause hosts un-consistent behaviors, which might harmful for management.

The content of the draft has been discussed a couple of times in 6man WG, most of the feedbacks are positive. Some people have showed their willing to fix the problems by revising the standard.
But considering this is a historic problem which was used to be discussed a lot before, we think it might be necessary to identify the problems clearly and solidly before revising the standard. 

So we made a Problem Statement document in v6ops, and hope the OPS people could provide opinions on this topic, e.g. 
- do you agree the problems in the draft;
- have you considered/suffered the impacts to the real IPv6 deployment by this issue; 
- do you think we must have to fix the problems .etc.

Your review and comments would be appreciated very much.

For those who are not familiar with the draft, please see the introduction as the following (also as the replies to the Chairs' questions)
> 1) Please provide a succinct problem statement for your draft. What
> problem/issue is this draft discussing? What operational problems does the
> proposal address in real life networks?
[Bing] As we know there are several flags in RA messages regarding with the host configuration behavior, which are A (Autonomous) flag, M (Managed) flag, and O (Otherconfig) flag.
For some reason, the host behavior of interpreting the flags is ambiguous in the standard (mainly RFC4862). This draft analyzed all the three flags, and provided test result of current implementations, it showed the behavior of different mainstream desktop/mobile OSes have varied. The ambiguous and variation might cause operational problems, such as renumbering, cold start problem, and management gaps .etc.

> 2) Where does this draft or presentation fits into v6ops' current charter
> (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a section(s)
> of the charter is preferable.
[Bing] 1. Solicit input from network operators and users to identify
operational issues with the IPv4/IPv6 Internet, and
determine solutions or workarounds to those issues. These issues
will be documented in Informational or BCP RFCs, or in
Internet-Drafts.

> 3) Who is this draft's audience?
[Bing] Administrators/Operators.

> 4) Have any operators expressed interest in this draft or its problem space,
> either via review or other discussion?
[Bing] Yes, China Telecom had expressed the problem when they deployed IPv6 networks. Their scenario was the CPE doing SLAAC while getting information through stateless DHCPv6. And the found the flags definition is ambiguous in current standard, so they had to directly specify the behavior of interpreting the flags to the CPE vendors.

> 5) Is this draft pursuing discussion in any other WGs? If so, please list them
> here, along with rationale for the interaction with multiple WGs in parallel.
[Bing] In 6man, as described in the main body.

> 6) Is any protocol work being recommended in the draft?
[Bing] Not yet. This draft was intend to be a pure Problem Statement draft.

Many thanks.

Best regards,
Bing

> -----Original Message-----
> From: fred@cisco.com [mailto:fred@cisco.com]
> Sent: Monday, October 21, 2013 8:45 PM
> To: v6ops@ietf.org
> Cc: draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org
> Subject: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
> 
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem.
> Please take a look at it and comment.