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

[神明達哉 <[e-mail]>]

At Wed, 23 Oct 2013 09:21:21 +0000,
"Ole Troan (otroan)" <[e-mail]> 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