Re: [homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
Hello everyone, this is HNCP revision 07 addressing comments mainly from Mikael, Juliusz and a few others as well as some updates to use the latest version of DNCP. Even though the WGLC is still running, we wanted to publish a new version before the IETF draft deadline for any further reviewers. There were mostly clarifications and additional explanations in this revision, though we changed the HNCP Version TLV to use version 1 in this revision. This was mainly to address behavior of the existing implementations. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
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. 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
On Sun, Jul 5, 2015 at 12:57 PM, Brian E Carpenter brian.e.carpen...@gmail.com 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. 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 homenet@ietf.org 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
On 06/07/2015 08:33, Dave Taht wrote: On Sun, Jul 5, 2015 at 12:57 PM, Brian E Carpenter brian.e.carpen...@gmail.com 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. Please not shoot messenger. 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
On Sun, Jul 5, 2015 at 1:52 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 06/07/2015 08:33, Dave Taht wrote: On Sun, Jul 5, 2015 at 12:57 PM, Brian E Carpenter brian.e.carpen...@gmail.com 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 homenet@ietf.org 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
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... Well we are referencing normative language of RFC 7084 in HNCP, which means that RFC 6092 is a SHOULD for us and with that basically stateful firewalling. Heh. Well, is there any thinking over there about how to tie this into mdns or dns, sanely? Well MDNS is the node's own responsibility mostly. Since that is not really platform default everywhere we also specify naming based on hostnames acquired via (stateful) DHCPv6/v4 which is turned on in addition to SLAAC on routers that support it. Our reference implementation uses this - if ULAs are present - only for ULA addresses. With only SLAAC you cannot really do proper naming. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
