James, I am saying when the M bit is clear, then a node cannot acquire an address using DHCPv6. However, I agree with you DHCPv6 is much better alternative than PPP.
Now, I'd like to focus the discussion back to how will the PPP peer (which is a server) going to fix the bug when this peer hasn't responded to the NUD unicast NS? I have already said the source PPP client that issued the unicast NS is 2461bis complaint. Hemant -----Original Message----- From: James Carlson [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 12:18 PM To: Hemant Singh (shemant) Cc: Ole Troan (otroan); [EMAIL PROTECTED]; JINMEI Tatuya / ????; [email protected]; Dave Thaler Subject: RE: Neighbor Discovery and PPP links Hemant Singh (shemant) writes: > The topic under discussion is how does a SLAAC PPP client acquire an > IPv6 address using DHCPv6? Using stateful DHCPv6 (with the RA 'M' bit set to one), of course. > Yes, stateless DHCPv6 can be used to dole out options to the SLAAC > client but you cannot have the SLAAC client obtain an IPV6 address > with stateless DHCPv6. If you're trying to assign addresses via stateful means (DHCPv6 is the defined stateful addressing mechanism for IPv6), it's unclear to me why you'd ever want stateless DHCPv6 as a solution. It seems like a contradiction in terms. It is, though, possible to use stateless and stateful address assignment in parallel if one wishes, and (to the previous posters comments) DHCPv6 also works fine in a stateless context to provide the "other" configuration parameters, even when all addresses in use are either stateless or are manually configured. It's a simple request-response mechanism, and no more troublesome to implement than adding yet another PPP option -- though the architectural issues are substantially different. The architecture differs because PPP messages themselves cannot be 'routed' or proxied, but DHCP messages can, meaning that DHCP also serves nodes located _behind_ the PPP termination point, but additional PPP options cannot. That alone makes a PPP-based solution to the (off-topic) issues raised by the other poster much less attractive, regardless of its supposed "simplicity." -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
