Hi, Hugo Maxwell Connery wrote (11 Dec 2014 15:01:11 GMT) : > Here is a recent presentation: > https://www.ietf.org/proceedings/90/slides/slides-90-dhc-6.pdf
I'll look it up, thanks! > (I am not associated with the WG or the slide presenter in any way) > I do not suggest that you wait for the IETF, but that once you have consensus > for your target(s) that you inform the WG listed above of your choices, such > that they may be worked into a standard, if that is appropriate and/or > possible. Seems to make sense (but I've very little understanding of the IETF processes -- dkg will surely be able to correct us if we go off-tracks). > == MAC Address Handling == > I see two approaches for dynamic MAC address handling: Privacy at all cost, > and Give me an address ASAP. > In the first case, one would wish for as many as possible registrations of > the same > MAC address on as many link local networks as possible. Thus, there should be > a list of agreed, preferred addresses to take from an agreed pool of > addresses. > (Does such an open "cannot be claimed by manufacturers" MAC address pool > exist? > I admit my ignorance). > The client should use these by preference, only choosing the next if the > previous > was already claimed on the link local network (ARP query). > In the second case, a randomised scheme seems the most useful. It would > reduce > the likelihood of conflicts with existing registrations, but expose whatever > ideosyncrasies > of the randomisation scheme may exist. I fail to see what this has to do with DHCP, since MAC addresses don't leak via DHCP requests only. May you please elaborate? (if the above-mentioned presentation explains this, just tell me, and then I'm sorry.) Cheers, -- intrigeri _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
