[DNA-BOF] Example of 'IP neighbourhood' instead of 'L3 link' in charter.

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

Hi,

Here's the charter with the replacement of all IP layer
'link' mentions replaced with (IP) neighbourhood.

This is to avoid potential ambiguities in the use of
the term (L3) link with L2 entities.

At the moment, the same caveats about DAD optimization
text disappearing apply.

Please read though it to see if this is appropriate.
Early feedback is encouraged, as mentioned before.

Also, there are minor modifications to the text
to bring it up to date with previous feedback.
(Accidentally absent before)

Greg



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
IP neighbourhood is defined by the range within which
IP packets may be sent without resorting to forwarding.
In other words, a neighbourhood 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 IP neighborhood.
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 neighbourhood 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.

?In order to detect network attachment, it is important
?to be able to send and receive IP packets, even if the
?IP neighbourhood has changed. The DNA WG will develop
?a system which allows use of an IPv6 addresses without
?the latency cost of the traditional DAD [RFC2462].
?Such a system may allow the transfer of user data
?while neighbourhood change detection and DAD
?procedures are in progress.

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 IP neighbourhood change in IPv6
     networks.

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

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

Deliverables

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.

?Aug 2004: Submit IPv6 DAD Optimization Goals as
?          informational.

?Dec 2004: Submit IPv6 DAD Optimization as Proposed
?          Standard

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

Feb 2005: Close or Re-charter WG.