From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-f170.google.com (mail-ia0-f170.google.com [209.85.210.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6042021F176 for ; Tue, 11 Dec 2012 12:25:32 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id i1so13970942iaa.1 for ; Tue, 11 Dec 2012 12:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JL+WoO8fCtQA4mzDOT07vNyyTCv65TT5XM3xI2ppAI8=; b=muvUAE7tu+j/nnVeRE0TXR65w3+iHamwh71xfkLYZ6s5WdTlhu5CE769awzxhEj6nN vvVYVgrflEz1t2aZ/2tQUddSL5lTkFaY+VKzDXbyQfqSEOn/2izbUMBufYc+pPopEIl5 aNRpe5CVcvFSDPm2Wnxq98ewoBL4Hh7FLjNj1XmANiQtnqK9rTell5OdqIpXK44rJ+DH N3ILJN0vqtO1+G4Uo1w798D82LefcQ7iqsqAnzrMwKCpZ8h+7hj0/mFtzzzg1NvRoVTq SMfoHh1kJjMPYVaqwY77pZEJC18zloFXCkCIayQ1EDAYmA6diPyS7A7qpuddfdv/oPCT cCSA== MIME-Version: 1.0 Received: by 10.50.150.144 with SMTP id ui16mr11324207igb.68.1355257531499; Tue, 11 Dec 2012 12:25:31 -0800 (PST) Received: by 10.64.135.39 with HTTP; Tue, 11 Dec 2012 12:25:31 -0800 (PST) In-Reply-To: <8F973FF7-B39D-4E21-B889-14F6105A29F4@employees.org> References: <8F973FF7-B39D-4E21-B889-14F6105A29F4@employees.org> Date: Tue, 11 Dec 2012 21:25:31 +0100 Message-ID: From: Dave Taht To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Steven Barth , "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 20:25:32 -0000 On Tue, Dec 11, 2012 at 8:56 PM, Ole Tr=F8an wrote: > 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). >>> >>> Hmm. The homenet folk have a prefix assignment and router discovery >>> process defined in their PD over ospf (somewhat crazy) >>> implementation... >>> >>> 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. >> >> cerowrt would run into problems if the ISPs would only assign a single >> /64. Even NPT would not help here as two distinct ULA /64 could not be >> mapped to the same public /64 without the possibility of collisions. So >> it might be necessary to relay between the downstream interfaces in this >> 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 transla= te between ULAs and globals. In the home I think NPT should be on by default any time there is a lease !=3D infinity. >>> However I guess and from what I have seen most ISP will probably assign >> a /56 or at least a /60. For OpenWrt a /64 would not so problematic as >> there is - by default - only 1 (bridged) lan-interface so a single /64 >> is sufficient for most users. > > agree. > With which part? A single /64 is totally insufficient for a very large percentage of users. A percentage that cannot be adaquately measured because what they do with their internal networks is currently their own business. I certainly hope that we will see /56s by default. With only a /64 the default becomes full NAT. >> This is how the prefix distribution works either for the ULA or the >> public prefixes. I've implemented this straight forward not looking at >> any specification as the local prefix distribution should not be >> mandated imo by any RFC. >> >> * For ULA fd00::/48, the first /64 would be fd00::/64, the 2nd >> 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 wi= th your neighbour. > (overlapping ULA space). Except that that specification requires that you have both ntp time (which you don't when you first boot a router) and first boot randomness (which is getting better). Whoever wrote that must have had an atomic clock in their basement. >> * Padding (unused adress-space) is added if the alignment cannot be >> satisfied (e.g. one interface wants a /64, the second a /62, then there >> will be a padding or 1 /64 and 1 /63 in between). > > shouldn't all interface have a /64? Not in the case of mesh links. >> * If a downstream-interface goes down, its assigned prefix is preserved >> in case it later comes up again. >> * Assignments for a public prefixes are forgotten once the prefix is >> removed (e.g. wan goes down). > > I'm uneasy about removing a delegated prefix just because the WAN link go= es down. > one should really only remove the delegated prefix when: > - the lifetimes expire > - the CPE is connected to a different domain. I agree. > > I know other people disagree with me, and would prefer that prefix lifeti= mes was > tied to reachability. The two concepts are not entirely disjoint. > >> In the current implementation the NPT will map the public prefix to the >> 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 >> not be mapped so care has to be taken. This is a bit unpredictable - I >> know - but in the end we cannot know what size the public prefix from >> the ISP will be and I guess if there are only a few /64-downstream >> 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 R= FC4193. > but it boils down to the fact that we do not want to push NATs for IPv6. Without an infinite lifetime on your IPv6 lease I see no other choice than npt66 or map... Period. So that means that a static tunnel or a provider assigned permanent lease is just fine, and we won't nat for that. IF all you get is a dynamic lease, nat it is. It's taken me 15 years and the arrival of a decent nat translation mechanism to come down to this decision. Also seeing hurricane sandy take out friends of mine for 2+ weeks and watching others put together ad-hoc networks out of desparation... In even the slightest complex network design, with ONE hard coded ipv6 address, is enough to mess up your whole day on a renumber. Lastly, I cannot make the concept of a firewall go away and leave mom's computer entirely unprotected, as much as homenet would like us to. > 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 assi= gned to an interface. > a ULA address, while having global scope, does not have global reachabili= ty. > actually it should not be expected to have global reachability. > doing ULA to global translation by default would break one of the ideas w= e have in the homenet WG, > about allowing devices on the network not being prepared to be on the glo= bal Internet use ULAs. that way > we can avoid firewalls on the network borders, and still protect the unpr= epared... ;-) But then have your network go down when your lease distribution mechanism is interrupted, like when a hurricane sandy goes by. > >>> 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) >> >> I'm currently wondering if it would make sense to implement a >> randomization strategy in case we have e.g. a /56 prefix and only want >> to assign one or two /64 so that the /64 would not always be ...1::/64 >> and 2::/64 but it would be a bit complicated with the dynamic prefix >> assignment of downstream-interfaces and especially when it comes to ULA >> 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. I'm kind of resistant to using :1, :2. Let a random attacker search your whole address space.... what I currently do is just let slaac or ahcp assign addresses, get a good name from dns, and route... These are just my opinions, driven by 2 years now of trying to make ipv6 work in the real world, with real daemons, with real applications. Cerowrt will default to a ula only with NPT66 where a /60 or better is available but it is not an infinite lease. Full Nat when there is only a 64. There will be a toggle option in the gui/config file to do differently. Openwrt can manage however it likes, as can homenet. I'll ride along and certainly will revise my opinions as experience dictates. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html