Monash Info

News & Events

Campuses and Faculties

Monash University

Centre for Telecommunications and Information Engineering

Detecting Network Attachment Charter Development.

This page provides the current status of the charter development for the Proposed Detecting Network Attachment DNA WG.

It is important that newcomers read the IETF 'Note Well' Statement.

Proposed Detecting Network Attachment (DNA) Working Group Description:

Here is the currently proposed text for the charter for DNA.
Please note that subsection titles are temporary and for the purposes of text development.

Charter now incorporates AD comments. Needs internal re-check.

Working Group Name:

Detecting Network Attachment (dna)

Last Modified: 2004-01-09


Greg Daley <Greg.Daley@eng.monash.edu.au>
Pekka Nikander<pekka.nikander@nomadiclab.com>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret.wasserman@nokia.com>

Internet Area Advisor:


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:

[Overview|Attachment Detection|Link Hints|Goals|Deliverables|Revision History]

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

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 define best current practice for nodes making use of existing L3 and L2 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.


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


  • Aug 2004: Submit Goals for Detecting Network Attachment in IPv6 as informational.

  • Aug 2004: Submit Best Current Practice for Detecting Network Attachment in IPv6 as BCP

  • Aug 2004: Submit Existing Link Layer Hints Catalogue as informational.

  • Dec 2004: Submit Detecting Network Attachment in IPv6 as Proposed Standard

  • Feb 2005: Close or Re-charter WG.

No Internet-Drafts

No Request For Comments

Revision History

  1. 2003-08-22: initial revision
  2. 2003-09-08: added text about link-layer connection to first para.
  3. 2003-10-07: Formatted for last call, removal of paragraph headings.
  4. 2003-10-16: Last Call Completed, Ready for AD review.
  5. 2003-11-10: Attempt to incorporate AD (Thomas) Feedback.
  6. 2004-01-06: Revised charter with WG feedback.
  7. 2004-01-09: Minor Amendments missed from WG feedback.
  8. 2004-01-14: Removed DAD opt.

Site Administrative contact:

Greg Daley

updated 9 Jan 2004

Please direct feedback regarding this site to the Administrative contact.

Monash University ABN 12 377 614 012
Copyright © 2002-2002 Monash University - Last Date Modified: 9 January 2004 - Caution

Help Contacts Site Map Staff Directory Search