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

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

[Dave Taht]

I just noticed this thread went over to cerowrt-users and
cerowrt-devel is the right place to discuss these issues.


---------- Forwarded message ----------
From: Steven Barth
Date: Mon, Dec 10, 2012 at 9:38 AM
Subject: Re: [Cerowrt-users] IPv6 router advertisements on custom interfaces
To: cerowrt-users <cerowrt-users@lists.bufferbloat.net>


Fyi I've commited a new ipv6-support version to OpenWrt yesterday.

This includes (partly untested) all features I want to see in there
for OpenWrt except the integration of dnsmasq-dhcpv6 (which will
follow later once the dynamic configuration features have been added
to it) and the WebUI which is still on the ToDo.


So far the current IPv6-featureset is:

* Support for native IPv6 with static configuration
* Support for native IPv6 with DHCPv6-Prefix Delegation
* Support for native IPv6 without PD via relaying or masquerading
* Support for 6in4, 6to4 and 6rd
* Prefixes are automatically split up and distributed over
downstream-interfaces OR by choice mapped to an ULA-address (NPT66).


Help, documentation and configuration examples for yesterdays version
can be found here (there were a few changes for the new NPT-support):

http://wiki.openwrt.org/doc/uci/network6


Especially the NPT / NAT-related stuff has seen very little testing
and of course only works with a Kernel >= 3.7 and ip6tables >= 1.4.17.


