RE: [dhcwg] Re: prefix length determination for DHCPv6
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [dhcwg] Re: prefix length determination for DHCPv6
OK, Iljitsch. But hasn't Bernie already responded to this one? What if
prefix length is fat-fingered at the DHCPv6 server by the admin and a
length L1 is sent in DHCPv6 messages but the router RA sent a PIO for
the same prefix with prefix length L2. So as Bernie says, who wins? What
does the host now do?
Further, isn't sending prefix length in DHCPv6 messages duplicating what
RA PIO prefix length field already is capable of doing?
Lastly, what huge problem is sending prefix length in DHCPv6 messages
going to solve that is not solved by ND RA, RA PIO, and existing DHCPv6?
Hemant
-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch at muada.com]
Sent: Thursday, August 16, 2007 6:42 PM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / ????; David W. Hankins; dhcwg at ietf.org;
ipv6 at ietf.org
Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6
On 16-aug-2007, at 21:35, Hemant Singh (shemant) wrote:
> RA supports all
> of prefix information and on-link determination, so why have DHCPv6
> duplicate that functionality?
That's not the discussion we were having. The discussion we were having
(or at least, _I_ was having) was whether it's a good idea to have a
prefix LENGTH go along with the IPv6 address if a DHCPv6 server assigns
an IPv6 address to a host.
In my opinion, the answer is "of course" because otherwise life gets
quite complex, but apparently there are people who like that kind of
thing and who feel that an address with an unknown prefix length is
useful.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.