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

[Ole Trøan]

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.

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

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

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

> * 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 know other people disagree with me, and would prefer that prefix lifetimes was 
tied to reachability.

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

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

cheers,
Ole