On 10.12.2012 08:56, Dave Taht wrote:
>
> Radvd is going away in the BB ("barrier breaker" - openwrt head)
> version of openwrt, fairly soon. It deserves to die...
>
> There is going to be a merger of the DHCPv6/SLAAC and naming
> functionalities in dnsmasq and the dynamicism of the new ipv6-support
> package, which also includes a spanking new dhcpv6-pd client..
>
> Also planned is to (once the 3.7 kernel lands) make npt66 the default
> (for most users). So in a couple weeks, all the underlying ipv6
> infrastructure in openwrt and cerowrt is going to change.
>
> As to whether the 6in4 case is fully handled as of now in that system,
> damned if I know. Same goes for 6to4... I put the ipv6-support package
> into cerowrt 3.6.9-5, all forms of ipv6 are blocked at the lincs lab,
> can't test it, right now.
>
> As for how to fix it in cerowrt 3.3.8, it was always problematic as
> hell, and I'm glad the work is being re-architected in BB by two of
> the most competent people I know, and I've signed cerowrt (and thus,
> y'all) up to test it when it comes out. It would be great to recruit
> more help, because *this time* we're going to get it right, come hell
> or high water.
>
> I'm very pleased, in particular, with dnsmasq's naming support for
> slaac. It "just works".
>
>
> On Mon, Dec 10, 2012 at 12:04 AM, Michael Richardson <mcr@sandelman.ca> wrote:
>>
>>
>> First question, why are there two radvd processes?
>>
>> 3343 root       964 S    /usr/sbin/radvd -C /var/etc/radvd.conf -m stderr_sys
>> 3345 root       964 S    /usr/sbin/radvd -C /var/etc/radvd.conf -m stderr_sys
>>
>> Is this just a thread issue?
>>
>> second question, none of my custom interfaces are in /var/etc/radvd.conf?
>>
>> Can I hack /etc/config/firewall directly rather than go through the UI?
>> I think so....?
>>
>> Could I attach blinking LEDs to VLANs?
>> (ps: whatever problems I had with ethernet mii between my cerowrt and
>> a cisco 200-26 switch in the summer, seems to have gone away)
>>
>> On an IPv6 interface which is not my uplink, I think that IPv6 gateway
>> should be blank.  That the router should advertise iself.
>>
>> I also think that the words "Send router soliciations" is wrong, that it
>> should say, "Send router advertisements".
>>
>> I had to put my custom interfaces into /etc/config/radvd.
>>
>> config interface
>>          option interface 'trusted'
>>          option AdvSendAdvert '1'
>>          option AdvRouterAddr '1'
>>          option AdvLinkMTU '1480'
>>          option ignore '0'
>>          option IgnoreIfMissing '1'
>>          option AdvSourceLLAddress '1'
>>          option AdvDefaultPreference 'medium'
>>          option AdvOtherConfigFlag '1'
>>
>> config prefix
>>          option interface 'trusted'
>>          list prefix ''
>>          option AdvOnLink '1'
>>          option AdvAutonomous '1'
>>          option AdvRouterAddr '0'
>>          option ignore '0'
>>
>> I don't see a place in the UI where this is edited, but I could be
>> missing it.
>>
>> --
>> ]       He who is tired of Weird Al is tired of life!           |  firewalls  [
>> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
>>     Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>>                         then sign the petition.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Cerowrt-users mailing list
>> Cerowrt-users@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-users
>
>
>
>

_______________________________________________
Cerowrt-users mailing list
Cerowrt-users@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-users


-- 
Dave Täht

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

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

[Dave Taht]

On Mon, Dec 10, 2012 at 9:41 AM, Dave Taht <dave.taht@gmail.com> wrote:
> I just noticed this thread went over to cerowrt-users and
> cerowrt-devel is the right place to discuss these issues.
>
>
> ---------- Forwarded message ----------
> From: Steven Barth
> Date: Mon, Dec 10, 2012 at 9:38 AM
> Subject: Re: [Cerowrt-users] IPv6 router advertisements on custom interfaces
> To: cerowrt-users <cerowrt-users@lists.bufferbloat.net>
>
>
> Fyi I've commited a new ipv6-support version to OpenWrt yesterday.
>
> This includes (partly untested) all features I want to see in there
> for OpenWrt except the integration of dnsmasq-dhcpv6 (which will
> follow later once the dynamic configuration features have been added
> to it) and the WebUI which is still on the ToDo.

Well, in my case, I'd like to also add ahcp server support to dnsmasq.
I've made a start at it but as I've not had time for the project for
over a year, (even though I figure it will take a week to do - it's a
really simple protocol with only 13 well defined TLVs), I have no idea
when I'll get round to it.

AHCP is very useful in edge cases where dhcp6-pd won't cut it, and the
existing daemon is kind of lonely, sitting out there, handling the
mesh'd interfaces in cerowrt, conflicting with multiple other things
in openwrt....

* distributes /128s out of a /64 pool (saves on ipv6 addresses)
* works on wireless mesh networks with spurious disconnectivity
* I wanted to find SOME alternative to the PD over ospf thing in homenet
* AHCP needs a second reference implementation to get back on standards track
* Getting a unified lease database and naming seems very useful - also
I'd wanted to
find a sane way to attach names to fe80:: style addresses so things
like traceroute6 worked better....

I at least got so far as pushing a patch set that "compiles" out to
github, but it's very incomplete - basically has some configuration
syntax defined and opens up the port. I have even more crappy patches
sitting in my tree, but they are embarrassingly bad.

I had wanted to implement it purely by referencing the rfc, but it
seems simpler to walk through the existing ahcpd code and apply it.

But lacking anyone but me that's interested in completing that work,
it's going to rot. I care a LOT about making ipv6 work, but would
rather finish coding up a replacement to pfifo_fast first.... Anybody
out there interested in implementing an interesting networking
protocol?


> So far the current IPv6-featureset is:
>
> * Support for native IPv6 with static configuration
> * Support for native IPv6 with DHCPv6-Prefix Delegation
> * Support for native IPv6 without PD via relaying or masquerading
> * Support for 6in4, 6to4 and 6rd
> * 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.

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)

And I wish anycast "just worked"...

> Help, documentation and configuration examples for yesterdays version

Heh. That's so... yesterday. I'm loving watching this stuff evolve.

> can be found here (there were a few changes for the new NPT-support):
>
> http://wiki.openwrt.org/doc/uci/network6

Looks very clean...
>
> Especially the NPT / NAT-related stuff has seen very little testing
> and of course only works with a Kernel >= 3.7 and ip6tables >= 1.4.17.

I intend to move cerowrt-next forward to 3.7 as soon as the patches stabilize.

