On May 31, 2011, at 6:41 PM, Mark Smith
<[email protected]> wrote:
> 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
Working from memory, there's an error code through which a DHCPv6 server can
explicitly NAK an address assigment request.
- Ralph
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
