[Cerowrt-devel] Extensive IPv6 support can be dropped from cerowrt rc8 [#317]
dave.taht at gmail.com
Tue Dec 6 22:58:47 EST 2011
On Tue, Dec 6, 2011 at 8:33 PM, <david at lang.hm> wrote:
> Again, what are you trying to address? there are a lot of issues with IPv6,
> do you want to be working to solve those, or do you want to focus on
In the early days...
We found that ECN and TOS (diffserv) were not being
handled correctly in the linux stack under ipv6.
There were routing and encapsulation problems, as well.
All that stuff is fixed upstream now. I'm happy.
Nor, applications that wanted to use prioritization understood
that they needed to use IPV6_TCLASS to do that on IPv6
sockets, not IP_TOS. That's fixed now also in openssh and
dropbear, babel, and AHCP. And all that's upstream, too.
I'm happier. :) Hopefully other application writers will see
how easy it is to do (see bug
) - and gradually incorporate one liner fixes like that
into their products.
I think, but am not sure, a fix is in the works for making IPv6
mapped sockets do more of the right thing in these cases
This reminds me, IPv6 + diffserv is *not* being handled
at all STILL in the wireless component of the stack.
If you do voip over IPv6, as an example it's being
tossed into the hardware BE queue, not the VO queue.
I really need to get around to pushing that patch up.
To fork off into the diffserv problem a bit harder:
It is certainly silly to have the one end-to-end technology that really
benefits from 'EF' being set AND from running over IPv6 to be so
The easy part of that patch is merely getting the IPv6 + diffserv part to work,
the hard part is getting something more comprehensive in place
to do diffserv at leat 95% *right*, as opposed to the half-assed
sorta-tos-like implementation we have now.
I'd like to see someone take implementing a rollup of the
diffserv standard into the linux kernel as a project, as
well as finding a clean way to map it into 802.1q and 802.11e.
For example, the less than complete implementation
on wireless doesn't do the right thing with the 'IMM' bit, tossing interactive
packets (like, for example, ssh) also into the BE hardware queue
rather than someplace saner like VI.
I have some patches towards implementing diffserv sanely, based on the
drafts here and here -
(actually, I tossed the iptables method entirely and decided tc was
closer to the right thing)
but have not got around to finishing them. I'm not the right guy to do so,
actually, as it would require buy-in from netdev, the netfilter guys, and
(my diffserv attempt was basically triggered by my observation of the VO queue
not being used for ipv6, and grew into a time-sucking rathole)
Anyway, so long as whatever approach taken towards diffserv did
take ipv6 into account, this component of the project can
be handled on 'normal', not embedded systems, done well,
and done by someone(s) else.
> if openWRT supports IPv6 you should not remove it, but don't go out of your
> way to provide anything more than openwrt includes unless it directly
> supports your goal.
In my opinion, getting IPv6 to work well requires a level of investment
and involvement well beyond that of the last major project that took it
on (japan's wide project), government and industry-wide funding,
and a focus on the problems induced by actual day to day usage.
While all the above accomplishments thus far *help* put
ipv6 on a more level playing field with ipv4, and indicate
the value of 'a' project that tries hard to treat the two protocols
equally, this cerowrt project does not necessarily need to
continue stressing ipv6 at all on the non-existent budget
We can fix many bufferbloat-induced problems and get ipv6
working better (now that the above fixes are in place),
for 'free'. Continued testing of course, would be helpful
and no doubt continually improve ipv6's behavior,
but it's a lot of additional effort that can be better expended
on stuff that is more crucial to the main goals.
US Tel: 1-239-829-5608
FR Tel: 0638645374
More information about the Cerowrt-devel