From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "ams-iport-4.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1F59A21F0A2 for ; Tue, 11 Dec 2012 11:56:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAHAD6Px1CQ/khM/2dsb2JhbABFg0i7BhZzgh4BAQQ7Mg0FFg4EfRSIHgarHZBWkCxhA5tyil2CdA X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="10348783" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 11 Dec 2012 19:56:49 +0000 Received: from [10.61.102.133] (dhcp-10-61-102-133.cisco.com [10.61.102.133]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBBJum2e009938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Dec 2012 19:56:49 GMT From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Dec 2012 20:56:48 +0100 Message-Id: <8F973FF7-B39D-4E21-B889-14F6105A29F4@employees.org> To: Steven Barth Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Current state of ipv6 in openwrt barrier breaker X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:56:53 -0000 Steve, et al, coming at this with an IETF 6man/homenet/v6ops hat on. >>> * Prefixes are automatically split up and distributed over >>> downstream-interfaces OR by choice mapped to an ULA-address (NPT66). >>=20 >> Hmm. The homenet folk have a prefix assignment and router discovery >> process defined in their PD over ospf (somewhat crazy) >> implementation... >>=20 >> My expectation here is that ISPs are going to be parsimonious in >> handing out anything bigger than a /64, certainly anything bigger = than >> a /56 is going to be scarce. So I'd hope that address assignment = using >> NPT66 would start with the bottom addresses and work up. >=20 > cerowrt would run into problems if the ISPs would only assign a single=20= > /64. Even NPT would not help here as two distinct ULA /64 could not be=20= > mapped to the same public /64 without the possibility of collisions. = So=20 > it might be necessary to relay between the downstream interfaces in = this=20 > case so that they share a /64 or did you have something else in mind? or create state... NPT should not be on by default though, and should definitely not = translate between ULAs and globals. > However I guess and from what I have seen most ISP will probably = assign=20 > a /56 or at least a /60. For OpenWrt a /64 would not so problematic as=20= > there is - by default - only 1 (bridged) lan-interface so a single /64=20= > is sufficient for most users. agree. > This is how the prefix distribution works either for the ULA or the=20 > public prefixes. I've implemented this straight forward not looking at=20= > any specification as the local prefix distribution should not be=20 > mandated imo by any RFC. >=20 > * For ULA fd00::/48, the first /64 would be fd00::/64, the 2nd=20 > fd00:0:0:1::/64 etc. I think the the ULA prefix should be created as specified in RFC4193. otherwise you'll get into trouble merging networks, or building a mesh = with your neighbour. (overlapping ULA space). > * Padding (unused adress-space) is added if the alignment cannot be=20 > satisfied (e.g. one interface wants a /64, the second a /62, then = there=20 > will be a padding or 1 /64 and 1 /63 in between). shouldn't all interface have a /64? > * If a downstream-interface goes down, its assigned prefix is = preserved=20 > in case it later comes up again. > * Assignments for a public prefixes are forgotten once the prefix is=20= > removed (e.g. wan goes down). I'm uneasy about removing a delegated prefix just because the WAN link = goes down. one should really only remove the delegated prefix when: - the lifetimes expire - the CPE is connected to a different domain. I know other people disagree with me, and would prefer that prefix = lifetimes was=20 tied to reachability. > In the current implementation the NPT will map the public prefix to = the=20 > lower part of the ULA, meaning a public /56-prefix will be mapped onto > fd00::/56 if the ULA is fd00::/48 and everything outside this /56 = would=20 > not be mapped so care has to be taken. This is a bit unpredictable - I=20= > know - but in the end we cannot know what size the public prefix from=20= > the ISP will be and I guess if there are only a few /64-downstream=20 > interfaces it is unlikely to clash for a majority of users. here it sounds like you translate ULA source addresses to global space? please don't do that by default. there is some reasoning in RFC6204 and = RFC4193. but it boils down to the fact that we do not want to push NATs for IPv6. ULAs are quite different in the IPv6 addressing architecture than = RFC1918 addresses in IPv4. in IPv6 it is expected that multiple addresses of different scope is = assigned to an interface. a ULA address, while having global scope, does not have global = reachability. actually it should not be expected to have global reachability. doing ULA to global translation by default would break one of the ideas = we have in the homenet WG, about allowing devices on the network not being prepared to be on the = global Internet use ULAs. that way we can avoid firewalls on the network borders, and still protect the = unprepared... ;-) >> Somewhat related to that, is the concept of actually USING ipv6 for a >> few things that it's good at. For example, a much greater randomized >> port space can be gained if the dns server is the only daemon >> listening on a dedicated ipv6 address (like a ::3) >=20 > I'm currently wondering if it would make sense to implement a=20 > randomization strategy in case we have e.g. a /56 prefix and only want=20= > to assign one or two /64 so that the /64 would not always be ...1::/64=20= > and 2::/64 but it would be a bit complicated with the dynamic prefix=20= > assignment of downstream-interfaces and especially when it comes to = ULA=20 > and us not knowing before-hand what length the public prefix will be. re-using the subnet id part for both the ULA and the global prefix would = certainly make sense. cheers, Ole=