[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 07:22 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 6022911E82E9 for <v6ops@ietfa.amsl.com>; Tue, 22 Oct 2013 00:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 lHxdNOJDXNLM for <v6ops@ietfa.amsl.com>; Tue, 22 Oct 2013 00:22:27 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31E2811E8169 for <v6ops@ietf.org>; Tue, 22 Oct 2013 00:22:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXA99876; Tue, 22 Oct 2013 07:22:19 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 08:22:03 +0100
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 08:22:12 +0100
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 15:21:30 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Thread-Topic: DHCPv6/SLAAC Make Hosts Confusing-//RE: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
Thread-Index: AQHOzltsXXG/hvZHw0OAdgyFq+29zZn+mHwAgAGxNZA=
Date: Tue, 22 Oct 2013 07:21:26 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com>
References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <alpine.DEB.2.02.1310211454090.26825@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1310211454090.26825@uplift.swm.pp.se>
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: "v6ops@ietf.org" <v6ops@ietf.org>, "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 07:22:32 -0000

Hi, Mikael

Thanks for your comments. (I change the mail title to help identify the traffic to this specific draft/problem).
Please see replies inline.

> I like the fact that this work is being done. It seems to me the current
> standards leave too much room for interpretation.
[Bing] Agreed. Ambiguity is usually a bad thing.

> I would like to see the following deployment scenarios being possible, and
> all hosts should support them.
> 
> 1. No Prefix information, M=1, Host gets /128 IPv6 address for own use and
> a default route (RA), possibly other information. All traffic to other
> hosts that is not LL goes via router.
> 
> 2. PIO /64, A=0, M=1, host gets /128 out of on-link /64, can communicate
> with other hosts on-link directly.
[Bing] I'm a little confused about the scenario. A=0 switch SLAAC off, and host would initial DHCP according M=1, do you mean the DHCP Server need to be aware of the PIO /64, so that the /128 from dhcp in accordance with the PIO /64?
 
> 3. PIO /64, A=1, M=1. Host gets /128 from DHCP plus can do SLAAC,
> otherwise same as above.
> 
> 4. PIO /64, A=1, M=1. Host gets /128 from outside /64 via DHCP, plus can
> do SLAAC within the /64.
> 
> Also it's quite worrying about the state changes when A/M/O changes. I
> believe that it might be time to re-rev our standards documents to specify
> exactly what should happen for each case.
[Bing] Agreed. 

Best regards,
Bing