>The answer is inconsistent.  Some DHCPv6 clients default to a /64
>prefix so that this scenario works, and systems with those clients can
>and do interoperate.
 
Those clients are broken however. Getting a DHCPv6 address assigned and
assuming it is /64 (and on link) is wrong. If there is no prefix
advertisement, the client should only assume a /128.

I think this behavior came from IPv4 where a host getting an address
without a subnet length assumed the class A/B/C defaults for the subnet
length. In IPv6, that would map to a /64. But that is wrong behavior for
IPv6.

- Bernie

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of David W. Hankins
Sent: Monday, October 13, 2008 12:50 PM
To: DHC WG
Cc: IPV6 List Mailing
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O
bits

On Mon, Oct 13, 2008 at 06:30:53PM +0200, Iljitsch van Beijnum wrote:
> A corner case is the situation where there are no routers, but I don't
see 
> how having a DHCPv6 server in that case still makes sense (would it
even 
> work?), communication can and probably should happen over link locals
in 
> this case.

The answer is inconsistent.  Some DHCPv6 clients default to a /64
prefix so that this scenario works, and systems with those clients can
and do interoperate.  The obvious complete solution to this problem is
to deliver the prefix length via DHCPv6, at which point you may as
well also deliver a default gateway, and complete the circle that
starts the deprecation of RA.

Link locals are not sufficient as they are unlikely to appear in DNS.


Welcome to the world of host configuration penumbra; the land of
partial shadows cast by multiple overlapping lightsources and their
obstructions.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?  https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins        "If you don't do it right the first time,
Software Engineer                    you'll just have to do it again."
Internet Systems Consortium, Inc.               -- Jack T. Hankins
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to