DHCP server address would be useless because clients don't generally unicast to the server/relay (and aren't allowed to unless the server has sent a server-unicast option). And, if the server isn't on-link, unless the client has an address of sufficient scope, it couldn't communicate with the server directly.
And, what value does this add anyway? If you are trying to get just get DNS server addresses, you can use Information-Request (which is multicast) and you'll get the answer in a Reply (which is unicast). So, you add two messages - only one of which is multicast. Even if you do use address assignment and thus Solicit, you can include the Rapid Commit option which can save two messages (instead of Solicit/Advertise/Request/Reply, you have Solicit/Reply). Only the client's messages are multicast. DHCPv6 messages are generally small and don't require a lot of back and further. I really don't understand why people are objecting to one or two request/reply exchanges (only the request of which is multicast). Sure, it be nice if there were zero messages, but we're basically down to as few as possible and most of these messages are tiny (especially compared to the 300+ bytes that is the minimal size of DHCPv4 messages). - Bernie -----Original Message----- From: Alexandru Petrescu [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 1:06 PM To: Leino, Tammy Cc: Iljitsch van Beijnum; ipv6@ietf.org; John Jason Brzozowski (JJMB) Subject: Re: prefix length determination for DHCPv6 Leino, Tammy wrote: > Iljitsch, thank you for your comprehensive remarks. I think my > mistake was in believing an IPv6 router does not have to be > configured to send RAs, but the DHCPv6 server could serve the same > purpose as the RAs. It appears DHCPv6 was meant to supplement RAs. > > As an embedded developer, there is a lot of overhead in terms of code > space and memory requirements in the DHCPv6 protocol, particularly > for customers wishing to just distribute DNS servers. It would be > nice if all the configuration options of DHCPv6 had been added to > RAs. This way, we would save on memory. Errr... the RAs would become larger and bandwidth would be wasted sometimes. I'd rather extend the RA to include the DHCP Server address such that the mobile does not need to discover the DHCP Server address, thus gaining time by eliminating Solicit and Advertise DHCP messages. But these things are relatively widely implemented and modifying anything in the existing operation risks taking a lot of time... Alex > > Thank you again for your time and advice. > > Best Regards, Tammy > > > -----Original Message----- From: Iljitsch van Beijnum > [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 6:18 AM To: > Leino, Tammy Cc: John Jason Brzozowski (JJMB); Hemant Singh > (shemant); ipv6@ietf.org Subject: Re: prefix length determination for > DHCPv6 > > > On 11-aug-2007, at 1:09, Leino, Tammy wrote: > >> The reason I am not assuming there is a router on link configured >> to send RAs with prefix options is because I don't see the point of >> DHCPv6 configuring addresses if a router is configured to do the >> same job. > > :-) > >> Since the prefix length is carried in a prefix option of an RA, I >> have to assume these will be absent on the link; otherwise, the >> node would not be using DHCPv6 to obtain an address. > > But then, why do you need addresses when you have no external > connectivity? A lot of stuff will work just fine over link local > addresses, although the need to include a scope identifier gets in > the way of some applications. > >>>> (There is of course the consideration that at this time, very >>>> few >> IPv6 implementations can configure an address through DHCPv6.) > >> Is this because of some shortcoming(s) in the specification or do >> network managers find DHCPv6 unnecessary? > > First of all, the DHCPv6 specification was finished relatively late, > in 2003 if I'm not mistaken. Most major vendors had already > implemented IPv6 by then and I'm guessing that deployment levels so > far haven't exactly given them much reason to drastically update > their IPv6 implementations. > > Then there is the confusion about stateful and stateless DHCPv6 and > the whole discussion about the meaning of the M and O bits in router > advertisements. I think this created uncertainty in the market place > for some time. > > Since address configuration has always happened and continues to > happen through stateless autoconfiguration, DHCPv6 address assignment > wasn't implemented widely, and you can only use this mechanism when > you can be sure that both the server and the clients support it. It > looks like now that IPv6 is gaining more widespread attention that > more people want this because it's the same as in IPv4, but "old > school" IPv6 users are generally happy with stateless > autoconfiguration. > > That leaves: > >> If they are not using DHCPv6, how do they distribute DNS servers >> and other configuration information? > > In practice? They don't. As long as you have IPv4, you can use IPv4 > for this. > > Other than that, you mostly manually configure an address. Although > DHCPv6 allows you to do this automatically, the trouble is that you > can't be sure that there will be a DHCPv6 server everywhere you go > so in practice, the advantage of DHCPv6 over manual configuration is > limited. There was talk about using well-known anycasted addresses > for this but that never came off the ground. > > In the near future we'll have draft-jeong-dnsop-ipv6-dns- > discovery-12.txt which is now in the RFC Editor queue. However, this > will have the same problem as DHCPv6: you can't be sure that someone > is making the info available until it's extremely widely > implemented. > >> I am interested in learning how well received DHCPv6 has been. We >> have been slow to implement it in our OS because of low demand. > > My opinion: DHCPv6 is a complex protocol that uses a relatively high > number of messages. In the past, UDP-based protocols have been > especially susceptible to security problems in their implementations. > As such, I'm very happy to do without it when I don't need it and I > feel stronly that DHCPv6 should NOT be initiated by clients by > default but only if RA flags indicate that they should do this, and > DNS configuration should be possible without DHCPv6. > > Having said that, there can be situations where it's useful to assign > an address to an IPv6 host, so there is certainly a place for > DHCPv6. And prefix delegation is brilliant, this is a great way to > provision IPv6 CPEs with an address block. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
