NattyNetworkStackEnhancements

Differences between revisions 11 and 12
Revision 11 as of 2010-11-17 15:40:07
Size: 2255
Editor: ua-178
Comment: use as template
Revision 12 as of 2010-11-17 16:17:39
Size: 6289
Editor: ua-178
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
 * '''Launchpad Entry''': UbuntuSpec:foo
 * '''Created''':
 * '''Contributors''':
 * '''Packages affected''':
 * '''Launchpad Entry''': UbuntuSpec:packageselection-n-network-stack
 * '''Created''': 2010-10-12
 * '''Contributors''': MathieuTrudel
 * '''Packages affected''': network-manager, wpasupplicant, dhcp3/isc-dhcp, debian-installer
Line 11: Line 11:
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.
Line 13: Line 17:
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.
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.
Line 19: Line 21:
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) [[http://www.potaroo.net/tools/ipv4/index.html|[1]]] [[http://ipv6.he.net/statistics/|[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.
Line 20: Line 26:

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.
Line 23: Line 33:
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).
Line 25: Line 39:
You can have subsections that better describe specific parts of the issue.
Line 29: Line 43:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: === IPv6 support ===
Line 31: Line 45:
=== UI Changes ===  * Get isc-dhcp from unstable into Ubuntu
Line 33: Line 47:
Should cover changes required to the UI, or specific UI that is required to implement this 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.
Line 35: Line 49:
=== Code Changes ===  * DHCP server support
Line 37: Line 51:
Code changes should include an overview of what needs to change, and in some cases even the specific details. 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.
Line 39: Line 53:
=== Migration ===  * Client support
Line 41: Line 55:
Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.
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:
 * nm-system-settings.conf renaming to NetworkManager.conf
Line 48: Line 66:
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.  * IPv6: Once ISC-DHCP v6 is available in Ubuntu, testing process is simple: install a DHCP server (using isc-dhcp-server) that hands out IPv6 addresses, use a default Desktop install to verify NM gets IPv6 addresses.
Line 50: Line 68:
This need not be added or completed until the specification is nearing beta.  * Wireless support: wireless configuration should be available in some form in both d-i menus/workflow and in Ubiquity.
Line 54: Line 72:
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. ##This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
Line 58: Line 76:
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. {{{
= 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

Issues:
 * 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)
}}}

Summary

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.

Rationale

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.

Assumptions

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).

Design

Implementation

IPv6 support

  • Get isc-dhcp from unstable into Ubuntu

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.

  • DHCP server support

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.

  • Client support

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

  • IPv6: Once ISC-DHCP v6 is available in Ubuntu, testing process is simple: install a DHCP server (using isc-dhcp-server) that hands out IPv6 addresses, use a default Desktop install to verify NM gets IPv6 addresses.
  • Wireless support: wireless configuration should be available in some form in both d-i menus/workflow and in Ubiquity.

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

Issues:
 * 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)


CategorySpec

NattyNetworkStackEnhancements (last edited 2010-11-17 16:17:39 by ua-178)