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

[Dave Taht]

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

In the home I think NPT should be on by default any time there is a
lease != 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 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.

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

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

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



-- 
Dave Täht

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