>
>
> On 10.12.2012 08:56, Dave Taht wrote:
>>
>> Radvd is going away in the BB ("barrier breaker" - openwrt head)
>> version of openwrt, fairly soon. It deserves to die...
>>
>> There is going to be a merger of the DHCPv6/SLAAC and naming
>> functionalities in dnsmasq and the dynamicism of the new ipv6-support
>> package, which also includes a spanking new dhcpv6-pd client..
>>
>> Also planned is to (once the 3.7 kernel lands) make npt66 the default
>> (for most users). So in a couple weeks, all the underlying ipv6
>> infrastructure in openwrt and cerowrt is going to change.
>>
>> As to whether the 6in4 case is fully handled as of now in that system,
>> damned if I know. Same goes for 6to4... I put the ipv6-support package
>> into cerowrt 3.6.9-5, all forms of ipv6 are blocked at the lincs lab,
>> can't test it, right now.
>>
>> As for how to fix it in cerowrt 3.3.8, it was always problematic as
>> hell, and I'm glad the work is being re-architected in BB by two of
>> the most competent people I know, and I've signed cerowrt (and thus,
>> y'all) up to test it when it comes out. It would be great to recruit
>> more help, because *this time* we're going to get it right, come hell
>> or high water.
>>
>> I'm very pleased, in particular, with dnsmasq's naming support for
>> slaac. It "just works".
>>
>>
>> On Mon, Dec 10, 2012 at 12:04 AM, Michael Richardson <mcr@sandelman.ca> wrote:
>>>
>>>
>>> First question, why are there two radvd processes?
>>>
>>> 3343 root       964 S    /usr/sbin/radvd -C /var/etc/radvd.conf -m stderr_sys
>>> 3345 root       964 S    /usr/sbin/radvd -C /var/etc/radvd.conf -m stderr_sys
>>>
>>> Is this just a thread issue?
>>>
>>> second question, none of my custom interfaces are in /var/etc/radvd.conf?
>>>
>>> Can I hack /etc/config/firewall directly rather than go through the UI?
>>> I think so....?
>>>
>>> Could I attach blinking LEDs to VLANs?
>>> (ps: whatever problems I had with ethernet mii between my cerowrt and
>>> a cisco 200-26 switch in the summer, seems to have gone away)
>>>
>>> On an IPv6 interface which is not my uplink, I think that IPv6 gateway
>>> should be blank.  That the router should advertise iself.
>>>
>>> I also think that the words "Send router soliciations" is wrong, that it
>>> should say, "Send router advertisements".
>>>
>>> I had to put my custom interfaces into /etc/config/radvd.
>>>
>>> config interface
>>>          option interface 'trusted'
>>>          option AdvSendAdvert '1'
>>>          option AdvRouterAddr '1'
>>>          option AdvLinkMTU '1480'
>>>          option ignore '0'
>>>          option IgnoreIfMissing '1'
>>>          option AdvSourceLLAddress '1'
>>>          option AdvDefaultPreference 'medium'
>>>          option AdvOtherConfigFlag '1'
>>>
>>> config prefix
>>>          option interface 'trusted'
>>>          list prefix ''
>>>          option AdvOnLink '1'
>>>          option AdvAutonomous '1'
>>>          option AdvRouterAddr '0'
>>>          option ignore '0'
>>>
>>> I don't see a place in the UI where this is edited, but I could be
>>> missing it.
>>>
>>> --
>>> ]       He who is tired of Weird Al is tired of life!           |  firewalls  [
>>> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
>>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
>>>     Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>>>                         then sign the petition.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Cerowrt-users mailing list
>>> Cerowrt-users@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-users
>>
>>
>>
>>
>
> _______________________________________________
> Cerowrt-users mailing list
> Cerowrt-users@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-users
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html



-- 
Dave Täht

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

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

[Steven Barth]

On 10.12.2012 10:15, Dave Taht wrote:
>> * 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?

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.



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


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.


>
> 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: [Cerowrt-devel] Current state of ipv6 in openwrt barrier breaker

[Dave Taht]

On Mon, Dec 10, 2012 at 12:27 PM, Steven Barth <cyrus@openwrt.org> wrote:
> On 10.12.2012 10:15, Dave Taht wrote:
>>>
>>> * 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?

The current lack of anything greater than a /64 from places like free
and comcast...

is why I use ahcp for everything, myself. /128s. I also gain the
ability to move transparently from wired to wireless and back again
without losing my 20 ssh connections or the movie I'm playing. Not
that wires matter anymore.

Not being able to get anything greater than a single delegated /64 has
been quite maddening, to date.

I'm glad to know that free actually distributes a /60 and that comcast
has plans to do /60s or better. and that the principal barrier to
wider distribution of more prefixes is mostly due to flaws in the
dhcp-pd clients.

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

Well, I abhor bridging 2.4 and 5 ghz wireless together, and then there
is the ever more popular concept of a "guest" network...

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

Heh.

>
> * For ULA fd00::/48, the first /64 would be fd00::/64, the 2nd
> fd00:0:0:1::/64 etc.

It would be my hope to not standardize on fd00::whatever, but to
actually generate random ones. Doing vpns between your standardized
192.168.0.1 addresses is painful.... and with better naming, the pain
of having to remember these large numbers goes away (a bit.)

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

My understanding is that public prefixes can be kept until the wan comes up.
That said, I'd argue in favor of expiring them as fast as possible if
ula's already exist.

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

I think randomizing would help against attacks, yes.

Somewhat related, you could do something SLAAC-like on the inner
interface's /64. In prior versions of linux using a dhcp-like address
assignment strategy hashed badly.

(I note that I'm more of a fan of slaac than dhcpv6)

-- 
Dave Täht

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

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

[Steven Barth]

On 10.12.2012 12:40, Dave Taht wrote:
> Well, I abhor bridging 2.4 and 5 ghz wireless together, and then there
> is the ever more popular concept of a "guest" network...

Yes I'm talking about the default setup of OpenWrt here which does not 
have a guest-interface etc. though I agree in general we will all have 
the problem.

Though we might not want to do bridging by default we might want to 
think about a solution using relaying (NDP-Proxying etc.) if the 
/64-problem becomes critical.

>
>> 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.
>
> Heh.
>
>>
>> * For ULA fd00::/48, the first /64 would be fd00::/64, the 2nd
>> fd00:0:0:1::/64 etc.
>
> It would be my hope to not standardize on fd00::whatever, but to
> actually generate random ones. Doing vpns between your standardized
> 192.168.0.1 addresses is painful.... and with better naming, the pain
> of having to remember these large numbers goes away (a bit.)
Yes we do generate random ones. The first time any interfaces comes up a 
random ula address is generated. I just used fd00:: in this example 
because its the shortest one to write to demonstrate the splitting of 
prefixes.


>
>> * 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).
>> * 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).
>
> My understanding is that public prefixes can be kept until the wan comes up.
> That said, I'd argue in favor of expiring them as fast as possible if
> ula's already exist.
Sorry I don't get what you mean, maybe a misunderstanding. What I was 
talking about is when you have an ULA or a public prefix, lets use 
2001:DB80::/48 here than e.g. your ethernet-lan gets 2001:DB80:0:1/64, 
wifi gets 2001:DB80:0:2/64 etc.
If you then do an ifdown lan and ifup lan, the ethernet interface still 
still get 2001:DB80:0:1/64 and not 2001:DB80:0:3/64 etc. This apply also 
when other interfaces were brought up or down in between, except when 
the interface that provided the prefix (e.g. wan) goes down. In this 
case all current assignments an the prefix itself will be forgotten.

