Re: [Cerowrt-devel] IPv6 address assignment and naming

Re: [Cerowrt-devel] IPv6 address assignment and naming

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 5234 bytes --]

Dear Juergen:

Your note kind of opens a can of worms.

On Fri, Aug 16, 2013 at 11:13 AM, Juergen Botz <jurgen@botz.org> wrote:

> On 08/16/2013 03:06 PM, Dave Taht wrote:
> > You need to statically assign addresses on the AHCP server box.
>
> Ok, fair enough... but then why did it work without statically
> assigned addresses in 3.7.x?
>
> :j
>
>
The desired state of integration with the openwrt developers was not
achieved? :/

Since January there has been a huge amount of work into making a better
state machine for openwrt, called netifd, to make it more possible to have
many more complex behaviors when it came to dealing with network
interfaces.

http://wiki.openwrt.org/doc/techref/netifd

I'm very happy with how well that's working out, but it was a scary switch
at the time!!

But this obsoleted the ahcpd integration I'd had before, and the "ahcpd"
proto has not made it into the mix of supported protocols in netifd. A
script that interfaces with the netifd concepts doesn't exist. AHCPd itself
could use a bit of work in this area, too. It would be nice in particular
if dyamic ipv6 assignment could be made to work, that would lead to a
natural syntax stanza in /etc/networks of something like:

config interface 'gw01'
        option proto 'ahcp'
        option ip6assign '128'

config interface 'gw11'
        option proto 'static'
        option ip6assign '128'

My thought originally was to just fold ahcpd into dnsmasq, but I spent a
grand total of a day on it and realized that it was harder than I thought.
Second thought was to make ahcpd listen on the netifd message bus, that too
was harder than I thought. Neither is "hard", actually, but it needs some
focused time by someone, preferably not me. Juliusz went to ietf hoping to
convince someone that dhcpv6 and SLAAC are not the answer to all things
(which I agree with), but there was insufficient time to present on the
topic.

AHCPD is a zillion times easier to use than dhcpv6, particularly in meshy
environments, it's also more effective.

While most of the ipv6 stuff in openwrt is going increasingly well, AND we
just got working multi-prefix routing fixed in the linux kernel (not sure
if the IPV6_subtrees spatches are committed or backported yet), there are
still integration hassles with ipv6 going on. (I expect integration hassles
for years, actually - dealing with the pure dynamic assignments the isps
are demanding is nearly impossible)

In particular the ongoing work on dnsmasq is now out of sync with the
6relayd work and vice versa. Back in january, when we obsoleted radvd, it
looked like dnsmasq was going to take over ipv6 ra, dhcpv6, and naming
duties, but 6relayd then made serious progress and does most of that itself
and is (at least presently) more tightly integrated with openwrt than
dnsmasq is.

On the one side, I strongly support tight naming integration with ipv6
address assignment, which is why I like the dnsmasq integration (which is
what cerowrt uses). Naming is a real pita with ipv6. (The ipv6 folk have
spent a lot of time NOT thinking about it.). I would like ahcpd to also
support some level of naming, too.

