[Cerowrt-devel] Current state of ipv6 in openwrt barrier breaker

[Ole Trøan]

Dave,

[...]

>>> In the home I think NPT should be on by default any time there is a
>>> lease != infinity.
>> 
>> why? to create stable addressing in the home?
> 
> 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.
> 
> This approach (flavored by my 3rd world experience with things like
> OLPC) colors my approach to everything.
> 
> ... 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.
> 
> 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.
> 
> 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
> 
> git remote add whoever git://whoever.local/home/whoever/thetree.git
> 
> 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. ;-)
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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
> 
> 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
> 
> 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.
> 
>> - do multilink subnet routing (if we get ND ARO implemented)
>>   (/128 host routes)
>> - complain to your ISP
> 
> 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.
> 
> 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?
> 
> 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).
> 
> 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.
> 
> 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.
>> 
>> 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.
> 
> 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...
>>> 
>>> 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.
> 
> Just as an example:
> 
> 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