Erik Nordmark writes: > Are we assuming/requiring that the first packet from the DHCP server > (the offer in DHCPv4 - I don't know if the packet is called something > else in DHCPv6)
DHCPv6 does have Standard V6 Random Renaming Disease. ;-} The same packet is called "Advertise" in DHCPv6 -- the normal sequence goes Solicit -> Advertise -> Request -> Reply. The semantics are essentially the same as DISCOVER -> OFFER -> REQUEST -> ACK for v4, but with some subtle tweaks. > includes the domain name? It can and should, though that's no guarantee. RFC 3315 suggests that clients should treat Advertise messages containing preferred options as being "better" than ones that don't have them. In the WIDE implementation, the same options are given in the Advertisement as in the Reply. One really good reason for doing that is to be able to support the Rapid Commit Option. You need to generate a Reply (instead of an Advertise) message in response to the initial Solicit message, if you're supporting that feature, so it makes sense to have this code in common. > In order to use the domain > name to determine what to do next we would need this. But are DHCP > servers required to include it in the offer, or can they wait to supply > it until the second packet (the ack in DHCPv4)? That's the "Reply" in DHCPv6 (which is both ACK and NAK, depending on the options contained inside). Yes, they can wait until the Reply if they choose. They can also avoid sending it at all. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
