[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [DNA-BOF] Modified Charter available.
Hello Greg
This charter looks good but unstable DAD issues.
This charter is definitely describing DAD is one of
remarkable considerations for IPv6 address configuration
quickly, however DAD optimization issue is still unstable.
Silence gives consent...otherwise I have no opinion to offer.
with best wishes !
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.
> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au
> [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of Greg Daley
> Sent: Thursday, January 08, 2004 7:49 AM
> To: dna@eng.monash.edu.au; greg.daley@eng.monash.edu.au
> Subject: [DNA-BOF] Modified Charter available.
>
>
> Hi,
>
> (This is a repost. Sorry if you receive this
> twice, I've not seen it appear).
>
> I've made some modifications to the charter
> based on the group's feedback.
>
> The charter description is below.
>
> Once again DAD optimization text has a question mark (?)
> at the start of each line.
>
> It's also available at:
>
> http://www.ctie.monash.edu.au/dna/charter.htm
>
> Please tell me if there are any other issues.
>
>
> Detecting Network Attachment (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.
>
> ?In order to detect network attachment, it is
> ?important to be able to send and receive IP packets
> ?on the link, even if the link 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 link-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 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.
>
> 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.
>
>
>
>