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

神明達哉 <jinmei@wide.ad.jp> Wed, 23 October 2013 18:15 UTC

Return-Path: <jinmei.tatuya@gmail.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 CB15111E8145 for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 11:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.222
X-Spam-Level: *
X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 dl78NILNQ4yG for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 11:15:47 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 13FBA11E8208 for <v6ops@ietf.org>; Wed, 23 Oct 2013 11:15:46 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id ey11so7823785wid.12 for <v6ops@ietf.org>; Wed, 23 Oct 2013 11:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=l3SYt5l3BOgcQpHPyZXxpuXG2cUC7g9cdv0swDhj7JY=; b=O/m4P1jMqCiV5ytqGxqVZP6E5+eTusaM24mxe0Fb3YC0Q5eszQMzaVZqauKb+wGqEI VOyorBMhHqBQSyMP1juu8eSHmvrR6WLCEDBn5YG4WfNPZkRlUqdz3MwrA06x4i2jjj19 XQ4+vL18gqSps5CcrydfA5V6nSkIWWBeLZZlfeF0+tiGP2CJmJV5rhJSB5yiZnMmNpT4 rVx8b6+9OxnoQQb7kYf/ecFKJjW8fgS+nGEkd+EuMfX+p9+2p4TM3WnABsyGr3wBxL0W FcElf9+/4kx9+7shDMaRGFhAl4WEoK+hJjf++7QUt3mScpwF+ERyJNHz9df8smmrCdNe TDBQ==
MIME-Version: 1.0
X-Received: by 10.194.108.164 with SMTP id hl4mr2833801wjb.62.1382552146382; Wed, 23 Oct 2013 11:15:46 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Wed, 23 Oct 2013 11:15:46 -0700 (PDT)
In-Reply-To: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com>
References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <alpine.DEB.2.02.1310211454090.26825@uplift.swm.pp.se> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <alpine.DEB.2.02.1310221511520.8663@uplift.swm.pp.se> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <alpine.DEB.2.02.1310230533340.1838@uplift.swm.pp.se> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com>
Date: Wed, 23 Oct 2013 11:15:46 -0700
X-Google-Sender-Auth: IqyuESFL_ZPdMPqbE-NnKwhrUHk
Message-ID: <CAJE_bqcAKBy62tzXP1aHhoYK_p49Hdv434-6uR-gC6rczyr=JA@mail.gmail.com>
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@wide.ad.jp>
To: "Ole Troan (otroan)" <otroan@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Re: [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: Wed, 23 Oct 2013 18:15:47 -0000

At Wed, 23 Oct 2013 09:21:21 +0000,
"Ole Troan (otroan)" <otroan@cisco.com> wrote:

> A single address does not have a mask.
> DHCP gives out addresses, not prefixes that can be used for onlink determination.

True, and this would mean that a /128 prefix is implicitly assumed for
a host implementation that manages addresses with a corresponding
netmask/prefix length, such as BSD variants.  But that can be
implementation dependent, and IIRC the ISC DHCPv6 client
unconditionally uses a /64 prefix when it configures a host's
interface with the address assigned via DHCPv6.

> > My question was more specificaly about you using "/128", rather than "an address" or "a single address", because I wondered if the DHCPv6 server supplies a /128 prefix length and the host configures a /128 prefix length on the address.
> >
> > As you say below, address prefix length doesn't indicate on-link or off-link presence. So I'd expect a DHCPv6 server to hand out single IPv6 addresses with a /64 prefix length, as I think that would be more consistent and more expected when the subnet's prefix length is /64.
> >
> > For somebody with a IPv4 experience, who wasn't aware an IPv6 prefix length doesn't indicate on-link presence, I think the use of a /128 prefix length in this scenario would imply that prefix length does indicate on-link presence. Somewhat pedantic perhaps, however I think anything that may give false indications of IPv6's behaviour, when it is different to IPv4's, is better to avoid.

I guess this point is related to this change in RFC 4861:

   o Removed the on-link assumption in Section 5.2 based on RFC 4942,
     "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful".

In RFC 2461, if no router (in this context, a node that sends out RAs)
is available, all addresses should be considered on-link.  So it
didn't matter whether a DHCPv6 client chose a /64 or /128 or whatever
prefix.  With the change of RFC 4861, however, there can be a real
interoperability issue if it's a router-less network.  Again, IIRC,
that was the main reason why the ISC implementation used a /64 prefix.

Maybe we should also clarify these points as we want to clarify other
matters regarding RA/DHCPv6 interactions such as A/M/O flags.

--
JINMEI, Tatuya