Detecting Network Attachment (dna)

Last Modified: 2006-04-18

Additional information is available at tools.ietf.org/wg/dna

Chair(s):

  • Greg Daley <greg.daley@eng.monash.edu.au>

  • Suresh Krishnan <suresh.krishnan@ericsson.com>

    Internet Area Director(s):

  • Jari Arkko <jari.arkko@piuha.net>
  • Mark Townsley <townsley@cisco.com>

    Internet Area Advisor:

  • Jari Arkko <jari.arkko@piuha.net>

    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
    Feb 2005  Submit to IESG Recommendations for Detecting Network Attachment in IPv6
    Feb 2005  Submit to IESG DNA solutions for IPv6 Framework document
    Apr 2005  Submit to IESG Protocol Enhancements for Detecting Network Attachment in IPv6
    May 2005  Close or Re-charter WG.

    Internet-Drafts:

    Link-layer Event Notifications for Detecting Network Attachments (45715 bytes)
    DNA with unmodified routers: Prefix list based approach (64550 bytes)
    Detecting Network Attachment in IPv6 - Best Current Practices for hosts. (44226 bytes)
    Detecting Network Attachment in IPv6 - Best Current Practices for Routers (41931 bytes)
    Fast Router Discovery with L2 support (35769 bytes)
    Detecting Network Attachment in IPv6 Networks (DNAv6) (76123 bytes)
    Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery (28673 bytes)
    FMIPv6 Usage with DNA Protocol (12357 bytes)
    Detecting Network Attachment in IPv6 - Network Deployment Considerations (41221 bytes)

    Request For Comments:

    Goals of Detecting Network Attachment in IPv6 (RFC 4135) (20518 bytes)
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.