We should improve the networking stack to better support new networking features such as IPv6, including avoiding unnecessary noise whenever something is changed in supporting such features in libc or in the kernel by providing better integration and supporting applications.

In the interest of keeping up to date with new features, it would be beneficial to stick to the latest possible versions of network management/automation tools such as NetworkManager and ConnMan and similar which regularly provide updates and new features.

Release Note

The network stack has been improved to allow easier configuration for the installer and being online during installation (for uses such as downloading updates, etc). IPv6 support also has been improved by introducing the new version of ISC's DHCP client, version 4, which now supports DHCPv6.


IPv6 support has to be made fully available and well supported, given that IPv4 exhaustion is fast approaching and now slated for as early as March 2011 at the time of this writing (November 2010) [1] [2]

With more and more users with wireless networks, given the large popularity of netbooks, tablets, and other highly-mobile devices we need to work on better supporting or integrating wireless in edge cases like in the installer.

User stories

John works for a large company which is migrating to IPv6 on their internal network. To be able to login to the network, he needs to receive an IP from their new DHCP server.

Johanna bought a brand new tablet that she wants to run Ubuntu on. It's now past release and there has been many updates released which she would like to download as part of the installer; but she must do that while using her wireless connection.


NetworkManager will continue to be a very active project for the time being with good responsiveness towards patches, and quick resolution of upstreamed issues.

isc-dhcp4 will be well supported by both the immediate upstream (Debian) and the authors (ISC).



IPv6 support

Fortunately, dhcp tools have been very well supported by network management applications on the desktop for a long time, and support for the new version is already in NetworkManager at least.

We will rely directly on the implementation from upstream for that. Given that it's not a rewrite and instead a continuation of the project with major new features added, issues related to installing or configuring this are not likely; things will remain working roughly the way they are -- rely on current documentation.

Turn on IPv6 by default in NetworkManager; allowing interface configuration even if an IPv6 address isn't received.

NetworkManager / ConnMan

Update to the latest version proactively; remain on the upstream supported versions. This means sticking to stable releases for ConnMan; and means going over to NetworkManager 0.9 if possible once it's considered stable enough upstream, with providing potential migration tools.

Likely migration requirements for NM:

Test/Demo Plan

Unresolved issues

BoF agenda and discussion

= Goal =
defining the requirements to give the best network experience to users in natty.

= Aspects =

 * kernel drivers (e.g. broadcom)
  * more work required
  * the new opensource driver is currently poor quality and requires many man months of effort, this is not likely to be done within the project for natty

 * network device naming
  * primarily on server people are interested in naming being stable
  * people prefer to have fixed names in some cases
  * udev already supplies stable names for them, but they are not necessarily sane ordering
  * can we use the BIOS naming at all?
  * changing the rules is problematic as preseeds may rely on the current rules
  * we could use a new preseed option to select any new naming

 * DHCP (v4?)
  * we need this to handle IPv6, should pull this in

 * ifupdown
  * doesn't seem to be an updated version

 * wpasupplicant (0.7 ?)
  * kvalo & cyphermox

 * IPv6
  * much of this should already be working
  * testing: will need coordinated testing across many different network environments

 * network manager (0.9 ?)
  * this sounds like it is something we do need
  * likely to switch if it is of sufficient quality in time, but this is likely to hit in a few weeks
  * likely to move to system connections by default, but with ACLs
  * user switch leaves a VPN open for all other user sessions, currently no plan to resolve this, primary focus is preventing exposure of the passwords etc not the connection itself

 * indicator for UI (session Thu 5pm)
  * need indicator support in network manager
  * there is support added to network manager to make adding this kind of bells and whistles easier

 * applications attempt to use the hostname to find IP address, this not so clear if the name points to 127.x
 * use of clock for dhcp leases might be problematic (block skew is not handled which can lead to use of expired allocations)


NattyNetworkStackEnhancements (last edited 2010-11-17 16:17:39 by mathieu-tl)