On the other, I like several things that 6relayd does that dnsmasq can't
(and probably shouldn't)

On the gripping hand, the elephant in the room is decent multicast dns and
service discovery over ipv6, and mdnsext over routed networks in general.
http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-02 - avaha is
huge, and buggy, and the mac guys have mdns figured out pretty good, so it
would be best (IMHO) to follow their lead....

I really don't know what to do about all that!

I tried to get the core developers of these tools to drink some beer and
bang their heads together at that ietf, don't know if that happened. cc-ing
a couple here. Cerowrt exists to test this sort of stuff. At the moment,
though, figuring out how to backport the ADSL htb fixes from Linux 3.11
into 3.10 is on my mind higher... and doing one more teeny fix to codel, as
well.

Seeing ipv6_subtrees work was very exciting, it's going to make things like
mptcp and vpns and multiple exit gateways work much better on ipv6, enable
a whole new generation of usefulness in ipv6 routing protocols, etc -
eventually.

http://patchwork.ozlabs.org/patch/265288/

http://tools.ietf.org/html/draft-boutier-homenet-source-specific-routing-00

The overall "fight" vs a vs ahcpd is that the path homenet is on is to drag
in an entire routing protocol (ospf) just to do ipv6 prefix assignment, and
methods for carrying other useful configuration information around have not
been well defined.

So this was juliusz's argument, unpresented:

http://tools.ietf.org/html/draft-chroboczek-homenet-configuration-separate-00

I have always thought ahcpd was a good start, but far from complete, and
dhcpv6 hopelessly overengineered and worse, inappropriate for the wireless
age. I also have no idea what to do about that!

Welcome to future. You can help shape it, if you choose.

/me pulls a pillow over his head

-- 
Dave Täht

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

[-- Attachment #2: Type: text/html, Size: 6955 bytes --]

Re: [Cerowrt-devel] IPv6 address assignment and naming

[Teco Boot]

The IPv6 subtrees in on its way :-). After 3.11 we can ask for backports.

I think we need more beers. One reason to go to Vancouver. We should ask the mptcp folks to join. There howto is far to complex, their own words on sadr: "Doing the above each time by hand is very cumbersome". Hey, this was the simple case with two interfaces, no dynamics !!

Teco

PS1: MPTCP in mesh is very useful: make before break and load distribution. Can only work with autoconfig.
PS2: Better autoconfig approach: BRDP. See draft-boot-homenet-brdp for overview. IPv6-only (autoconf v4 over v6 is doable). Didn't implement. I have no v6 access. Nor I am coder. It is similar to Juliusz his approach, but it runs on top of ND RA and informs hosts. Didn't see straightforward proposals for that, other than using another set of DHCP options.


Op 16 aug. 2013, om 21:13 heeft Dave Taht <dave.taht@gmail.com> het volgende geschreven:

> 
> Dear Juergen:
> 
> Your note kind of opens a can of worms.
> 
> On Fri, Aug 16, 2013 at 11:13 AM, Juergen Botz <jurgen@botz.org> wrote:
> On 08/16/2013 03:06 PM, Dave Taht wrote:
> > You need to statically assign addresses on the AHCP server box.
> 
> Ok, fair enough... but then why did it work without statically
> assigned addresses in 3.7.x?
> 
> :j
> 
> 
> The desired state of integration with the openwrt developers was not achieved? :/
> 
> Since January there has been a huge amount of work into making a better state machine for openwrt, called netifd, to make it more possible to have many more complex behaviors when it came to dealing with network interfaces. 
> 
> http://wiki.openwrt.org/doc/techref/netifd
> 
> I'm very happy with how well that's working out, but it was a scary switch at the time!!
> 
> But this obsoleted the ahcpd integration I'd had before, and the "ahcpd" proto has not made it into the mix of supported protocols in netifd. A script that interfaces with the netifd concepts doesn't exist. AHCPd itself could use a bit of work in this area, too. It would be nice in particular if dyamic ipv6 assignment could be made to work, that would lead to a natural syntax stanza in /etc/networks of something like:
> 
> config interface 'gw01'                          
>         option proto 'ahcp'                      
>         option ip6assign '128'
>                                                   
> config interface 'gw11'                           
>         option proto 'static'                     
>         option ip6assign '128'
> 
> My thought originally was to just fold ahcpd into dnsmasq, but I spent a grand total of a day on it and realized that it was harder than I thought. Second thought was to make ahcpd listen on the netifd message bus, that too was harder than I thought. Neither is "hard", actually, but it needs some focused time by someone, preferably not me. Juliusz went to ietf hoping to convince someone that dhcpv6 and SLAAC are not the answer to all things (which I agree with), but there was insufficient time to present on the topic. 
> 
> AHCPD is a zillion times easier to use than dhcpv6, particularly in meshy environments, it's also more effective.
> 
> While most of the ipv6 stuff in openwrt is going increasingly well, AND we just got working multi-prefix routing fixed in the linux kernel (not sure if the IPV6_subtrees spatches are committed or backported yet), there are still integration hassles with ipv6 going on. (I expect integration hassles for years, actually - dealing with the pure dynamic assignments the isps are demanding is nearly impossible)
> 
> In particular the ongoing work on dnsmasq is now out of sync with the 6relayd work and vice versa. Back in january, when we obsoleted radvd, it looked like dnsmasq was going to take over ipv6 ra, dhcpv6, and naming duties, but 6relayd then made serious progress and does most of that itself and is (at least presently) more tightly integrated with openwrt than dnsmasq is. 
> 
> On the one side, I strongly support tight naming integration with ipv6 address assignment, which is why I like the dnsmasq integration (which is what cerowrt uses). Naming is a real pita with ipv6. (The ipv6 folk have spent a lot of time NOT thinking about it.). I would like ahcpd to also support some level of naming, too.
> 
> On the other, I like several things that 6relayd does that dnsmasq can't (and probably shouldn't)
> 
> On the gripping hand, the elephant in the room is decent multicast dns and service discovery over ipv6, and mdnsext over routed networks in general. http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-02 - avaha is huge, and buggy, and the mac guys have mdns figured out pretty good, so it would be best (IMHO) to follow their lead....
> 
> I really don't know what to do about all that!
> 
> I tried to get the core developers of these tools to drink some beer and bang their heads together at that ietf, don't know if that happened. cc-ing a couple here. Cerowrt exists to test this sort of stuff. At the moment, though, figuring out how to backport the ADSL htb fixes from Linux 3.11 into 3.10 is on my mind higher... and doing one more teeny fix to codel, as well.
> 
> Seeing ipv6_subtrees work was very exciting, it's going to make things like mptcp and vpns and multiple exit gateways work much better on ipv6, enable a whole new generation of usefulness in ipv6 routing protocols, etc - eventually.
> 
> http://patchwork.ozlabs.org/patch/265288/
> 
> http://tools.ietf.org/html/draft-boutier-homenet-source-specific-routing-00
> 
> The overall "fight" vs a vs ahcpd is that the path homenet is on is to drag in an entire routing protocol (ospf) just to do ipv6 prefix assignment, and methods for carrying other useful configuration information around have not been well defined.
> 
> So this was juliusz's argument, unpresented:
> 
> http://tools.ietf.org/html/draft-chroboczek-homenet-configuration-separate-00
> 
> I have always thought ahcpd was a good start, but far from complete, and dhcpv6 hopelessly overengineered and worse, inappropriate for the wireless age. I also have no idea what to do about that! 
> 
> Welcome to future. You can help shape it, if you choose.
> 
> /me pulls a pillow over his head
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] IPv6 address assignment and naming

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On Fri, Aug 16, 2013 at 2:21 PM, Teco Boot <teco@inf-net.nl> wrote:

