2.3.3 Detecting Network Attachment (dna)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-11-01

Chair(s):

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
technologies.

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

Documents

    * Define goals for detecting network attachment in IPv6
          (Informational).

    * 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
        (Informational).

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.

Internet-Drafts:

  • draft-ietf-dna-goals-03.txt
  • draft-ietf-dna-link-information-00.txt

    No Request For Comments

    Current Meeting Report

    IETF-61 DNA WG minutes

    Detecting IPv6 Network Attachment (DNA) Working Group

    These are the minutes for the Detecting IPv6 Network Attachement (DNA) working group meeting, held at the 61st IETF meeting on Monday, November 8, 2004, at Hilton Washington. Thanks to Michael Richardson and James Kempf, for the notes, on which these minutes are based on.

    Presentations and Discussion

    Agenda and Document status

    The DNA goals draft had been submitted to the IESG for consideration to be published as an Informational RFC. The chairs expressed their thanks to the editor, JinHeyock Choi, for his hard work. For the other documents, see the explicit presentations below

    Link Layer Events and Notifications for DNA

    Eric Nejdjou gave a presentation about the DNA link indications draft. Currently the draft covers only a few different link technologies, and it was decided already in the previous meeting to add coverage for new technologies.

    One particular confusing area appears to be in connection to using PPP and GPRS. In particular, for the final end-host (like a laptop) the actual IP link appears as a PPP link, not as a GPRS link. Hence, in that scenario the "link up" event is generated when NCP concludes. The situation is somehwat different when ther eis no PPP link, e.g. when a 3GPP handset is directly communicating using IP. There are also differences in address assignment in PPP, and this seems to be confusing people.

    Bernard Aboba:
    Are you proposing a new IP address assignment mechanisms, delivering the IPv6 address directly from the PDP context, i.e., without router adverticements.
    Hesham Soliman:
    No. When PPP is not used, the RA/RS gives you the address, but PPP gives it when it is used.
    Greg Daley:
    In the IPv6 case, PPP does not deliver the address. It just hands over a unique interface identifier token, which can be used to construct a link local IP address.
    Bernard Aboba:
    From the application point of view, that is not a link up event. You don't have a globally routable IP address.
    Pekka Nikander:
    The link is up for IP, not for apps. These are two different events.
    Bernard Aboba:
    The draft does not make this clear. There is lack of clarity on how IPv6 address assignment works in this case.
    Erik Nordmark:
    The situation is similar when running IPv6 over ethernet. There is a difference between the event when the link is up for IP and when it is ready for apps.

    (Some more discussion about IPv6 address assignment; the editor couldn't make sense about the notes.)

    Rajeev Koodli:
    Look at som 3GPP2 proposals, they have something on this.
    Hesham Soliman:
    If you can't get an IP address directly from PPP, then this is a large problem, not just 3GPP.
    Pete McCann:
    3GPP2 still runs RS/RA, they use PPCP to get the interface identifier only.
    Pekka Nikander (chairing):
    There seems to be some serious problems in the draft, maybe already in the introduction. It looks like that we need more people working on the draft to get this right.
    Eric Nejdjou:
    Applications never need to interpret link events.
    Greg Daley (chairing):
    Let's take this to the list.
    Greg Daley (chairing):
    Should we add a section on 802.16 link hints? Are there any commercial interest on this?
    James Kempf
    No, we shouldn't touch 802.16 yet. The 802.16 mobility features are not mature enough yet. We shoudld wait until it has been cleaned up.
    Ralph Droms:
    Let's wait until IEEE gets the document in order.
    Greg Daley (chairing):
    How about 802.3 then? We definitely should have a section on that. Any volunteers?

    Editor's note: No volunteers during the face-to-face meeting, but one was found afterwards.

    Best Current Practice (BCP) drafts

    Sathya Narayanan gave a presentation about a draft proposed as a baseline for the WG BCP draft.

    JinHyeock Choi:
    Why so much emphasis on bi-directional reachability? Partial connectivity is enough.
    Speaker:
    If you can easily check bi-directional reachability, why not? I agree that partial reachability works, but it is much harder to check for it. You need to check the reachability of the current default router anyway; that is part of what you just have to do. Hence, why just not do it?
    Erik Nordmark:
    Do you check the reachability of all last hop routers, e.g., the all 17 of them?
    Speaker:
    Do you mean that we need partial reachability with all of them in order to perform DNA?
    Erik Nordmark:
    According to RFC 2461, some connections may go out over some routers, other on others.
    Greg Daley:
    "Before proceeding" set NC state to "stale". May take 8 seconds.
    Eric Njedjou (?)
    After you have decided or when probably moved?
    Greg Daley:
    It might still be the same link. If you have an AP that says you've received an RA, that doesn't guarantee that you can send something up through the router, may be discontinuous.
    Eric Njedjou (?)
    The issue is to detect if you are moving at all? To detect if you are on a new network or the same. Or is it that wireless behaves differently?
    Greg Daley:
    Different link layers may have different failure characteristics.
    Jinheyock Choi:
    Sure it would be nice to perform bi-directional reachability checks, but not right as a part of the DNA.
    Hesham Soliman:
    Are we trying to detect if we are on a new link or if the IP configuration is still okay?
    Greg Daley:
    Yes (laughter).
    Hesham Soliman:
    These are two different types of actions. The question is when to send an RS.
    Greg Daley:
    That will be covered in additional recommendations.
    Jinheyock Choi:
    Is DNA by check for link change or by IP config change?
    Speaker:
    It is not a clear either-or. It could be based on explicit link od, or address validation, or default router.
    Vijay Depravalli:
    The default router's adverticements may not include all the prefixes.
    Greg Daley:
    We need to define what is the best practice for router configuration. For example, if it helps to have overlapping prefixes advertised by different routers on the link, we should define it.
    Speaker:
    Define the Best Current Practice, within the current standards. Follow these procedures and things will get better. For example, what is the preferred timer ranges. How about recommending a subset of the existing range.
    Hesham Soliman
    There is no real current practice here. Buf if we recommend something, it depends on the context in which say that. For example, if we want to have short beacons, the prefixes should be sent once. Hence, the recommendations will necessarily have some context dependencies.
    Pekka Nikander (chairing)
    We should remember that one of the primary reasons for the DNA WG to exist is that it is hard to detect link change and update the configuration within the current standards. Remember that we have also the solutions work, which is separate from this BCP work.
    Greg Daley:
    The intention is that the hosts are able to work in any access network, regardless of whether or not the networks have the tweaks.
    Pekka Nikander:
    If we suggest something for the routers, we have to remember that many people won't do it, i.e., they will not tweak the parameters to get better performance. Rather we might want to focus more on the host side; how to get reasonable results there.
    James Kempf:
    We should also include advice for network designers, how to lay out their networks, too.
    Pekka Nikander:
    Right, mostly host but also network.
    Christian Huitema:
    We should tell the network managers about the consequences, i.e., identify the tredoffs in configuration. That is, you can do various things, but if you do, you may gain flexibility but make roaming more difficult.
    Erik Nordmark:
    This sounds like two BCPs. One for host implementors, telling them how to make the hosts to behave better however the routers are configured. The other one on how one would configure a router, network, etc.

    (Sens of the room on two drafts, majority favouring)

    Rajeev Koodli:
    Do you need two separate documents?
    Vijay Depravalli:
    Are we describing what is out there, or recommending a solution?
    Greg Daley:
    An example is CPL, which is a good idea in certain situations. We want to illustrate tradeoffs and certain configurations within the boundaries of the existing protocols.
    Vijay Depravalli:
    If recommending configuration, couldn't that involve both the mobile node and the router. Hence, shouldn't we just have one document?
    Erik Nordmark:
    If the document is split, then one half will not delay the other, since the review communities are very different.
    Hesham Soliman:
    There is likely to be dependencies between host recommendations and route recommendations.
    Pekak Nikander:
    The CPL work should go into the host document.
    Jinheyock Choi:
    The discussion about CPL is more fruitful after the CPL presentation. The slide is misleading.
    Pekka Nikander:
    I think we need a separate document focusing on hosts, maybe build around the CPL work.

    Erik Nordmark gave a brief presentation about the current status of the CPL work.

    Solutions framework

    JinHeyock Choi gave a presentation about the solutions framework document.

    Greg Daley:
    Should we make this a working group document? We might merge this with the eventual solution.
    Pekka Nikander:
    Should we adopt this, run a quick last call, and submit to the IESG for informational?
    Vijay Depravalli:
    What if the outlined solution does not work; shouldn't we have a link identifier draft first?
    Pekka Nikander:
    If it turns out that the outlined solution does not work, we can change the RFC status to historical.
    Vijay Depravalli:
    Shouldn't this rather be a document that you take through with an implementation?
    Greg Daley:
    We have various options.
    Erik Nordmark:
    There is some issue with interactions with the IPv6 WG, optimistic DAD. Maybe we should send a message to them that we expect them to do something.
    Greg Daley:
    The IPv6 WG is proceeding with Opti-DAD. Our solutions are not that advanced. The tentative link layer address is not yet baked.
    Sathya Narayanan:
    Should we accept this as a WG item or not?
    Pekka Nikander (chairing):
    Two questions:
    • Should we accept this as a WG item or not?
    • Should we proceed quickly with this?

    Consensus in the room to adopt the document as a WG item.

    Sathya Narayanan:
    Let's make a compromise, not submit it immediately, but wait until the solutions work is halfway done.
    Samita Chakrabarti:
    The document discusses several solutions in a framework. Is the purpose is to describe a framework for different solutions in different cases, or requirements?
    Pekka Nikander:
    We should think about this as a framework for thought, something that we can use when thinking about solutions. The aim is to standardise a single solution in the end. There are possibilities in this document.

    Individual solutions discussion

    Chairs:
    The plan is to set up a design team of people tha thave worked on the solutions. The design team then should come up with a single solution.

    Greg Daley gave a brief presentation about Fast Router Discovery with RA caching, basically nothing that the proposal crosses layers 2 and 3, and enters a grey area for the IETF. The access points are modified. It does not modify packet formats.

    Hesham Soliman:
    This is applicable only if the access point is separated from the access router, and there is no protocol to inform the access router about entering hosts.
    Jinheyock Choi:
    Some link layers won't need this.
    Greg Daley:
    It is trivial to include this kind of functionality if you have a single access router acting also as the access point.
    Hesham Soliman:
    The RA is sent by the MAC layer here. I see this applicable only to WLAN where the AP is separate from the router.
    Erik Nordmark:
    The generalized technique applies always, also when L2 and L3 are combined.
    Vijay Depravalli:
    We want to make sure that the AP cahces the most recent RAs. The AP needs to check every packet to see if its IPv6, if the destination address is multicast etc.

    (Presentation continues)

    Chairs:
    We recommed continuing this work as experimental, either within our outside of the working group.
    Rajeev Koodli:
    So, you cache new router RA on AP. What about SEND, RA/RS, grey area, could attach to rogue AP, to what do you point?
    Greg Daley:
    If SEND is used, you can't accept RA until you have checked authorization. That would require addtional exchange anyway.
    Rajeev Koodli:
    We have to consider the host and ARw security.
    Hesham Soliman:
    No strong disagreement to move forward, but limited applicability. There is the danger of replay attack, no strong need. This needs a strong applicability statement.
    Sathya Narayanan:
    If you have multiple rotuers, how do you make choice about which RA to send?
    Greg Daley:
    That is not clear.
    Jinheyock Choi:
    When a host makes a new connection, l2 knows, l3 doesn't. AP or base station initiates RA earliest possible time. AP in 802.11 specific case.
    Rajeev Koodli:
    Many APs today are capable of doing some IP stuff.
    Chairs:
    We propose experimental. Should we proceed within the working group or as individual work. Anybody interested.

    Only one hand in addition to the authors.

    Chairs:
    Continue as individual draft, but solicit people to do external review.

    Greg Daley gave a brief presentation about Deterministic Fast Router Advertisement Configuration.

    Brett Petland gave a brief presentation about Router Advertisement Link Identifiers.

    Pekka Nikander:
    Have hash of all prefixes of link?
    Speaker:
    Was considered, too complex, need to keep track of all prefixes on link, need to detect and change link id.
    Greg Daley:
    Tradeoff between large unique number or something that only has local unique properties.
    Speaker:
    Simpler to pick a large random number. More overhead though.
    Erik Nordmark:
    First, a prefix option with no other flag set has no semantics. The host only acts when one or more flag bits are set. One possibility is to advertise a prefix for the purpose of being a link id, with no other bits set. Second, we have to consider how long it takes for a link id to experire and how long does it take for one to travel. You travel around world w. laptop suspended. How long is the travel time and how long is the expiry time? The host will forget. Limit times when collisions occur. How bad is it?
    Erik Nordmark:
    NC goes to stale. One of addresses may have a preferred lifetime, move, get another prefix, think old prefix is valid because lifetime hasn't expired.
    Tony Hain:
    Any concept using prefixes is wrong, prefix will change, don't want link id to change when prefix changes. 48 bits, local prefix. Use 64 bits to pad. Global ids won't work.

    Sathya Narayanan gave a presentation about Router Reachability Detection.

    Greg Daley:
    Failings of DRA is that some hosts will pick up same router, change which responds fastest, all routers know which order to respond, router to respond first, others delay around list. If router not part of list, DRA rules. If not in list, then sent quickly.
    Erik Nordmark:
    Does this draft propose that all routers agree what designated prefix is?
    Speaker:
    No.
    Erik Nordmark:
    Used router and prefix. Are they still there?
    Speaker:
    Yes. Two different hosts have two different ids.

    (Some discussion missed.)

    Sathya Narayanan gave a presentation comparing the approaches.

    Summary

    1. The Link ID draft apparently needs more work.
    2. Aim for two BCPs, one for hosts, one for network configuration.
    3. Adopt the solutions framework as a WG draft. No consensus on the pace of going foward, discuss this on the list. Does not restrict the design team work.
    4. RA caching as individual experimental until more interest.
      Jinheyock Choi:
      The chairs did not ask author, chairs did not mention presentation to him beforhand.
      It appears that there were communication problems between the author and the chairs, and therefore this decision was decided to be made void and to be reconsidered on the mailing list.
    5. The chairs will form a design team that will consider the various solutions drafts, with the goal of coming up with a proposal of how to go foward at the next IETF meeting.

    Consensus call on forming a DT; about 20 hands in favour, no one objecting.


    Slides

    Agenda
    Link Layer Events Notifications for Detecting Network Attachments
    Detecting Network Attachment Best Current Practices
    DNA with unmodified routers: Prefix List based approach
    DNA solution framework
    Fast Router Discovery with RA Caching
    Deterministic Fast Router Advertisement Configuration
    Router Advertisement Link Identifiers (LinkID)
    Detecting Network Attachment Router Reachability Detection
    Detecting Network Attachment Comparison of proposed solutions