On Wed, Jan 28, 2015 at 2:07 PM, Ted Lemon <[email protected]> wrote:
> On Jan 28, 2015, at 2:02 PM, Warren Kumari <[email protected]> wrote:
>> The reason I prefer this to "whatever finishes first" is that it is a
>> bit more deterministic and so easier to troubleshoot. I also don't
>> clients to connect to http://<uri-from-dhcpv6> one day, after an OS
>> upgrade, suddenly start connecting to http://<uri-from-ra>. In theory
>> (and if the CP operators is sane) the <uri-from-dhcpv6> ==
>> <uri-from-ra>, but...
>
> In practice it's always going to be RA-first, because DHCPv6 doesn't start
> until after RA.
Oh. Huh. Yeah, that didn't occur to me :-P
> And it's likely going to be non-deterministic whether it's RA-first or
> DHCPv4-first, rather than being a function of some implementation detail in
> the O.S.
>
> So I think Joel is right that there's no benefit to insisting on an ordering.
I wasn't really *insisting*, more of a general statement ("If the
device gets different URIs (for example, via DHCPv6 and IPv6 RA) it
should try them in the following order: DHCPv4, DHCPv6, RA."), but
happy to remove that.
> I think you should just say that the ordering is indeterminate, and if
> different mechanisms give non-equivalent answers, this is likely to cause
> operational problems in practice.
Done!
"In order to support multiple "classes" of clients (e.g: IPv4 only,
IPv6 only with DHCPv6, IPv6 only with RA) the captive portal can
provide the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, IPv6 RA).
The captive portal operator should ensure that the URIs handed out are
equivalent to reduce the chance of operational problems."
Version -10 posted. This is a nice, round number...
W
>
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