> The IPv6 subtrees in on its way :-). After 3.11 we can ask for backports.
>

I folded it into cerowrt 3.10.7-1 just now. No noise on the patch. I was
scared by some of the backtraces you posted, so I'd like to keep the
testing simple for a while... and...

I still have the ADSL htb fixes to fold back in from 3.11 to 3.10, to
massively update cisco's pie implementation, and to make one more tweak to
codel, before I do anything other than compile testing, personally.

Probably will be a couple days.

I have no idea the state of the babel branch on this stuff. My own use case
is a system with multiple 6rd, 6in4, 6to4 tunnels in play....

One of my concerns was that: is there an easy way to detect at runtime via
netlink if subtrees was working correctly or not?


-- 
Dave Täht

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

[-- Attachment #2: Type: text/html, Size: 1407 bytes --]

Re: [Cerowrt-devel] IPv6 address assignment and naming

[Teco Boot]

The backtraces were not caused by the ip6_subtrees patch. It is Ubuntu that upgraded me to 3.8.0.28, with some free bugs. I went back to 3.8.0.27. No problems since then.

Teco

Op 16 aug. 2013, om 23:35 heeft Dave Taht <dave.taht@gmail.com> het volgende geschreven:

> 
> 
> 
> On Fri, Aug 16, 2013 at 2:21 PM, Teco Boot <teco@inf-net.nl> wrote:
> The IPv6 subtrees in on its way :-). After 3.11 we can ask for backports.
> 
> I folded it into cerowrt 3.10.7-1 just now. No noise on the patch. I was scared by some of the backtraces you posted, so I'd like to keep the testing simple for a while... and... 
> 
> I still have the ADSL htb fixes to fold back in from 3.11 to 3.10, to massively update cisco's pie implementation, and to make one more tweak to codel, before I do anything other than compile testing, personally. 
> 
> Probably will be a couple days.
> 
> I have no idea the state of the babel branch on this stuff. My own use case is a system with multiple 6rd, 6in4, 6to4 tunnels in play.... 
> 
> One of my concerns was that: is there an easy way to detect at runtime via netlink if subtrees was working correctly or not?
> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] IPv6 address assignment and naming

[Hannes Frederic Sowa]

Hello all!

On Fri, Aug 16, 2013 at 11:21:03PM +0200, Teco Boot wrote:
> The IPv6 subtrees in on its way :-). After 3.11 we can ask for backports.

