> > This has huge privacy and security implications. > > This is way, way too vague to be useful in the cons section. Can > you please elaborate, like an example attack? Also, is the current > stack behavior exposing the user to that threat as well? Suppose every device basics pings $vendor.com when it gets a new address as part of a very low level function of the stack. So basically we spend a lot of time worrying about tracking devices. We have randomized MACs. We avoid embedding MAC addresses in IPv6 addresses and then we have all devices advertise what their vendor is and their current addresses. Anybody who wants to do monitoring will have a field day. I know that mobile devices do some weird stuff, but not all devices are mobile devices. And the whole captive portal discovery seems to be mostly a flight between device vendors and captive portals. There is no technical reason it has to be this ugly for mobile devices. The situation would be better if there were a well-known anycast address. However that has operational implications (pinging $vendor as well, because it has happened often enough that vendors stopped renewing the DNS registrary after they stopped supporting a particular brand of devices). Even the well-known address may cause operational problems for disconnected operation. > See > https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-03#section-8.3 Of the disadvantages: - The first point can be solved by pinging the first hop router - The second point also applies to pinging an off-link destination - There can always be broken middle boxes. I.e., if a wireless device does ND proxying then it is up to the network admin to make sure that the router has enough capacity to perfom ND. In any case, the existance of weird middle boxes should not be a reason to start pinging off-link destinations. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
