Something from the conference that was pointed out was that IPv6 support
for MeeGo 1.2 is a best-effort but not mandatory requirement in the
deliverables, due to the already heavy workload and tight timescales.
IPv6 is something I know about, something I can work on (over the next
few months) and I have active/working setup both at home/office and the
data-centre. It is also something that the fear mongers claim will be
uber important to everyone within the next 12 months (due to the last
LIR /8 blocks getting sent out within that time).
I have therefore created an IPv6 workload bug
http://bugs.meego.com/show_bug.cgi?id=10984 and invite anyone with any
input to either comment into the bug or create a separate bug and
associate it to that bug (if the item is a fair chunk of work and/or has
a detailed). Please if you think necessary discuss any points in this
mailing list first.
If you are knowledgable about any sub-system that might be impacted then
please find a moment to speak up and brain dump
The primary goal of this is to answer the question, "What
work/support/testing needs to be done, so that a future release of MeeGo
core can claim IPv6 support". At the moment I don't even have a scope
on that so please speak up. All other matters talked about can be
considered secondary goals. It if by no means certain that enough work
will be done soon enough to be able to make MeeGo 1.2 but the hope at
this time is that that might be possible.
My brain storm of issues are:
* Kernel and user-space support (ipv6.ko, ravd, netfilter, ...
reciprocal to IPv4)
* Startup/shutdown scripts and interface controls
* Configuration management (total feature disable/enable, priority
4over6, auto-config, dhcp6, config tweaks, ...)
* conman/libconic
* Special use cases: MMS (MeeGo handset, private limited connectivity
network)
* DNS resolver (investigate conman proxy)
* Applications (need list of most important to least important
meego-core/handset applications to validate IPv6 support)
* Kernel auto-bind control (priority order, application, maybe this is
something I don't get)
* Testing
Less important but more complex things:
* IPv6 Tethering
* IPv6 Tunneling
The particular item has its heritage in some original Maemo5 goals that
have been put on hold for a while by me.
Such are issues of making sure the device(s) manage being connected via
multiple interfaces (at the same time) in a useful way. For example
WLAN+3G, this includes such things as allowing MMS to just work while
WLAN stays connected, allowing multiple default routes at the same time.
Such as all interfaces (especially chargeable ones) must have some
statistics and charge limiting controls in place, yes this is a feature
that Network Mobile Operators might not like in a product, but hey.
This would also be groundwork to think about seamless cross connectivity
handovers, like walking out of my office WLAN and auto-switchover to 3G
without say loosing an IRC connection, maybe using indirection via VPN
like endpoint. For reference this is a somewhat longer term goal.
There has been a meego-dev thread referencing IPv6 support: "[MeeGo-dev]
developers wanted for MeeGo, Xmpp, Ipv6 project", Jul-2010, OP: Bernd
Stramm, it does not however really discuss the hoops/barriers in the way
for MeeGo core to claim IPv6 support in a future release. My post here
is more about system-wide support than specific application/Qt support.
Darryl
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
