Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: cerowrt-devel@lists.bufferbloat.net, Steven Barth <cyrus@openwrt.org>
Subject: Re: [Cerowrt-devel] Current state of ipv6 in openwrt barrier breaker
Date: Mon, 10 Dec 2012 10:15:41 +0100	[thread overview]
Message-ID: <CAA93jw7_+kjyuaRteNDfagzy-vcvghAyPbzgALVMqPQr+_SdkA@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw55X1e90yrXKofRsS9BbN_aVyU==vAuASwgH0sceupA1w@mail.gmail.com>

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

  reply	other threads:[~2012-12-10  9:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-10  8:41 Dave Taht
2012-12-10  9:15 ` Dave Taht [this message]
2012-12-10 11:27   ` Steven Barth
2012-12-10 11:40     ` Dave Taht
2012-12-10 11:53       ` Steven Barth
2012-12-11 19:56 Ole Trøan
2012-12-11 20:25 ` Dave Taht
2012-12-11 21:31   ` Ole Trøan
2012-12-12  8:19     ` Dave Taht
2012-12-12  9:08       ` Ole Trøan
2012-12-12  9:19         ` Steven Barth
2012-12-12  9:28           ` Ole Trøan
2012-12-12  9:47             ` Steven Barth
2012-12-12 10:11               ` Dave Taht
2012-12-12 18:56       ` Michael Richardson
2012-12-12  9:05     ` Török Edwin
2012-12-11 20:46 ` Steven Barth
2012-12-11 21:02   ` Ole Trøan
2012-12-12  8:23     ` Steven Barth
2012-12-12  8:43       ` Ole Trøan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw7_+kjyuaRteNDfagzy-vcvghAyPbzgALVMqPQr+_SdkA@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=cyrus@openwrt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox