Subject: WG Action: Detecting Network Attachment (dna)

From: The IESG <[email-masked]>
Date: Wed, 11 Feb 2004 16:57:34 -0500

A new IETF working group has been formed in the Internet Area.  
For additional information, please contact the Area Directors or the WG Chairs.

Detecting Network Attachment (dna)
-----------------------------------

Current Status: Active Working Group

Chair(s):
Pekka Nikander <[email-masked]>
Greg Daley <[email-masked]>

Internet Area Director(s):
Thomas Narten <[email-masked]>
Margaret Wasserman <[email-masked]>

Internet Area Advisor:
Margaret Wasserman <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: subscribe dna
Archive: http://ecselists.eng.monash.edu.au/~warchive/dna/

Description of Working Group:

When an IP 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) configuration and connectivity 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 by the 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[RFC2462,
RFC3315], the DAD status of the addresses[RFC2462],
valid routing prefixes[RFC2461], set of default
routers[RFC2461], neighbor and destination
caches[RFC2461], multicast listener (MLD)
state[RFC2710]. 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 processes.

In some wireless technologies, the link layer state
and events may not be accurate and unambiguous from
the IP point of view. For example, a host may be able
to see a base station but still be unable to deliver
or receive IP packets within the link. Similarily, 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.

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.

Initiation of link change detection procedures can be
achieved either through reception of messages at the
IP layer or through indications from other layers.
The working group will produce a document that
contains a catalogue of the indications available
from a number of link layer technologies.

The working group will produce a document explaining
how a node can make best use of the existing L2 and
L3 information for detecting network attachment.

The working group will define a set extensions to the
current IPv6 configuration protocols [RFC2461, 2462,
possibly RFC3315] that allow the nodes to discover
whether L3 configuration or connectivity may have
changed more reliably and easily than today.

The DNA WG will not define new procedures or APIs
related to link layers.

Goals

      * Document existing link layer (L2) information
          which is useful to start detecting network
          attachment.

      * Specify current practice for detecting network
          attachment and L3 link change in IPv6 networks.

      * Define a protocol extension for detecting
          network attachment and L3 link change in IPv6
          networks more reliably and easily.

      * Develop a DAD optimization protocol, independent
          of link layer (L2) technology.

Goals and Milestones:

Aug 04   Submit Goals for Detecting Network Attachment in IPv6 as informational 
Aug 04   Submit Best Current Practice for Detecting Network Attachment in IPv6 as BCP 
Aug 04   Submit Existing Link Layer Hints Catalogue as informational 
Dec 04   Submit Detecting Network Attachment in IPv6 as Proposed Standard 
Feb 05   Close or Re-charter WG