2.3.4 Detecting Network Attachment (dna)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-18


Pekka Nikander <Pekka.Nikander@nomadiclab.com>
Greg Daley <greg.daley@eng.monash.edu.au>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.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 04  Submit to IESG Existing Link Layer Hints Catalogue
Feb 05  Submit to IESG Recommendations for Detecting Network Attachment in IPv6
Feb 05  Submit to IESG DNA solutions for IPv6 Framework document
Apr 05  Submit to IESG Protocol Enhancements for Detecting Network Attachment in IPv6
May 05  Close or Re-charter WG.


  • draft-ietf-dna-goals-04.txt
  • draft-ietf-dna-link-information-01.txt

    No Request For Comments

    Current Meeting Report

    Monday Minutes taken by John Loughney and Christian Vogt

    DNA Working Group Meeting
    March 7, 2005, 15:30pm to 17:30pm
    IETF 62, Minneapolis

    CHAIRS: Greg Daley <greg.daley@eng.monash.edu.au>
    Pekka Nikander <pekka.nikander@nomadiclab.com>


    1. Introduction, Status Update

    2. L2 Event Notifications
    Alper Yegin

    3. Media Independent Handover Services and Interoperability
    Ajay Rajkumar

    4. DNA with unmodified routers: Prefix List based approach
    JinHyeock Choi

    5. BCP For Hosts
    Sathya Narayanan

    6. BCP For Routers
    Sathya Narayanan

    7. DNA Design Team Update
    Brett Pentland

    8. Conclusion
    Greg Daley, Pekka Nikander


    - 10 min wg status and summary

    overview of the agenda
    overview of WG status
    3 items are late
    Goals draft in RFC editor's queue
    Send-CGA has just passed AUTH-48, SEND-ndopt is currently in AUTH-48.

    - 20 min link information draft
    Alper Yegin

    New version of ietf-dna-link-information-01.

    New text with respect to 802.11 ad-hoc mode.

    New text on 802.3, Greg would like someone to review.

    Comments from John Laughey will lead to clarifications affecting the GSM, GPRS, and UMTS parts of the document.

    John Loughney: Terminology is not so good. I volunteer for enhancing this.

    John Loughney: Notifications can be spoofed; this might lead to DoS attacks. Volunteer for text on this, too.

    Reviews from Pekka Savola & Bernard Aboba will be sent to the draft.

    - 20 min 802.21 status and liaison
    Media Independent Handover Services and Interoperability
    Ajay Rajkumar 802.21 Chair

    Media Independent Handover:

    IEEE 802.21 considers handovers between the following technologies
    - between 802.xx and 802.yy
    - between 802.xx and Cellular (3GPP, 3GPP2)
    - between 802.11 ESS
    where x,y = 3, 11, 15, 16.

    Won't specify the mobility protocol used.

    All scenarios but the last are handovers between different technologies. In all scenarios including the last, the question of whether a node has changed IP attachment when it changes its AP is a critical one.

    Session continuity is important, so that there is service continuity at the application layer.

    Session continuity has three components
    - adaptation to new link at layer two
    - address continuity at layer 3
    - service continuity at application layer

    Lots of info that is required to move from interface to interface and maintain session continuity. A basic list was shown.

    active work items:
    - MIH model
    - event-trigger service model
    - information service

    - Should MIH a layer, should an API be defined, should the transport mechanism be defined?
    - How should the APIs to upper and lower layers be defined?
    - Should the transports be defined for remote, local triggers?

    define these in a RAN & in the MN

    MIH model

    Modelling mobile terminals is easy: Assume PHY, MAC, LLC in every mobile terminal except in cellular ones. But within the network, things are more complicated, because a certain layer is usually implemented in different entities.

    signaling diagram for the MIH model is shown. See slide.

    signaling diagram for cellular side is a bit different than for the 802.xx version

    Keith Moore: (paraphrase) objects to the statement "no overlap/no switching" is possible, thinks its because 802.21 has scoped it outside of the presentation.

    Example: MN has 802.11 and cellular interface. When 802.11 interface recognizes fading signal, it signals this information to the MIH layer. MIH layer looks for alternative interfaces and initiates scanning at those.

    Alper Yegin: asked about the cellular diagram - is it between 2 IP nodes?
    Ajay Rajkumar: this is open, not specified. It could be over IP.

    Alper Yegin: What are the endpoints for MIH signaling? Can such signaling be over the air?
    Ajay Rajkumar: Yes, it could.

    Alper Yegin: Is IEEE 802.21 developing a special MIH signaling protocol?
    Ajay Rajkumar: This has been discussed.

    Alper Yegin: could have some signaling between different networks.
    Alper Yegin: resembles 'smart networks' like cellular
    Ajay Rajkumar: that is one scenario, but MN might have the policy

    Pekka Nikander: What will be carried within the MIH signaling?
    Ajay Rajkumar: I can give examples, no slides, though.

    Pekka Nikander: I would prefer to not specify the transport. The reason is that L2 information must provided early to/by MIH. But you have to exchange 15-20 messages for L2 attachment with 802.11 or 802.11i. This, in turn, prohibits using IP as a transport in some cases. So, it needs to be carefully considered which transport to use.

    Ajay Rajkumar: <missed?>

    Pekka Nikander: It seems that you require all interfaces of a MN to belong to the same operator. This business model may not be feasible in all situations.

    Someone: CS cellular or PS?
    Ajay Rajkumar: (paraphrase) only PS, no CS.

    Gabriel Montenegro: How much information do you want to carry in the MIH protocol? Too much information could be an issue with certain link layers.. E.g., the maximum payload that can be carried in IEEE 802.15.4 frames is 102 bytes.
    Ajay Rajkumar: IEEE 802.15 is not currently directly addressed. The group is chartered for it, so this may be done at a later point.

    Stefano Faccin: (answering to Gabriel) The information carried in the transport is modular. Different link layers use different modules, so the information that would be exchanged over 802.15.4 would be such that it fits the maximum frame size. Things can also be sent in multiple messages/round trips.

    Event-trigger service model
    - Local triggers
    - Peer-to-peer remote triggers

    Local triggers
    - link up
    - link down

    Should be generic enough to function over different access

    Other triggers are specific to some bearers. How to limit the
    amount of possible triggers?

    Peer-to-peer remote triggers
    - authentication done
    Several modes of transport; granularity issues being discussed

    Alper Yegin: What kind of triggers are being defined?
    Ajay Rajkumar: link up, link down, pre-authentication, post-authentication.
    still being discussed. large number is being discussed.

    Information Services
    - Security mechanisms
    - location
    - cost of link

    Call for proposal issued on September 28, 2004.
    Initial draft text due in May 2005.

    Stefano Faccin: IEEE has not the power to define a L3 transport. This needs to be done in the IETF.

    Someone 3: IAB l2 draft question? will it be handled in DNA?

    Pekka Nikander: It is an IAB draft, will discuss with Bernard

    S3: Thinks that the solution for the MIH signaling should be done in the IETF

    Pekka Nikander: I think we agree that IEEE and IETF need to closer co-operate with respect to 802.21.

    Alper Yegin: 802.21 folks may want to take a look at the CARD protocol. This protocol can also carry information to mobile terminals about potential new attachment points.

    S3: yes, it will be considered.

    - 10 min DNAv6 with unmodified routers: Prefix List Approach
    JinHyeock Choi
    JinHyeock Choi: The DNA WG is working on efficient mechanisms for L3-handover detection that may also be applicable to link changes between DNA links and non-DNA links. E.g., look at the Complete Prefix List proposal:

    discussion of goals

    basic idea: a host collects all prefix on a link & makes a list. When it moves to a new link, it creates a new list. If the lists are disjoint, then its on a new link. Only RA is needed for movement detection.

    someone 4: ???
    ans: there is a kind of hint, then you need a trigger to start DNA process.

    greg explains mechanism better.

    Keith Moore: (paraphrased) thinks the mechanism is broken, if you see some of the same set of prefixes on multiple links, then you have different links. You actually can have the same prefix advertised on two links. Links can be bridged.

    JinHyeock Choi: If two links are bridged, then we consider it one L3 link-- even if this L3 link consists of two L2 links. (For a definition of L2 links and L3 links, see DNA documents and mailing-list discussions.)

    Keith Moore: A prefix may move from one link to another. This is an example (though a rare one) of where the prefix is not necessarily tied to one link.

    Keith Moore: Its hazardous that if you see one of the same prefixes, then you think two links are the same.
    Keith Moore: (paraphrased) some discussion on this, thinks you need to have some explicit mechanism to do effectively

    Samita Chakrabati: We have an implementation of this on the wired network.

    Keith Moore: thinks this is not reasonable assumption

    Pekka Nikander: draft should cover Keith's scenario
    Keith Moore: thinks it is reasonable that the group looks into the problem, but not that the problem is solved

    WG document? We want to facilitate its adoption to existing Mobile IPv6 code.

    Kent Leung: (paraphrased): didn't read the draft. What's different from Mobile IPv6 movement detection?
    JinHyeock Choi: Mobile IPv6 uses three RA's separated by one second to check whether an old router is still available. This takes three seconds. CPL is much faster.

    someone 4: How long do you need to watch?

    JinHyeock Choi:
    look for 2 RA's on a link

    Pekka Nikander: How may people are willing to read the document and make comments before we recommend the document to the IESG? -- 10 or some more.

    ==> Accepted as WG doc.

    - 20 min DNA hosts bcp draft, with discussion
    Sathya Narayanan

    issues presented

    Question (from author): The draft makes the assumption that a mobile node, when it returns to a previous link within the DAD complete time, it may claim the previous IP address by sending a NA. Is this alright? (Discussion delegated to the mailing list.)

    Pekka Nikander: We are chartered to produce a document that describes what you can do with the current protocols. In Washington, we decided that we would do two documents -- what you can do as a host, and what you can do as a router.
    The question is whether this draft can be used as a starting point for a WG document ?
    How many people would be willing to review the document? -- 5 people.
    ==> Enough, but we will need all of these five. (Adopted)

    - 20 min DNA routers bcp draft, with discussion
    Sathya Narayanan

    issues presented.

    Pekka Nikander: we are chartered to create a bcp on what to do with existing protocols. How many are interested in on working on this? about 4 hands, so we will work on this.

    - 5 min dt update
    Brett Pentland

    The design team consists of JinHyeock Choi, Tero Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark, and Brett Pentland.

    Now its time to think whether there is something that we forgot and that needs to be put into the design draft.

    Comment from the audience: I think that the assumptions that routers on the same link can hear each other is valid.

    Brett Pentland: That's probably one thing that needs to be further discussed.

    Two basic problems

    - checking for a link change
    - getting the RA fast
    First can be achieved by means of a link ID that is put into RA's.
    Second could be Fast Router Discovery.

    Design team has produced a discusssion document that talks about the advantages and disadvantages of different approaches. And we still need more discussion on everthing.

    Someone: doesn't think that routers on a link can hear each other is not a good assumption.
    Someone: question if one solution is reasonable.

    ans: design team said that this is a possibility, but just a suggestion.

    JinHyeock Choi: clarify the concept link in document.

    Question to the audience: Where to go?

    Pekka Nikander: Defer all technical questions to Thursday. If you have a non-technical questions, go ahead.

    8. Conclusion

    Thursday's session will focus on draft-dnadt-dna-discussion-00. Folks are hence encouraged to read the document and discuss it with design team members.

    The design team has identified a large number of options, and the goal is to eliminate some of these options. It would be good if you read the design-team document critically and make comments, so that we can eliminate some of the current options.

    DNA Working Group Meeting
    March 7, 2005, 15:30pm to 17:30pm
    IETF 62, Minneapolis

    CHAIRS: Greg Daley <greg.daley@eng.monash.edu.au>
    Pekka Nikander <pekka.nikander@nomadiclab.com>

    Minute Takers: Pekka Niknder (??)


    DNA discussion 05-03-10
    Presentation by Bret Pettland
    Clarifying questions:
    Are you assuming every router can hear
    Shared media like Ethernet There are other cases, such as access routers connected through ppp or similar to an access point.

    JinHyeock Choi:
    We are assuming any two access routers in the same link can hear each other
    This link definition is different from what I know
    Equivalent to Broadcast domains. Multicast should be received by all nodes including routers.
    There is this assumption?
    Brett Pentland:
    Erik Nordmark:
    Assumption is that if somebody sends a packet to the all hosts multicast address then all nodes in the link will receive it. If you think of IPv4 you would call it subnet. In IPv6 you call it link. If for somereason people do link partition.
    Brett Pentland: definition in 2461
    The access routers connected to the same access point switch point-to-point connection. These form a subnet. But the access routers don't hear each other.

    Erik Nordmark:
    Then you have two links that happen to share the same access points. Must be differentiated by the link layer or otherwise it doesn't work. You articifically partition it. There are choices when you want to have two separate link but you have to carry it out with VLAN tags or SSID or whatever you want it to be.

    Weeding out discussion

    X: basestation includes a beacon. Isn't it sufficient?
    Brett Pentland: If it is viable, maybe?
    JinHyeock Choi:
    Link identifier is not SSID.
    Greg Daley:
    Beacon's don't have enough information to identify links
    Potential security holes in Explicit link ID? Someone could explicitly block.
    Brett Pentland:
    A rogue node could come along and change the link ID.
    Greg Daley:
    Brett Pentland:
    Vulnerabilities in all if you are not using SEND. Must be considered.
    Erik Nordmark:
    These has been discussed in the design team extensively but not written down, may make it hard for outsiders to understand better.
    Greg Daley:
    Implemented two of the ideas: probabilistic and hash ordered RA. There is some experience within the working group
    Vijay Devarapalli:
    Nice to have implementation experience. Get feedback from MIPv6 working group.
    Brett Pentland:
    Get written down.
    Erik Nordmark:
    Get feedback from Ipv6 working group. Understand the combinations hard?
    Vijay Devarapalli:
    12 combinations is too many to give feedback.
    James Kempf:
    Make JinHyeock's draft (fast ra discovery) WG informational. Proposal to 802.21, we can't really do it in the IETF. Lots of issues with different link layers. Reduce the number of proposals at the WG.
    Suresh Krishnan:
    Brett Pentland:
    Collect the set of prefixes?
    Erik Nordmark:
    You need to have a link detection mechanism and a fast advertisement things
    Suresh Krishnan:
    Some are not really combinaritorical Only 8 combinations, leave fast RA out.
    Sathya Narayanan:
    Landmark is an option. Do you want. Only 6 independent combinations Whether you add something on RA on RS. Orthogonal. Benefits from both RA and RS side. If you do that you are down to three.
    Suresh Krishnan:
    Not that many combinations. We can decide.
    Greg Daley:
    Helpful if I posted code?
    Charlie Chef, Motorola:
    Tremendous disconnection between 802.21 and DNA. Very marchy handcap here. We assume that there is very little information here. In 802.21 looking for techical solutions, still all individual prosals. 20 some proposed. Not all of them will become supported. Way beyond what we assume here. If we assume even a small fraction of those would tremendously simplify. Coordination. More informed assumptions
    Greg (chairing):
    Good comment. .21 will simplify things thing tremendously, if you have got .21 interfaces on the network/host side. Not every device or network will have .21 interfaces. We want to follow it closesly, feed requirements to .21. Very much interested in collaborating.
    Charlie Perkins:
    Been involved. Only value if being used. User for .21 is IETF.
    Greg Daley:
    At this time it is important what we are actually using. Other groups have other requirements. If we had triggers available, mechanisms for identifying links. Will revisit this, separate document that follows that.
    Charlie Perkins:
    Put together here a wish list.
    Greg Daley:
    Be careful here. (don't want to tell other SDOs things we don't want)
    Erik Nordmark:
    Will .21 carry layer 3 information
    Greg Daley:

    James Kempf:
    Way that .21 works today. No connection between L2 and L3. Maybe some time when .21 is completed it may change. ESS. .21 is not chartered for intra-ESS handovers.
    John Loughney:
    DT document rough going. Move things that should be remove to an annex. Provide main body additional information, maybe actual code, experiments. Would be good to see.
    Greg Daley:
    My experiments not done yet. Minor variations to be. Nail down if there are any protocol issues. If we need to specify behaviour changes.
    Greg (next steps):
    New version of the design team document. Additional information. Next few weeks. Read it again. Might be shorter to read next time. Good idea: 10 hands. Not sufficient?
    Erik Nordmark:
    More information about the proposals that don't have indivudal drafts. Make very short drafts of the right side. Example that could be put into the design team document.
    Vijay Devarapalli:
    More detailed specs of each one of the ones on plate. Weed out if we don't get them. Plans to experiment some of these.
    Greg Daley:
    Would be nice to know soon. Good to have as individual submissions.
    Vijay Devarapalli:
    Detailed enough?
    Greg Daley:
    Promised to implement afterwards
    Suresh Krishnan:
    IPR considerations needed.
    Greg Daley:
    Must be careful. (BCP 79 referencing)
    Erik Nordmark:
    Rules are there for arhived stuff like RFCs.
    Greg Daley:
    Could have a note with an RFC editor note.
    Brett Pentland:
    DT document designes basic concepts. More detail needed.
    Erik Nordmark:
    Maybe the design team could settle with 2 ways, one ipr one without. A possibility.
    Sathya Narayanan:
    Some consensus on one and a little bit of controversy.
    Erik Nordmark:
    That doesn't stop the WG from saying that we don't like.
    James Kempf:
    Do two documents. Implement. Measure. Have a comparison.
    JinHyeock Choi:
    Do something with IPR if clear technical advance.
    Greg (personal):
    I will supply test results wrt. main perfomance, delay, packet loss levels. Provide at the mailing list.
    Greg Daley:
    Clear way ahead with DT, clear enough to implement. Will remain individual submissions.
    Sense of room: Useful to record the DT considerations: 10 hands, no: no hands
    DNA solutions framework: Not to loose the MLD and DAD stuff
    James Kempf:
    Probably be BCP?
    Erik Nordmark:
    Changes protocol behaviour even though.
    Greg Daley:
    Could go to the exiting mile stone. Discuss on the list.
    JinHyeock Choi:
    Also applies to solutions?
    Greg Daley:
    Solutions will probably refer to the BCPs.
    Erik Nordmark:
    Willing to update
    Greg Daley:
    Some to move to host BCP?
    Erik Nordmark:
    Host BCP stuff that someone wants to implement in one place. Some DNA and other things there.
    Greg Daley:
    Update the framework. Text to move to BCP, ask on the mailing list. Don't want to loose the information. Design team considerations: Brett and Sathya will collect.



    None received.