[DNA-BOF] Revised WG Charter

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

Hi,

Here's the charter which Pekka and I put together
after the last session.

Please tell us what you think of the text
(clarity/coverage) and work-items.

Let's start a separate thread if there's need
to discuss the location of DAD optimization work,
though.

Greg

We'll remove the DAD specific sections
if IPv6 WG take on the DAD optimizations.
Of the text in the charter, only the second last
paragraph and one of the dot-points refer to
IPv6 DAD optimization (Indicated with question marks).

Also, there are two deliverables tied to this topic.

---------------------------------

Detecting Network Attachment (DNA)

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, an L3 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[RFC2461],
the DAD status of the addresses[RFC2462], valid
routing prefixes[RFC2461], set of default
routers[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, and to propose 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 preduce 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.

?In order to detect network attachment, it is important
?to be able to send and receive IP messages on the link,
?even if the link has changed.
?The DNA WG will develop a system which allows use of
?an IPv6 addresses while determining if a link has
?changed without the latency cost of the traditional
?DAD [RFC2462].

The DNA WG will not provide explicit directions to
implementors about datalink layer issues.

Goals:

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

* Specify a solution framework for detecting network
       attachment and L3 link change in IPv6 networks.

* Specify a set of extensions to the current IPv6
       protocols for detecting network attachment and
       L3 link change more reliably or more easily than
       today.

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


----------------------------------------
Deliverables:


Detecting Network Attachment in IPv6:
             Goals and Requirements  (Info)            Aug04

Best Current Practice for Detecting Network
           Attachment in IPv6        (BCP)             Aug04

Detecting Network Attachment in
           IPv6 Protocol             (Standards Track) Dec04

Existing Link Layer Hints Catalogue (Info)            Aug04


?IPv6 DAD Optimization Goals and
?         Requirements              (Info)            Aug04
?
?IPv6 DAD Optimization              (Standards Track) Dec04