It is already in davem's stable queue and should be integrated in the next stable
kernels. If openwrt picks them up, it should show up there, too.

> > While most of the ipv6 stuff in openwrt is going increasingly well, AND we just got working multi-prefix routing fixed in the linux kernel (not sure if the IPV6_subtrees spatches are committed or backported yet), there are still integration hassles with ipv6 going on. (I expect integration hassles for years, actually - dealing with the pure dynamic assignments the isps are demanding is nearly impossible)

May I ask if those fixes for multi-prefix routing made it upstream? Btw. I
am more then willing to have a look at ipv6 kernel problems and maybe
fix them. ;)

Thanks a lot,

  Hannes

Re: [Cerowrt-devel] IPv6 address assignment and naming

[Steven Barth]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

Well lets see how this could help us. I presume this makes ipv6 source routing usable without policy rules and distinct tables? Sorry didnt have time to look into it in more Detail.

As 3.10 has become LTS it would probably be a good candidate for a release.

I hope to start a new Iteration for ipv6 in openwrt in the near future. Lets see if we can get anything out of the meetings in Berlin. If anyone wants to contribute anything to owrt please let me know so we can coordinate all efforts.

Cheers,

Steven



Hannes Frederic Sowa <hannes@stressinduktion.org> schrieb:
>Hello all!
>
>On Fri, Aug 16, 2013 at 11:21:03PM +0200, Teco Boot wrote:
>> The IPv6 subtrees in on its way :-). After 3.11 we can ask for
>backports.
>
>It is already in davem's stable queue and should be integrated in the
>next stable
>kernels. If openwrt picks them up, it should show up there, too.
>
>> > While most of the ipv6 stuff in openwrt is going increasingly well,
>AND we just got working multi-prefix routing fixed in the linux kernel
>(not sure if the IPV6_subtrees spatches are committed or backported
>yet), there are still integration hassles with ipv6 going on. (I expect
>integration hassles for years, actually - dealing with the pure dynamic
>assignments the isps are demanding is nearly impossible)
>
>May I ask if those fixes for multi-prefix routing made it upstream?
>Btw. I
>am more then willing to have a look at ipv6 kernel problems and maybe
>fix them. ;)
>
>Thanks a lot,
>
>  Hannes

[-- Attachment #2: Type: text/html, Size: 2216 bytes --]

Re: [Cerowrt-devel] IPv6 address assignment and naming

[Teco Boot]

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

Yes, source address dependent routing in main table. Just use from <prefix>. Typically on default route. 

Add also normal default for source address selection. 

Teco

Op 17 aug. 2013 om 16:53 heeft Steven Barth <cyrus@openwrt.org> het volgende geschreven:

> Well lets see how this could help us. I presume this makes ipv6 source routing usable without policy rules and distinct tables? Sorry didnt have time to look into it in more Detail.
> 
> As 3.10 has become LTS it would probably be a good candidate for a release.
> 
> I hope to start a new Iteration for ipv6 in openwrt in the near future. Lets see if we can get anything out of the meetings in Berlin. If anyone wants to contribute anything to owrt please let me know so we can coordinate all efforts.
> 
> Cheers,
> 
> Steven
> 
> 
> 
> Hannes Frederic Sowa <hannes@stressinduktion.org> schrieb:
>> 
>> Hello all!
>> 
>> On Fri, Aug 16, 2013 at 11:21:03PM +0200, Teco Boot wrote:
>>> The IPv6 subtrees in on its way :-). After 3.11 we can ask for backports.
>> 
>> It is already in davem's stable queue and should be integrated in the next stable
>> kernels. If openwrt picks them up, it should show up there, too.
>> 
>>>> While most of the ipv6 stuff in openwrt is going increasingly well, AND we just got working multi-prefix routing fixed in the linux kernel (not sure if the IPV6_subtrees spatches are committed or backported yet), there are still integration hassles with ipv6 going on. (I exp
>>>>  ect
>>>> integration hassles for years, actually - dealing with the pure dynamic assignments the isps are demanding is nearly impossible)
>> May I ask if those fixes for multi-prefix routing made it upstream? Btw. I
>> am more then willing to have a look at ipv6 kernel problems and maybe
>> fix them. ;)
>> 
>> Thanks a lot,
>> 
>> Hannes

[-- Attachment #2: Type: text/html, Size: 2758 bytes --]