In the NPT-scenario these rules will apply to the ULA-addresses, so once 
an interface got a part of the ULA-prefix, it will keep that prefix even 
if it goes down and up again.



> I think randomizing would help against attacks, yes.
>
> Somewhat related, you could do something SLAAC-like on the inner
> interface's /64. In prior versions of linux using a dhcp-like address
> assignment strategy hashed badly.
>
> (I note that I'm more of a fan of slaac than dhcpv6)

Re: [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

Re: [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@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

Re: [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

Re: [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@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

Re: [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

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

[Steven Barth]

Hi Ole, Dave,

> the worst you can expect is a /64 on the link-net and no PD. I suggest you don't support that case.
The problem is that (some) people are expecting to be able to just plug 
other routers behind their main uplink router for whatever reasons (e.g. 
additional WiFi-network etc.) like they have with IPv4 or e.g. make a 
router just connect to a non-WDS WiFi in client mode and extend their 
network.

As the home router shouldn't do PD to further distribute the ISP-prefix 
it is hard to support this with IPv6 except with detecting the case and 
doing NDP-Proxying then as bridging might not always be possible or 
desired in this case.

And supporting all of this above would have the side-effect that such 
ISP without PD would be supported as well so I'm not really sure.

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

[Ole Trøan]

Steven,

>> the worst you can expect is a /64 on the link-net and no PD. I suggest you don't support that case.
> The problem is that (some) people are expecting to be able to just plug other routers behind their main uplink router for whatever reasons (e.g. additional WiFi-network etc.) like they have with IPv4 or e.g. make a router just connect to a non-WDS WiFi in client mode and extend their network.

that only works in IPv4 if you have a good tail wind and your fingers crossed.

> As the home router shouldn't do PD to further distribute the ISP-prefix it is hard to support this with IPv6 except with detecting the case and doing NDP-Proxying then as bridging might not always be possible or desired in this case.

you could use hierarchical PD, just that it doesn't work well with:
 - networks with loops
 - multi-homed networks

and it is quite wasteful with regards to subnet space.

> And supporting all of this above would have the side-effect that such ISP without PD would be supported as well so I'm not really sure.

ND proxy fails in any topology with a loop.

we do have an implementation on github that implements
http://datatracker.ietf.org/doc/draft-arkko-homenet-prefix-assignment/
that supports prefix assignment with an arbitrary topology in the network. why not use that?

cheers,
Ole

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

[Steven Barth]

Hi Ole,

> you could use hierarchical PD, just that it doesn't work well with:
>   - networks with loops
>   - multi-homed networks
>
> and it is quite wasteful with regards to subnet space.
> ND proxy fails in any topology with a loop.
Yes but I expect loops not to happen in practice or people that build 
loops to know how to take care of them.

Nevertheless taking into account the issues I mention below hierarchical 
PD still sounds to me like a better thing in SOHO environments regarding 
interoperability with other devices in that environment however as I 
still need the NDP-Proxying fallback in case the upstream router (be it 
a SOHO-router) doesn't support further distribution of the ISP-Prefix.


> we do have an implementation on github that implements
> http://datatracker.ietf.org/doc/draft-arkko-homenet-prefix-assignment/
> that supports prefix assignment with an arbitrary topology in the network. why not use that?
 From a technical point of view I like your approach and using OSPF.

However the stuff is >1 MB in size including all of its dependencies and 
includes some strange dependencies like libreadline?, some otherwise 
unrelated Lua extensions and so on.

Sorry, that is not an option for the majority of OpenWrt users, just for 
having a more versatile Prefix Delegation feature which will only be (?) 
interoperable with a small amount of routers.

We could integrate it for more powerful routers though (and I wouldn't 
object) but I don't see any hope to get it to mainstream before we can 
get it down to a few 100 KB (including dependencies).
Also at least I don't have any time or resources to take care of either 
of that in the near future.

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

[Dave Taht]

On Wed, Dec 12, 2012 at 10:47 AM, Steven Barth <cyrus@openwrt.org> wrote:
> Hi Ole,
>
>> you could use hierarchical PD, just that it doesn't work well with:
>>   - networks with loops
>>   - multi-homed networks
>>
>> and it is quite wasteful with regards to subnet space.
>> ND proxy fails in any topology with a loop.
>
> Yes but I expect loops not to happen in practice or people that build loops
> to know how to take care of them.

I expect loops to happen a lot in practice, and people to not be able
to take care of them.

Babel, however, is loop free.

http://www.pps.univ-paris-diderot.fr/~jch/software/babel/

>
> Nevertheless taking into account the issues I mention below hierarchical PD
> still sounds to me like a better thing in SOHO environments regarding
> interoperability with other devices in that environment however as I still
> need the NDP-Proxying fallback in case the upstream router (be it a
> SOHO-router) doesn't support further distribution of the ISP-Prefix.
>
>
>
>> we do have an implementation on github that implements
>> http://datatracker.ietf.org/doc/draft-arkko-homenet-prefix-assignment/
>> that supports prefix assignment with an arbitrary topology in the network.
>> why not use that?

I would like to implement portions of that algorithm in something far
more lightweight than OSPF. Extending AHCP is my current first choice.

> From a technical point of view I like your approach and using OSPF.
>
> However the stuff is >1 MB in size including all of its dependencies and
> includes some strange dependencies like libreadline?, some otherwise
> unrelated Lua extensions and so on.
>
> Sorry, that is not an option for the majority of OpenWrt users, just for
> having a more versatile Prefix Delegation feature which will only be (?)
> interoperable with a small amount of routers.
>
> We could integrate it for more powerful routers though (and I wouldn't
> object) but I don't see any hope to get it to mainstream before we can get
> it down to a few 100 KB (including dependencies).
> Also at least I don't have any time or resources to take care of either of
> that in the near future.

Neither do I.

>



-- 
Dave Täht

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

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

[Michael Richardson]

>>>>> "Dave" == Dave Taht <dave.taht@gmail.com> writes:
    Dave> I finally figured out something today. I've been trying to build a
    Dave> network that "just worked" in places where the internet doesn't exist
    Dave> (yet) - which is roughly 2/3s of the users on the planet. To be able
    Dave> to connect two arbitrary machines together with zero configuration. To
    Dave> get something that would let Jose's machine shop in one part
    Dave> of town 
    Dave> connect to Jorge's printer down the street, because that's the only
    Dave> printer for 100 kilometers.

I have the goal.

I am not a political fan of ULAs, I would prefer a space of
Non-Connected Networks addressing, including perhaps Tony Hain's GeoIP.
(http://datatracker.ietf.org/doc/draft-hain-ipv6-geo-addr/ ), but I can
live with ULA.

Given ULA, the problem of connecting Jose and Jorge, is not a job for
DHCP or PD, but rather of a routing problem.  You can apply babel,
OLSLR, OSPC AHCP, etc. to the problem.

I see no reason to ever want NPT66.

    Dave> The other day I sat, in disbelief, in a a room with several students,
    Dave> when they all had git trees of the project, and the internet
    Dave> was down .
    Dave> They started passing around a usb stick, and didn't know about the
    Dave> whatever.local trick. I showed them that they could, indeed,
    Dave> just pass 
    Dave> the objects around locally, with a

Yup, it's true.
People under the age of 30 have never been on the Internet.  They grew
up with NAT, and assume that *their* computer is just a client.

    Dave> I love it when I hear "Host vendors should fix their boxes". I would
    Dave> prefer that people making the architectural decision to assign
    Dave> work to 
    Dave> someone else, either find a way to pay for it, or do the work
    Dave> on those 
    Dave> hosts to enable the vision.

It's gonna happen this time.
Seriously.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

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

[Török Edwin]

On 12/11/2012 11:31 PM, Ole Trøan wrote:
> 
> 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).

Don't forget about virtualization.
Correct me if I'm wrong, but even if the router gets more than a /64 a host would only request a /64 automatically, which is not
enough to automatically route between the virtual network interfaces (each would want a /64 again).
Unless the virtual network runs in bridged mode so that the VMs can get their IPv6 address directly from the router, or you use
AHCP to assign addresses.

And in general there are even more problems, for example in a datacenter you might need to proxy NDP requests otherwise the VMs get no IPv6 traffic
(either manually for each host, or with a userspace daemon). So you'd probably need both ndppd and ahcpd to have things working.

It'd certainly be easier if one could use less than a /64, at least for virtual networks, and have automatic IPv6 address assignment and
automatic ndp proxying working without the need for any user-space daemons.

--Edwin

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

[Steven Barth]

Hi Ole,

your feedback is appreciated, thanks.
Just to clarify a few things here because I think there might be
misunderstandings.


> or create state...
> NPT should not be on by default though
I agree and it won't be a default in plain OpenWrt.


> 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).
In the current implementation /dev/urandom is used to generate the /48
on the first boot of the device. fd00:: was just an example here.
I don't see any particular advantage in using the sha / ntp etc. thing
especially since there might not be a working RTC.


> shouldn't all interface have a /64?
I won't restrict users doing anything else but /64 is the default, yes.


> 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... ;-)
Yes the problem is that source address selection seems to be a trouble
on clients. I just had users / tester complain yesterday about devices
using ULA instead of the 200X: source addresses breaking connectivity
when both are announced so now I had to implement a hack that sets
the preferred time of the ULA to 0 when there are prefixes with global
reachability.


Similarly I see NPT only as a way to work around client issues
- especially when having multi-homing / redundant uplinks -
and not as a default way of doing things.


Cheers,

Steven

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

[Ole Trøan]

Steven,

> your feedback is appreciated, thanks.
> Just to clarify a few things here because I think there might be
> misunderstandings.

yes, seems like I did (misunderstand that is. ;-))


>> or create state...
>> NPT should not be on by default though
> I agree and it won't be a default in plain OpenWrt.
> 
> 
>> 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).
> In the current implementation /dev/urandom is used to generate the /48
> on the first boot of the device. fd00:: was just an example here.
> I don't see any particular advantage in using the sha / ntp etc. thing
> especially since there might not be a working RTC.

cool. if you don't want to keep additional state, you could base it on a MAC address in the box, but random is fine too,
as long as it is persistent (across reboots).

>> shouldn't all interface have a /64?
> I won't restrict users doing anything else but /64 is the default, yes.

ack.

>> 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... ;-)
> Yes the problem is that source address selection seems to be a trouble
> on clients. I just had users / tester complain yesterday about devices
> using ULA instead of the 200X: source addresses breaking connectivity
> when both are announced so now I had to implement a hack that sets
> the preferred time of the ULA to 0 when there are prefixes with global
> reachability.

we need to get the hosts fixed for this.
right now, given the state of affairs my recommendation would be not not enable ULAs by default.

> Similarly I see NPT only as a way to work around client issues
> - especially when having multi-homing / redundant uplinks -
> and not as a default way of doing things.

I'd really like us to avoid that. it is going to be so hard to get NPT out of the network again.
it also forces applications to continue with STUN/TURN and all that stuff to discover global addresses
that can be used for referrals. please let us keep the end to end properties of IPv6 intact.

cheers,
Ole

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

[Steven Barth]

Hi Ole,

> we need to get the hosts fixed for this.
ideally yes, but judging from experience I don't think that will happen 
(anytime soon).

> right now, given the state of affairs my recommendation would be not not enable ULAs by default.
Hmm I'd agree however I don't like to not have any (non-link-local) 
addresses when there is no uplink. So I think I will keep the current 
workaround (announcing ULA with preferred time 0 as long as there are 
public prefixes) and see how that works.


> I'd really like us to avoid that. it is going to be so hard to get NPT out of the network again.
> it also forces applications to continue with STUN/TURN and all that stuff to discover global addresses
> that can be used for referrals. please let us keep the end to end properties of IPv6 intact.

Yes, I wholeheartedly agree with you from a technical and ideological 
standpoint. However I don't think it would be wise - at least as an 
OpenWrt developer - to force any of this ideology onto users. IPv6 NAT 
made it into the Linux kernel so I guess there are some legitimate 
use-cases, so at least I don't want to be the guy assuming I know better 
then the people who implemented, requested and accepted these features.

I'd rather have it implemented and more or less supported in the most 
sane way possible then people hacking it in on their own.

However as I said I feel the need to have reasonable defaults and make 
it easy (easier?) to use the standards-compliant way than to use NAT. 
Thats where I can be reasoned with ;)

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

[Ole Trøan]

Steven,

>> I'd really like us to avoid that. it is going to be so hard to get NPT out of the network again.
>> it also forces applications to continue with STUN/TURN and all that stuff to discover global addresses
>> that can be used for referrals. please let us keep the end to end properties of IPv6 intact.
> 
> Yes, I wholeheartedly agree with you from a technical and ideological standpoint. However I don't think it would be wise - at least as an OpenWrt developer - to force any of this ideology onto users. IPv6 NAT made it into the Linux kernel so I guess there are some legitimate use-cases, so at least I don't want to be the guy assuming I know better then the people who implemented, requested and accepted these features.
> 
> I'd rather have it implemented and more or less supported in the most sane way possible then people hacking it in on their own.
> 
> However as I said I feel the need to have reasonable defaults and make it easy (easier?) to use the standards-compliant way than to use NAT. Thats where I can be reasoned with ;)

oh absolutely. there is a need for IPv6 NAT. particularly around multihoming to non-congruent networks, even in the home.
(this would of course be a lot prettier with ILNP, IPv6 NATs, better looking cousin.)

I'm only arguing against having IPv6 NAT as the default solution.

cheers,
Ole