From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "ams-iport-1.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 620D521F1B3 for ; Tue, 11 Dec 2012 13:31:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEHADqlx1CQ/khM/2dsb2JhbABFg0i7BhZzgh4BAQQBJ0UNBQsLEjRJDgaIHgarK5BHiw6FHmEDm3KKXYJ0 X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="148131469" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2012 21:31:05 +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 qBBLV4jT025967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Dec 2012 21:31:04 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 11 Dec 2012 22:31:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8F973FF7-B39D-4E21-B889-14F6105A29F4@employees.org> To: Dave Taht X-Mailer: Apple Mail (2.1499) 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 21:31:08 -0000 Dave, >> coming at this with an IETF 6man/homenet/v6ops hat on. >>=20 >>>>> * 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 >>> /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? >>=20 >> or create state... >> NPT should not be on by default though, and should definitely not = translate between ULAs and globals. >=20 > In the home I think NPT should be on by default any time there is a > lease !=3D infinity. why? to create stable addressing in the home? if we have to do IPv6 NAT by default, then I think we have lost. you = might as well stick to IPv4. ;-) ULAs are meant to solve the stable addressing problem for internal = applications. you will have reasonable stable addresses (global) that will exist side by side with the ULAs. = applications can pick address based on what properties they want. (see my reservations about current ULA support in hosts in = the reply to Steven). >>>> 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. >>=20 >> agree. >>=20 >=20 > 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. with that ISPs delegate an address block larger than /64. we are trying to educate ISPs that anything else isn't going to work and = is going to result in customer calls. > I certainly hope that we will see /56s by default. With only a /64 the > default becomes full NAT. there are a few cases here. if you _only_ get a /64 on the link-net between CPE and ISP then do one = of the following: - don't enable IPv6 on the LAN - proxy ND if there is only one LAN interface if you only get a /64 in PD: - IPv6 bridge links and assign the /64 to the LAN interface - do multilink subnet routing (if we get ND ARO implemented) (/128 host routes) - complain to your ISP depending on topology, it is in my view better to not enable IPv6 on the = LAN side, if the ISP doesn't delegate sufficient address space to run a = service. there is an argument to be made, that if we are so clever that we make = CPEs function well with a /64, then that will encourage ISPs to be = parsimonious with address space. what are they doing next, a /80? one of the reasons we have the 64 bit boundary in IPv6 is to make it = very difficult to give anything less than 2^64 addresses to a site. we should keep trying to make it very difficult to provide less than a = /56-/60 to a site also. I'd be happier if no CPE could do handle it (and certainly not on by = default). >>> 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. >>>=20 >>> * For ULA fd00::/48, the first /64 would be fd00::/64, the 2nd >>> fd00:0:0:1::/64 etc. >>=20 >> 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). >=20 > 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). >=20 > Whoever wrote that must have had an atomic clock in their basement. guess so. ;-) >>> * 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). >>=20 >> shouldn't all interface have a /64? >=20 > Not in the case of mesh links. ? please explain. >>> * 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). >>=20 >> 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. >=20 > I agree. >=20 >>=20 >> I know other people disagree with me, and would prefer that prefix = lifetimes was >> tied to reachability. >=20 > The two concepts are not entirely disjoint. >=20 >>=20 >>> 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. >>=20 >> 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. >=20 > 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. why not? IPv6 renumbering is designed in from the beginning. and if you have managed to stifle your laughter from that claim, it can = actually be made to work. > 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... >=20 > In even the slightest complex network design, with ONE hard coded ipv6 > address, is enough to mess up your whole day on a renumber. yes, to ensure renumbering works, let's make sure to renumber often. > 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. we can argue what benefit that firewall has. assuming your mom has a = reasonable recent OS. >> 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... ;-) >=20 > But then have your network go down when your lease distribution > mechanism is interrupted, like when a hurricane sandy goes by. ULAs are designed to solve that problem. with two comments: 1) the intention of Prefix Delegation was for it to be a replacement of = a fax. that the global address space would be long lived, as in a lifetime equal to the contract period with the ISP 2) given some (misguided) deployments using short lifetimes and your WAN = link goes down, what is the harm in continuing to use that global address space, until the WAN link comes back up again? >>>> 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 >>> 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. >>=20 >> re-using the subnet id part for both the ULA and the global prefix = would certainly make sense. >=20 > 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... >=20 > 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. >=20 > 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. why are we doing IPv6 in the first place? to restore the end to end Internet, right? I would like an application on my host, to advertise itself with service = discovery (DNS-SD), and then be externally available using that name -> address mapping. I = would like referrals to work, without middle boxes. if you force all IPv6 applications to expect a NAT. then we're not much = better off than were we are with IPv4. see bath water and baby... > Openwrt can manage however it likes, as can homenet. I'll ride along > and certainly will revise my opinions as experience dictates. so will I ;-) cheers, Ole