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 4571B21F1C4 for ; Wed, 12 Dec 2012 01:08:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgURALlIyFCQ/khL/2dsb2JhbABFg0i6TgQDgQUWc4IeAQEEAXkFCwsSNEkBDQaIHgYMvEeLD4FRg01hA5cjjyyCdIFj X-IronPort-AV: E=Sophos;i="4.84,265,1355097600"; d="scan'208";a="148150928" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Dec 2012 09:08:33 +0000 Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (dhcp-lys02-vla252-10-147-117-91.cisco.com [10.147.117.91]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBC98V1l019713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 09:08:31 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: Wed, 12 Dec 2012 10:08:30 +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: Wed, 12 Dec 2012 09:08:35 -0000 Dave, [...] >>> In the home I think NPT should be on by default any time there is a >>> lease !=3D infinity. >>=20 >> why? to create stable addressing in the home? >=20 > I finally figured out something today. I've been trying to build a > network that "just worked" in places where the internet doesn't exist > (yet) - which is roughly 2/3s of the users on the planet. To be able > to connect two arbitrary machines together with zero configuration. To > get something that would let Jose's machine shop in one part of town > connect to Jorge's printer down the street, because that's the only > printer for 100 kilometers. >=20 > This approach (flavored by my 3rd world experience with things like > OLPC) colors my approach to everything. >=20 > ... I'd prefer a network that just worked, within, and *between* > homes. Internet connectivity, while nice, is optional. Getting to > where you can just wave a box in the air, and be on a network, is > seemingly a design goal for me. >=20 > I didn't realize this until this morning, I'll have to think about it. > Maybe I'm weird, but the principal purpose in having a network used to > be to connect up useful, local services to other useful, local > services. >=20 > The other day I sat, in disbelief, in a a room with several students, > when they all had git trees of the project, and the internet was down. > They started passing around a usb stick, and didn't know about the > whatever.local trick. I showed them that they could, indeed, just pass > the objects around locally, with a >=20 > git remote add whoever git://whoever.local/home/whoever/thetree.git >=20 > and they all remarked on how much faster it was... I fully support your use case. originally IPv6 link-local addresses was = designed for something similar, although limited to a single link. "the dentist's office". I just want us to see if we can support this use case without breaking = the architecture (too much). >> if we have to do IPv6 NAT by default, then I think we have lost. you = might as well stick to IPv4. ;-) >=20 > No, having ULAs - distinct numbering - is what is useful about ipv6 in > this scenario. agree. >> 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). >=20 > I love it when I hear "Host vendors should fix their boxes". I would > prefer that people making the architectural decision to assign work to > someone else, either find a way to pay for it, or do the work on those > hosts to enable the vision. >=20 > 10 year tail here, to deal with. although support for multiple IPv6 addresses of different scope has been = part of the IPv6 architecture from the beginning. it has taken a long time to get proper support for that into hosts. e.g. Windows as far as I know has a decent implementation of RFC3484. [...] >>> I certainly hope that we will see /56s by default. With only a /64 = the >>> default becomes full NAT. >=20 > Actually I should probably have said /48 by default. Breaks less = stuff. from the deployments I see, 'default' will be /56. some cases of /60 = (largely because of 6rd), and a few ISPs that let you choose /48 if you want to. I don't see why anything but /48 would break anything though? >> 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 >=20 > Bridging various forms of wifi together with gigE is contributing to > the collapse of wifi networks around the world. yes. break IPv6 applications with NAT, or suffer poor wifi = performance... take your pick. ;-) >> if you only get a /64 in PD: >> - IPv6 bridge links and assign the /64 to the LAN interface >=20 > I just continue to disbelieve that there will only be one lan > interface. Everybody that shares a network splits them up. In small > business, especially, there is almost always a dmz, a business > network, and a guest network. >=20 >> - do multilink subnet routing (if we get ND ARO implemented) >> (/128 host routes) >> - complain to your ISP >=20 > Just use /128s. how? http://tools.ietf.org/html/rfc4903 describes some of the issues with = multilink subnet routing. it is theoretically possible to make this work with a combination of = only DHCPv6 for address assignment and a routing protocol, or the new address registration options in ND. but barring that I don't = see how you can make this work well today. >> 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. >=20 > In my view I don't want to have to care. I agree with the goal. for separation between home network topology and = the provider network, I'd much rather us ILNP, or even LISP. at least then you don't break apps. >> 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? >=20 > I think that would break everything rather thoroughly. But the best we > can expect is a /64 in the present day, and I'd prefer to be able to > test ipv6 more thoroughly, inside the home, rather than wait for > better delegation policies. There are plenty of other tools that will > break. the "best" you can expect today is an address block of /48 - /60. the worst you can expect is a /64 on the link-net and no PD. I suggest = you don't support that case. >> 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). >=20 > Sorry. I note that at least part of my purpose in planning to use > npt66 by default is to get it thoroughly tested. In various phases of > cerowrt's development I have made 6to4 the default, tried every dhcpv6 > client, enabled tunneling, and so on. >=20 > Of these, 6to4 worked the best on networks that had relays. Second > best was hurricane's tunnels. A distant last was native ipv6. 6to4 and "worked the best", has to be an oxymoron. ;-) > I certainly expect npt66 to have bugs. That's in part, what cerowrt is > designed to flush out. I also look forward to trying the new dhcpv6 > client, which has a code base that is actually understandable and > delightfully small. indeed. ;-) [...] >>> 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. >>=20 >> 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. >=20 > The list of applications that need to be modified to support that is > rather long. I wouldn't mind if someone(s) put resources into fixing > all those. yes, I think we should. the applications you know of, could you list = them on the cerowrt wiki, and those of us interested in getting renumbering to work seamlessly = could start working on that? >>> 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. >>=20 >> yes, to ensure renumbering works, let's make sure to renumber often. >=20 > Just as an example: >=20 > How do you setup a tunnel to another location? another level of indirection. set up the tunnel to "superhost.taht.org." applications should not use = addresses directly. Best, Ole