Hello Phil > Le 16 sept. 2020 à 14:51, Philip Homburg <pch-v6ops-9@xxxxxxxxxxxxxx> a écrit : > > >> >>> 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. > Certainly this is not what my pc or my phone do. They reach a dell known address from the OS vendor. Still there is no IETF spec / blessing / study about that behavior. > 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. > One reason is that we did not specify a better way. > 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. > This is listed as a cons already. >> 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. Actually I was pondering pinging the newly formed global address from an already formed link local one, passing ping the packet to the router at L2... -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
