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

神明達哉 <> Wed, 23 October 2013 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB15111E8145 for <>; Wed, 23 Oct 2013 11:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dl78NILNQ4yG for <>; Wed, 23 Oct 2013 11:15:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) by (Postfix) with ESMTP id 13FBA11E8208 for <>; Wed, 23 Oct 2013 11:15:46 -0700 (PDT)
Received: by with SMTP id ey11so7823785wid.12 for <>; Wed, 23 Oct 2013 11:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id hl4mr2833801wjb.62.1382552146382; Wed, 23 Oct 2013 11:15:46 -0700 (PDT)
Received: by with HTTP; Wed, 23 Oct 2013 11:15:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Wed, 23 Oct 2013 11:15:46 -0700
X-Google-Sender-Auth: IqyuESFL_ZPdMPqbE-NnKwhrUHk
Message-ID: <>
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <>
To: "Ole Troan (otroan)" <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "" <>
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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)" <> 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