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

[Dave Taht]

On Tue, Dec 11, 2012 at 10:31 PM, Ole Trøan <otroan at employees.org> wrote:
> Dave,
>
>>> 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 translate between ULAs and globals.
>>
>> 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...

> 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.


> 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.

>
>>>>> 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.
>
> 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.

Actually I should probably have said /48 by default. Breaks less stuff.

>
> 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.

>
> 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.

>
> 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.

> 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.

>
> 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.

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.

>>>> 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 with 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.
>
> 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).
>>>
>>> shouldn't all interface have a /64?
>>
>> Not in the case of mesh links.
>
> ? please explain.

I gave up on getting anything other than a /64 years ago and switched
to /128s. For wireless, especially, using /64s is not terribly useful.

>>>> * 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 goes 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 lifetimes 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 RFC4193.
>>> 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.
>
> 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.

>
>> 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?

>
>> 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... ;-)
>>
>> 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)
>>>>
>>>> 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.
>
> 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
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html