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

[Ole Trøan]

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?
if we have to do IPv6 NAT by default, then I think we have lost. you might as well stick to IPv4. ;-)

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

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

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

if you only get a /64 in PD:
 - IPv6 bridge links and assign the /64 to the LAN interface
 - do multilink subnet routing (if we get ND ARO implemented)
   (/128 host routes)
 - complain to your ISP

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.

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?

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

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

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

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

> 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