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
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
On Sun, Jul 5, 2015 at 1:52 PM, Brian E Carpenter wrote: > On 06/07/2015 08:33, Dave Taht wrote: >> On Sun, Jul 5, 2015 at 12:57 PM, Brian E Carpenter >> 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
On 06/07/2015 08:33, Dave Taht wrote: > On Sun, Jul 5, 2015 at 12:57 PM, Brian E Carpenter > 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 12:57 PM, Brian E Carpenter 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
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
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
[homenet] I-D Action: draft-ietf-homenet-hncp-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Control Protocol Authors : Markus Stenberg Steven Barth Pierre Pfister Filename: draft-ietf-homenet-hncp-07.txt Pages : 33 Date: 2015-07-05 Abstract: This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices on top of the Distributed Node Consensus Protocol (DNCP). It enables automated configuration of addresses, naming, network borders and the seamless use of a routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-homenet-hncp-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
