On Tue, 31 May 2011 09:24:19 -0700 james woodyatt <[email protected]> wrote:
> On May 30, 2011, at 7:38 PM, Fred Baker wrote: > > > > [...] IPv6 systems come, at least today, with SLAAC as the default. So > > there is a requirement to configure DHCPv6, at least from that perspective. > > That said, SLAAC ain't gonna happen in the absence of RAs, and you can > > disable RAs on the router. So if an interface comes up and no RA is > > forthcoming, I could imagine the thing probing with a DHCPv6 request. [...] > > For what it's worth, the behavior of Apple's iOS 4.3 and later is > straightforward. If there is no RA, then there is no IPv6. iOS 4.3 doesn't > support manual IPv6 configuration, so automatic configuration is the only way > to plumb it. The DHCPv6 client only starts if the router indicates > availability with O=1. Remember when I was complaining that we needed RFC > 6106 for the O=0 case? Given that we have that, I don't see any benefit to > starting the DHCPv6 client unless a router explicitly tells us to expect > service. No router? No need for dynamic host configuration. > Actually, that raises an interesting question. If SLAAC and DHCPv6 were enabled by default, ignoring the M and O bits, what type of DHCPv6 is enabled - stateless or stateful? I'm sure people are expecting stateful, so the DHCPv6 client would initially issue a Solicit and including IA_NA and IA_TA options. My understanding is that if a DHCPv6 server won't ever provide any addresses (as it is a "stateless" server), it is to ignore those Solicit messages. Since the end-node may have also acquired addresses via SLAAC, it eventually wouldn't care. However, it would have to timeout the Solicits as per RFC3315, just in case there was a stateful DHCPv6 server available. I understand this retransimission/timeout period is 120 seconds (SOL_MAX_RT). At that point, it should then resort to stateless operation, using an Information-Request message, to acquire Other DHCPv6 supplied options. So 2 minutes would need to elapse before the client would receive options it is interested in via stateless DHCPv6. That's an awfully long time to wait to find out other DHCPv6 option values that can't be supplied in an RA as per RFC6106. Perhaps a stateful and stateless DHCPv6 transaction could be performed in parallel to avoid this 2 minute delay. I think that would create another possible conflict. What if the non-address option values that are received via the stateless DHCPv6 transaction are different to the non-address option values supplied by a stateful DHCPv6 server? The current selection of either stateful or stateless DHCPv6 operation for a segment via M&O bits, and then a DHCPv6's client's selection of a single DHCPv6 server to continue or have a transaction with avoids this option value mismatch ambiguity. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
