On Sun, Jul 5, 2015 at 1:52 PM, Brian E Carpenter <[email protected]> wrote: > On 06/07/2015 08:33, Dave Taht wrote: >> On Sun, Jul 5, 2015 at 12:57 PM, Brian E Carpenter >> <[email protected]> wrote: >>> Hi, >>> >>>> Stateless assignment based on Modified EUI64 interface identifiers >>>> [RFC4291] SHOULD be used for address assignment whenever possible, >>> >>> This is new and problematic. EUI64 is pretty much deprecated now, see >>> https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-07 >>> (in IETF Last Call) for background, and https://tools.ietf.org/html/rfc7217 >>> https://tools.ietf.org/html/draft-ietf-6man-default-iids-04 for >>> the way forward. >> >> Oy. One of the things I rely on is mark 1 eyeball when a device is >> renumbered, or has multiple ipv6 addresses. Recognizing the std SLAAC >> hex vomit pattern is VERY hard, but at least I can find things >> again.... >> >> Lacking any decent naming support is a real PITA when your lower level >> identifiers are random and changing all the time. > > Yep. That is of course the intended effect from a privacy point of view. > I expect that enterprise network managers will hate it too.
Well, even in the home, I still regard there being a need for at least SOME perimeter defense - at the moment I am leveraging the source specific routing information to establish clear paths within my network, and to then also block known to be problematic protocols originating outside it - like CIFS, and port 80/443/661 from the outside (way too many default passwords on way too many devices, like cameras), and for that matter, port 53... > Please not shoot messenger. Heh. Well, is there any thinking over there about how to tie this into mdns or dns, sanely? having better source address selection policies on the hosts? perimeter defense? > Brian > >>>> otherwise (e.g., for IPv4) the following method MUST be used instead: >>>> For any assigned prefix for which SLAAC cannot be used, the first >>>> quarter of the addresses are reserved for routers HNCP based address >>>> assignments, whereas the last three quarters are left to the DHCPv6 >>> >>> That would only be acceptable, I think, if you also specify that >>> pseudo-random >>> allocation is used within the 1/4 and 3/4 of the addresses (referring >>> to IPv6 only). >>> >>> Brian >>> >>> >>> _______________________________________________ >>> homenet mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/homenet >> >> >> -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
