2.3.5 Detecting Network Attachment (dna)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03


Greg Daley <greg.daley@eng.monash.edu.au>
Suresh Krishnan <suresh.krishnan@ericsson.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

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

The DNA WG will not define new procedures or APIs
related to link layers.


    * Define goals for detecting network attachment in IPv6

    * 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

Goals and Milestones:

Done  Submit to IESG Goals for Detecting Network Attachment in IPv6
Dec 2004  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.


  • draft-ietf-dna-link-information-03.txt
  • draft-ietf-dna-cpl-01.txt
  • draft-ietf-dna-hosts-02.txt
  • draft-ietf-dna-routers-01.txt
  • draft-ietf-dna-frd-00.txt

    Request For Comments:

    RFC4135 I Goals of Detecting Network Attachment in IPv6

    Current Meeting Report

    DNA working group meeting
    Chairs:Greg Daley, Suresh Krishnan
    Minutes: James Kempf, Mohon Parasarathy
    Discussion of agenda
    Additon of some items
    - call for reviewers
    - tentative option
    - milestones
    Link call draft sent to IESG , LC approved
    CPL sent outside for review, not much changes, just clarfications.
    Ready to go. Make consensus call on the list to check for more
    FRD document as WG document in the last meeting.
    Please take a look at the IPR, filed in Korea.
    discussion of drafts
    - WG last call on Alper's draft complete, to IESG
    - CPL draft to last call
    Last meeting, FRD is WG doc, review needed.
    DNA hosts draft updated:
    Presentation by Sathya
    We made the DNA steps explicit..
    there are 3 steps.
    - To see if you have cached information and make use of it. If there is no information,
    - make all the addresses as optimistics
    - Conduct link identification
            Prior info stored related to the links the host visited in the past
            - link change or no useful prior info, follow procedure below
    Link change
    -Change IP config
    - configure DAD
    - MLD 
    Non link change
    -Restore address config state of all addresses
    - Conduct reachability detection to one of default router
    Editorial changes
    We don't say anything for MLD join for solicited multicast address when setting
    to optimistic:
       proposed text from ErikN's email:
     - Host must send MLD join for the solicited node multicast group before
       sending RS message for the CPL 
    Erik Nordmark
    - Not before RS, but MUST before DAD NS (It MUST be done before RS or NS.)
    - Do it before sending RS. .
    - After change state to optimistic
    Erik Nordmark
    - Doesn't have to be that early. Can stay in optimistic forever, but ND is
      inefficient, can't send NS, must send packets to router. Constraint is loose,
      important that it gets sent and then send DAD probe, then wait for a second.
      Might be later
    - Tight constraints on this. Need to send before the RS. Presentation later,
      has to do with snooping switches
    Other changtes 
    - Editorial
    - Diff (will send link to mailing list)
    Next presentation
    Nicolas Montavont
    Router BCP Update
    Brief update draft-ietf-dna-routers-01.txt
    Did not make many changes
    Removed section on Disjoint admin
    about: - Routers should not advertise that belongs to different admin
    Anything else needed here? (No comment)
    Removed background w.o. recommendations
    -Diff (will be posted to list)
    Greg: Review needed on both docs, contact chairs if you want to review
          Want to get docs advanced soon
    DNA relocation delays
    Presentation by Greg, doc written by Chris Vogt, et. al.
    addresses MLD join issue in Sathya's presentation..
    The problem: 
    When we change POA, determine IP address change very fast. Involves
    IPV6 RD, ND,
    - MN configures new address, etc.
    RS (TSLLAO) from MN to AR
    RA back (content depends on router on access link)
    after reception of RA, additional addr and routing config
    IP reattachment, BU etc. may happen after that..
    The problem:
    Optimistic Addresses need to go through optimistic DAD
    Sending NS requires prior transmission of MLD Reprot
    MLD Report should be randomly delayed up to 1 second during interface intialization
    (RFC 2461/2462 bis)
    Objective of delays to desync simultaneous bootup of multiple hosts
    - but it prevents fast IP reattachment due to MLD Report delay
    Erik Nordmark:
    Power goes, power comes back up, all hosts will send at the same.
    - Delay was there to introduce cthe concern.
    - key word is interface initialization. Moving, not 
    - Not bringing interface up and down when moving
    - When you are moving around, this delay may not be needed.
    GReg: Still need to say something
    Erik : Just say that DNA does not ....
    Hesham Soliman
     Adding something to 2461bis would make sense ?
    - saying don't do if MN
    It has to be in 2462bis or MLD ?
    - Would need in MLD also
    - Don't think it needs to be in MLD...
      delay is in MLD also
    - 2462bis, matter of RA
    - Current draft req. on amount of delay for MLD transmission when reiniting the interface
    - discuss in IPv6 WG, Our (IPv6) consensus is that it is too late
      to change in rfc 2462. random delay remains, will remain in RFC.
      This delay is not needed (Personal). No clear consensus on IPv6 WG.
    Greg: We have to make some decision.
    - Trying to clarify
    -This might be where to do it,
     Goal of this draft is to make recommendations
    - Is delay not needed?
    - Clarification makes sense.
    - No impediment from IPv6 WG, should we do it.
    - Erik's point, discussion on RSes and soforth, global clarification that chaning
      APs and interface init are not the same thing. Don't put same constraints
      on moving between APs as on init
    Greg continues
    MLD report sent  before oDAD NS, delay is not necessary
    RS is tricky one
    RS/RA - no additional messages between them.
    Router understands the tentative options and hence sends RA. If the router does not
    understand TSLLAO, things may not work.
    If not, can't push LL addr, which would lead to NS/NA exchange which would need
    MLD report
    Omit delay for initial MLD Report upon movement
    there might already be desynch at the link layer when you attach from moving
    Start optimistic DAD before initial NS, use for RS prior to NS for oDAD
    Erik Nordmark comments
    oDAD is set up so you don't have to complete before you send RS/RA. Questions about
       wording in spec, oDAD spoec still says you must send NS when you go optimistic.
       Can go into optimistic mode, send RS, then MLD Report. If RA says didn't move,
       turn off optimistic mode
    Cost of opti mode is low enpough that you can stay in as long as needed
    If router supports DNA, you get response immediately
    RS/RA, then do MLD
    Not sure
    MLD snooping switch, multicast is not treated like broadcast, then switches
    need to have multicast group state, need to send MLD group join at new port
    before you can send NS. Legacy router, will try multicast delivery or unicast
    delivery RA with NC entry. Snooping switch won't get NS. 
    MLD group join, won't get NS if router sends it (due to lack of NC entry),
    because snooping switch doesn't have state
    Greg: MLD required only for solicited node multicast..
    Ignoring SNMCaddr, moved or didn't, hint is layer 2 move. Need to send MLD reports for all. Movement at L2 matters for snooping switches. 
    To get RA, only intereseted in NS, so only interested in SNMCaddr
    But what about other multicast groups, don't know if switches are snooping, can't
    tell if moved port
    Brett Petland
    DNA router will support tentative options
    If not, normal response would be multicast
    Assuming multicast for legacy routers, don't have snooping switch networks
    Router only send multicast if scheduled to send, normal behavior is to send unicast
    to solicitor.
    SHOULD in 2641
    Legacy router sees no don;t understand TSLLAO. either needs to resolve with NS or
    multicast the RA back
    Question, if you have legacy router, if it tries to unicast (sends NS),
    then host sends RS. Host sends RS, doesn't see response because switch drops
    multicast. Need to do the MLD at some point in time.
    Eventually recover on multicast RA
    Bigger problem with MLD in general, manditory part of spec, need link layer trigger
    Hesham : eventually Router might send a RA.
    	 MLD in general. MLD and snooping switch. If the interface goes up and
             down, then need to do elaborate procedure of joining all groups..
    Subdir Das
    How do you know interface went down and came up.
    WG doc describes link indications (could look at DNA triggers)
    Reduce delay for MLD, special case for interface already up, how do you
    distinguish that it is a special case? Hard to special case.
    We are already making a special case..
    Already using special case for RS
    Generic problem, synch is a problem, don't know how many MN are doing it
    MLD problem might be solved here or somewhere else
    2 questions on MLD join. Neither question are answered in host BCP. What should be done? 
    suggestions about general guidance for difference between reiniting and moving.
    Is that something we should look at? Difference in delays should be identified.
    Might not be explict DNA thing. 
    Sathya: should do in DNA?
    Hesham : Years of confusion in interface goes up/down, should be done in DNA.
    We can try to put into host BCP draft
    Or possibly MLD draft
    MLD join, done when L2 hint or? Quesions are open.
    Suresh : Right place to address is DNA and not IPv6 because IPv6 is not worried
    	about getting the documents out so fast..
            a reference is not very good. Should address in DNA.
    Sounds as if a generic issue for MLD with snooping switches
          Not fast enough for us, it is in MLDv2bis  but it is not clear for movement.
          Ref in 3590.
    Rajeev Koodli
    Router gets RS with temp SLLA, repsond with RA to that address or send multicast. 
    Can it do an NS?
    Greg: Yes, the receipient can do an NA with override flag reset
    What is requirement for node that hasn't sent MLD
    distinction if multi or uni. some daemons don't know if there's a NC entry
    NS, address is still optimistic. 
    Recpipiet can do NA w.o. setting NC enttry
    Before RS, set to optimistic
    Dosn't need to send NS right away, incorporate guidance deferral of
    NS whether or not separate guidance for MLD, another story
    (sense of room)
    Distinct problem that generic guidance for difference between movement and
    initialization, and document. 
    (hum) - nobody against
    Next question
    Separate document to describe guidance for differences between movement and
    separate doc: (confusion on question)
    Sathya : Host BCP document. Adding more drafts is not good.
    Brett: Applies to both BCP and Solution dradft.
    (Greg puts the question into a slide)
    a) separate document
    b) PUt in existing DNA docs. 
    Pat Stevens (HMS)
    There might be scenarios where there might be an interface going up and down
    Might not know if transmission event, might look like movement but
    might be same behavior like up and down. All hosts lose connectivity,
    looks like a mobility event, but same behavior as interface up and down
    Looked at it for 11b, same for BS failure and everyone moving out of
    range at same time, missing beacon, etc. Devices moved out of range
    simultaneously. In 11b, serialization done at 802.11b probe phase
    did some serialization: LL desyncs. Some link layers will sync, but
    with certain MACs, will desync. 
    Also most MAC layers, handled by MAC. If you're already assoc with AP,
    lose AP and comes back up, no contention based access. If you need to
    go through contention based access, problem.
    Point well taken. We will say clearly that "If the link layer is
    desynchronised.." do the following..
    Same document or Existing document ?
    Back to concensus call
    A)	Separate document : No Hum.
    B)	Existing Document : Hum.
    Which doc?
    a) drafct-vogt-dna-reloc?
    b) draft-dna-hosts
    draft-vogt is not a WG document, so not "existing"
    draft-vogt solves two problems
    Question, what is DNS hosts BCP for? Can be regarded as protocol
    change or variation, might not best if protocol change
    hosts document is a BCP and not standards track.
    We can make hosts doc standards track if necessary
    More general concept. And not specific to vogt*.  Need to describe
    how you know diff between init and mobility, makes sense for generic doc
    Greg: Do you think it is a DNA thing ?
    Hesham: Yes, it is.
    Suggestion. Don't get working group consensus yet ? Don't know
    what is described in these documents.
    Have people working on docs work this out.
    Who thinks we have enough understanding to make a decision?
    do: no hum
    dont': (hum)
    Group consensus is that there is not enough understanding about what is
    contained in these documents.
    Take it to the list.
    Talk on the list about when MLD join should be done
    (Next topic)
    Rajeev Koodli
    FMIPv6 and DNA
    FMIPv6 usage with DNA protocol
    Presented this at Paris, 
    To document how FMIPv6 can be used with DNA ?
    FMIPv6 makes use of neighborhood information to expedite handovers ?	
    FMIPv6 makes use of neighborhood info to expedite handovers - resolve AP
    ids to router mac and IP addrs
    DNA provides fast movment detection across subnets
    Scenarios where neighborhood information is not avaialble, DNA
    Nhood info might not be available, DNA can assist reacitve handover
    (description of protocol)
    can help fast reactive handover MN associated with Access point
    and obtains the AP-ID, Ar-info, if information not available use DNA
    Rtr solicitation with DNA extension
    configures address, 
    MN sends a FBU to PAR directly
    PAR sends HI message, Handover acknoweldge message
    PAR sends FBA
    PAR starts tunneling packets to MN's new COA
    Current spec, encap fast BU inside FNA, if oDAD used might cause collison,
    but no fifference with normal oDAD
    Suresh: Informational document. How many folks have read the draft ?
    	- couple of folks.
            Accept as WG item ?
    Suresh: Useful to document? (30 hands)
    Not interested? (no hands)
    Interest in doing work
    There is interest in pursuing this work.
    Hesham : RFC 4068 is being updated. Done there or here ?
    4068 is being updated. Should it be done in 4086 or here?
    Why do it here? No protocol modifications, just documenting steps.
    DNA is right place to do it. Can reference, if you resort to DNA, here is how to do it.
    Should this document in DNA WG? 12
    Do elsewhere? 3 hands
    Concensus to work on here
    James Kempf : Splitting the work into multiple documents makes it hard..
    		 No Hyper links. Searching too many bits..
    Rajeev: Instead of cleaning separate protocols, have a single monster.
    		No normative dependency.
    Greg: We don't have to push this if FMIPv6 comes out as proposed standard
    Brett Pentland
    Solution document presentation, draft-pentland-dna-protocol3-00.txt
    Based on two piror proposals
    (describes FastRA)
    (describes link idnentification, landmark prefix)
    Description :
    	FAST RA and link-id
    Fast RA: Calculate token based on RAs from other routers and RS and calculate token
    Link-identification : 
    	- routers listen to all prefixes on the link
    	- new option for learned prefixes
    	- one of them is marked as link-ID prefix
    	- hosts include a landmark
    	- landmark yes or no
    	- unsolicited RAs may carry a subset of prefixes but must include a link-id
    Link Identification:
    	- RAs include a link-id prefix
    	- moving to new AP still includes the prefix, 
    	Identification based on non-prefix information, no supporting emails on ml
    	Explicit link-identifiers - mark the prefix: alt non prefix (biggest issue)
    	TSLLAO option, where does it belong
    	Delivery of MLD packets during DNA (presentation to follow)
    Where is the TSLLAO draft?
     Not in any WG, individual w. IPv6 tag. Separate draft, may need to have it
     separate if additional uses. Primary use DNA, include in base DNA spec.
     Generally applicable w. oDAD, send unicast NS, send this option instead
     of destructive source link layer document.
    Suresh : How many have read the document ?
    Suresh : People with issues last time, are the issues solved now?
    Should we adopt this as WG document ? 23
    NO : zero
    Consensus to accept it as WG document.
    Non-prefix link identifiers : 
    Racquel Morera:
    Could be useful in adhoc networks. Explicit link ids could be useful, could
    be easier to include now. 
    OK to be an explict prefix id
    Brett: Can RS/RA even work in adhoc network ?
    JinHyeockChoi : DNA is good with explicit link identifier. Host can check for
    	  link change for link identifier even for RA. Linkid 
    Not based on prefixes
    Questions to resolve in adhoc
    Link id, explict id is more friendly to ad hoc environment, host can check
    with complete RA. Link id is landmark prefix, prefix all routers know,
    link id prefix is natural choice. W. explicit link id more gracefully
    deal with link prefixes changes.
    Some crossover, need to figure whether we need first, non prefix, or whether
    simpler to incorporate now.
    Mesh networks, RS/RA, is this compatible with mesh
    Nonprefix ids, still might need explict w.o. nonprefix (i.e. explict but prefix)
    prefix like ids but not a prefix. Don't know what ad hoc is. If you need to assign
    some form of id, does it have to be different than 128 bits? Can you use ULAs, but
    not too many. Don't set L or A bit. As long as I can use as link id, just use with
    DNA. Don't know what might be needed, keep door open. Only used for link id
    purposes. Don't know requirements. 
    Explicit link id in router advert, rather than using prefix from prefix list?
    ULAs are just prefixes, bit that says its a link id, but not a routing prefix
    to say that don't use it for other purposes. But don't know enough about
    Hosts don't know that there is a link id, do hosts need to understand what is
    the link identifier.
    Suresh: Pick a 128 identifier,looks like a prefix,  mark as not a prefix,
            someone will still use it.
            We don't know enough about it to work on it, so I think we should postpone.
            Another issue, how do we come up with this link id, manually configure, we are
            not ready to work on this.
    Agree these are issues, but Greg suggests scheme to solve two at once
    Sathya: Two problems
           Agree w. Suresh. One, devices agreeing on common id to define link,
           having separation between routers and hosts, no definition from
           ad hoc network point of view, open for ad hoc. We are just trying for small
           forward compatibility, add a it somewhere. Will this make a difference?
    (as nonchair) If we wanted to do nonprefix link id, we would need to track validity of id separately from prefixes, not something that we have not really done much on. Would it be OK to add nonprefix ids later as an option. Absence of nonprefix, use prefix ids only for DNA.
    Are you saying that we should have an explicit link identifier?
    If we don't know how to do this now, we can get away with not defining these now, add explicit link id, we could add it in later, won't hurt operation of this draft. 
    Then would redo DNA
    No, just nonprefix link identification
    Wouldn't overlap condition on hosts still apply? One router with idnentifer?
    Agree with Sathya
    Hesham : Use some bit for indicating the DNA operation.
    New bit, needs to be present in all adverts
    Just an entry in prefix list though not a prefix
    Ad hoc, not clear what is valid link configuration. Wait until it becomes clearer.
    Do we need to add even later? Can have prefix, enough flags to indicate to use for
    autoconfig or not. Use for either case. Diff is can you use it for generating addresses.
    How can you solve this problem? Smallest prefix is fine, just stick with that.
    Change will not be that costly on existing. Lot more changes on router behavior,
    agree on an id, etc. not suggesting this. 
    Not necessary to define a new id, whether to announce explicitly
    Don't mandate if use prefix as link identifier, could be a link identifier.
    Say that it is lowest prefix, but can change it.
    Don't tightly couple. Decouple
    Mohan and Suresh argue about how to do this
    Current solution will break down, have to mandate something for the current problem.
    Separate idea of prefix from link id? Routers have a way of selecting different link id. 
    Should be open to having not having shortest prefix, but we should have a default.
    Routers put flag in saysing this is link id, default is shortest prefix, but possible to change in future
    Flag for link id, what's the point of shortest?
    Routers need to agree.
    Host isn't involved. Routers need a way to pick this. 
    Say that explicit, separate bit
    One step, this is link id. Two, can you use to configure addresses
    Some of bits are in prefix info options.
    One bit may not be sufficient
    TSLLAO Draft
    Normatively referenced by two documents, which are WG docs
    IPv6 chairs want this done in DNA cause IPv6 WG is going into hibernation
    Greg will present
    (briefly summarizes draft)
    Optimistic DAD does not let you use SLLAO:
    RFC 2461 has a SLLAO is an option to provide the link-layer address
    in order for the receiver to respond without doing NS.
    Problem with SLLAO is that it always overrides NC entry in the receiver,
    would like to get unicast back to an optimistic address 
    If we are not sure whether we have arrived on the new link, we need
    TSLLAO so that we don't destroy the NCE.
    TSLLAO does not destroy NC entry
    Implementation in Linux available from Greg
    RS can't be unicast without option, need to do NS. Necessary to have
    this done, IANA allocation
    Solution all you need is Mac address for repsonse for RA, create NC 
    entry for packet. Optimistic DAD is written such that create an NC 
    entry if you don't have it.
    Can send unicast packet back without a Neighbour Cache entry. 
    Does create entry if no entry is there?
    With oDAD, small chance of collision, if there's a collision, we want 
    operations to be safe for original address owner, advantage if temporary, 
    won't create or modify an entry (GD: if an entry exists). MAC binding will
    be delivered to another destiantion if there is another NC entry.
    Suresh: Is there an interest adopt this work ?
    WG item - 8 hands
    none against
    Consensus : Do it on mailing list ?
    Know it's a late agenda item, not trying to shove something through.
    Should this be in a separate document? 5 hands for
    Part of solution document? 2
    confirm on list
    Vijay: Small extension, should be part of solution.
    Brett : Keep it separate because FRD uses it
    DNA solution protocol by April 2006: 
    	- Interested in the document ?
    	- Looking for significant comment before that to make that decision ?
    Revise milestones- need to come up with realistic dates
    Greg presents
    Need to set milestones that reflect dates by when documents delivered. 
    Can submit link layer hints to IESG (passed last call already) next week
    Hosts/Routers BCPs
     - can we get it reviewed by Jan. next year?
    Would include MLD relocation and other guidance
    Willing to review docs? 3 hands
    Vijay, Hesham, Bret, Mohan volunteetered to review..
    Solutions framework
    draft expired, anyone interested? (no hands)
    Anyone opposed to let it die? (no hands)
    Bretts doc doesn't make clear why it was designed a certain way. Is other
    document a design doc or a solution framework? Doc was available in Mobike. 
    Confirm on mailing list
    Write framework after? No objection. Will talk to Maragaret.
    Solution doc done
    Interest in helping complete by April 2006? couple hands
    Some people are interested. 
    Significant comment required before March


    DNA Agenda
    Analysis of IPv6 Relocation Delays
    Fast Handovers for MIPv6 with DNA
    DNA Solution Proposal