Pascal Thubert \(pthubert\) <pthubert=40cisco.com@xxxxxxxxxxxxxx> wrote:
> Note to your points below (where we lost sync): this must be
> *completely transparent to the applications*. The idea in 1) would be
> that something like a tentative state where the address was formed in
> the stack but not available to the apps. There are a number of reasons
> for the stack to send a probe like this: prepare the NCE in the router
> as GRAND does, find a captive portal as my phone and PC do, assess the
> reachability from a ULA, check the MTU on the last mile...
If there is a captive portal, as indicated by RA and/or DHCP, then
communicating with it will do exactly the desired NCE actions.
My understanding is that iOS will start rotating MAC addresses *even on the
same network* every 12hours.
I have no idea what they will do with their L3 addresses.
I imagine they get recycled... but it would be interesting if they were
allowed to be kept for open sockets.
There is an assumption is that WPA-X will need to be invoked at that point,
and that will re-establish the identity of the phone to an upper layer, but
layer-2 snoops will not be able to track beyond that point.
(Maybe they won't bother on unenccrypted wifi, which is often used in
airports/hotels where captive portals are?)
At that point, the NCE will need to be updated again and any captive portal
will either have to be connected to the WPA auth-server (to get the updated
l2 address), or the phone will need to visit the captive portal again.
> That OS magic is largely OS -specific, unspecified and
> undocumented. Which means that we cannot validate its value and
> effects, we cannot count on it, and, as opposed to WiND, we cannot
> refer to it to explain what it is we dismiss as a possible
> solution. Since there is no standard, GRAND is bound to explain what it
> is dismissing so the reader can decide to buy the argument of not.
I understand your point.
It would be good to describe method (1) somewhere, if only because hosts will
continue to have to do this until the other methods are widely supported.
> Note that in the text above the stack does not need to get the
> packet(s) back. All it cares is too get an NS from a router in a very
> short time.
Do you propose that the host is actually looking to receive that NS?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
