Detecting Network Attachment (dna) ---------------------------------- Charter Last Modified: 2008-09-23 Current Status: Active Working Group Chair(s): Greg Daley Suresh Krishnan Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:dna@eng.monash.edu.au To Subscribe: majordomo@ecselists.eng.monash.edu.au In Body: subscribe dna Archive: http://ecselists.eng.monash.edu.au/~warchive/dna/ Description of Working Group: When an IPv6 node detects or suspects that its underlying link layer (L2) connectivity has or may have undergone a change, it needs to check whether its IP layer (L3) addressing and routing configurations are still valid or have changed. In the case that the L3 connectivity has changed, the node needs to reconfigure and may need to initiate mobility procedures, such as sending Mobile IP binding updates. Changes in an L2 connection do not necessarily mean that there has been change in L3 connectivity. For the purposes of detecting network attachment, an L3 link is defined as the topological range within which IP packets may be sent without resorting to forwarding. In other words, a link is the range where a given IP configuration is valid. In IPv6, the IP layer configuration information includes the set of valid unicast addresses[RFC 2462, RFC 3315], the Duplicate Address Detection (DAD) status of the addresses[RFC 2462], valid routing prefixes[RFC 2461], set of default routers[RFC 2461], neighbor and destination caches[RFC 2461], multicast listener (MLD) state[RFC 2710]. The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection. The main goal of this WG is to develop mechanisms that reduce or avoid such delays, in cases where they are not necessary. For example if an interface comes back up after having been down momentarily, it can be quicker to verify that one is still attached to the same link than rerunning the full reconfiguration as if one were connecting to a new L3 link and had no previous configuration information cached. In some wireless technologies, the link layer state and events may not give an accurate indication of whether or not the IP addressing configuration and routability have changed. For example, a host may be able to see a base station but still be unable to deliver or receive IP packets within the L3 link. Moreover, a hardware indication that a radio link is up does not necessarily mean that all link layer configuration, such as authentication or virtual LAN connectivity has been completed. Therefore detecting network attachment requires not only change detection but IP layer connectivity testing. The purpose of the DNA working group is to define standards track and BCP documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today. The group will define a set of goals for detecting network attachment, describing existing issues and important properties of potential solutions. The working group will describe best current practice for nodes making use of existing information for detecting network attachment. The working group will define a set of extensions to the current IPv6 configuration protocols [RFC 2461, 2462, possibly RFC 3315] that allow the nodes to discover whether L3 configuration or connectivity may have changed more reliably and easily than today. Initiation of L3 link change detection procedures can be achieved either through reception (or lack of reception) of messages at the IP layer or through indications from other layers. The working group will produce an informational document that contains a catalogue of the indications currently available from a subset of wireless link layer technologies. The DNA WG will not define new procedures or APIs related to link layers. Documents * Define goals for detecting network attachment in IPv6 (Informational). * Specify recommendations for detecting network attachment and L3 link change in IPv6 networks (BCP). * Define a protocol extension for detecting network attachment and L3 link change in IPv6 networks more reliably and easily (Standards Track). * Document existing link layer (L2) information which is useful to start detecting network attachment (Informational). Goals and Milestones: Done Submit to IESG Goals for Detecting Network Attachment in IPv6 Done Submit to IESG Existing Link Layer Hints Catalogue Oct 2008 Submit 'Tentative options for link-layer addresses' to IESG as Standards Track Nov 2008 Submit 'Detecting Network Attachment in IPv6' to IESG as Informational Jan 2009 Submit 'Simple procedures for Detecting Network Attachment in IPv6' to IESG as Standards Track Mar 2009 Submit 'Fast Router Discovery with Link-Layer Support' to IESG as Informational Mar 2009 Close WG Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 Mar 2009 Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery Apr 2008 Jul 2009 Simple procedures for Detecting Network Attachment in IPv6 Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC4135 I Aug 2005 Goals of Detecting Network Attachment in IPv6 RFC4957 I Aug 2007 Link-layer Event Notifications for Detecting Network Attachments