2.3.2 Detecting Network Attachment (dna)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-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 technologies.

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


* 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:
Aug 04  Submit to IESG Goals for Detecting Network Attachment in IPv6
Aug 04  Submit to IESG Recommendations for Detecting Network Attachment in IPv6
Aug 04  Submit to IESG Existing Link Layer Hints Catalogue
Dec 04  Submit to IESG Protocol Enhancements for Detecting Network Attachment in IPv6
Feb 05  Close or Re-charter WG.
  • - draft-ietf-dna-goals-00.txt
  • No Request For Comments

    Current Meeting Report

    DNA Working Group
    Agenda bashing Complete
    JinHyeock Choi talking

    Clarified term link in the draft

    Link & Attachment Point slides - with 3 ARs. But only 2 links (AR2 + 3 share a link)
    When MN moves from 2->3, it remains at the same link.

    Mentioned that Jim Bound says "DNA in Existing IPv6 Systems" might not be appropriate here, might be moved to a separate draft.

    Actual configuration is outside DNA scope

    DNA Problems - Difficult to represent link identity, ambiguity of RA information, delay to check reachability of AR

    Goals list (6 goals).
    #1 - dna scheme should detect identity of current link to ascertain the validity of existing IP config. should recognize whether link change has occurred and initiate acquiring new config if necessary.

    Goals.. 7-11

    Greg Daley - Issue #7 (neighbor discovery)

    JH- We can talk about that in the Issues List presentation. Issue List slide- Jim bound proposes parts of inappropriate analysis to be removed and put in sep. draft

    JB suggested to remove the second part of abstract..(...more proposals from JB, on slide)

    Greg Daley says he will put issues list up on the web, so we can discuss and track changes

    Any other comments?

    Vijay D. - compatibility w/ IPsec and send - nice to have, or don't need it initially?

    GD - SEND is like, if you have it you must use it. I like SEND but it's not going to get deployed everywhere. We have to be aware of DNA interactions from SEND to non-SEND solution

    Vijay - for us to pick an impl. - how critical is it?

    Jari A. - SEND should not break DNA, and vice-versa. I asked about IPsec because...

    Erik N - Jim Bound's comment means we can have a goals draft that is much shorter. Mostly just the prob. stmt, plus list of goals, or should we have something that explains a lot more? That's the fundamental question.

    The other things are useful IMHO, but might not be in the goals draft.

    GD - What do ppl think about that? Should we give an overall motivation, but not details of individual hurdles to tackle?

    Does that sound good, or should we have goals and requirements in same document?

    #1 - about 12
    #2 (more info about challenges/"opportunities" in goals doc?) about 8/9.

    We will have to get back to you about proposal for shortened version, and discuss it further on the list.

    (from GD)

    JH - I would like WG to clearly accept it... (GD - we go to list on that)
    JinHyeock - correct spelling

    Carl W. not here, we'll skip to L2 Hints draft with Alper

    GF - can we get into this without the link trigger and link hint thing?
    Alper - What do you mean, that's the whole point?
    Alper - Since last IETF, the draft hasn't changed. It got reviews from Bernard Aboba and Greg Daley, but we would like more reviews.

    Highlight of comments - both reviewers agreed that link-layer details are a little too much. We agree to reduce them just based on subject
    Terminology and associated semantics received a lot of debate, and that's the topic of this presentation. We want to catalog use for link layer information, but not say how they will be used by DNA -- that's the subject for solution specifications.
    Last ietf we proposed use for triggers and hints. Trigger term is extremely overloaded. Hints seems a little too dna solution specific.

    New proposal - use terms Link-layer event notification, and Associated information (optional).

    LLEN - link up, link down. Just indicate event that took place in the link layer.

    Associated with that is optional information, BSSID/SSID, IP address if obtained..

    Can be delivered along with the notification.

    This is the view as the information passes from the link layer to the network layer, not as it's interpreted by consumer (DNA).

    LLEN might look like a hint to the user.

    We want to create a draft that will be useful for DNA, but be useable later without binding into semantics of DNA-specific terms

    Want feedback on this key issue

    GD - Does anyone have opinions about this so far?

    Charlie - That's not the only kind of LLEN?

    GD - yes... we are avoiding other ones we can't make use of in DNA

    TJ - so how's it different than a trigger?

    GD - doesn't use trigger word

    Alper - Along with PPP establishment, we get an IP address....

    Vijay - (too fast)

    Talking about IPv6, don't get address . With PDP context you get it

    Erik - for IPv6 (PPP) you would want to send up token Currently draft handles 802.11, cdma2000, GPRS by 802.11, doesn't it mean you handle 802.3 (subset)?

    GD - Individual link types are useful at this stage. We could extract LLEN later. We are asked to catalog them, but we can't do an exhaustive one.

    EN - But I want DNA to work on top of ethernet.
    Alper - Current details are specific to 802.11 - we should have separate text for 802.3

    GD - It would be nice to see it as a complete document before we go to making it a WG document?

    Vijay - What's the goal?

    GD - Little information about LL indications within IETF. We want to
    use them fairly uniformly for DNA.

    Vijay - with these 3 examples, each one is very different

    GD - yes but they can send generic IP frames over them once you get to a certain stage in connectivity?
    GD - is this useful to make this WG informational when we see the next version of the draft?
    GD - JH mentioned that link is another overloaded term.

    JinHyeock - presenting on disambiguating meaning of link.

    Link / Attachment Point. But People ask me what is a link. So we have a new term, we should fix it and clearly announce it.

    GD - Terminology document (indiv submission) where people have been capturing these terms Has anyone got an idea for what we can use instead of link?

    JH - Link segment

    Erik - Ethernet segment is different

    GD - Well it's something that isn't bridged.

    Erik - If you do mobility by moving ethernet cable, you might move from one switch point to another, or from one hub to another hub..which would be the same segment. So we need to have some scope for using the term as well. We have "point of attachment" as well You should at least make them be consistent

    GD - how about if we match terminology from DNAv4 w.r.t point of attachment. It would replace the term link. (?) Isn't it about point of presence, not point of attachment?
    - Darwin
    GD - I like that idea, if we consider that IP address is tied to the fixed network and implies a presence.

    JH - we have a problem, WG understands. we can fix it later

    Samita -why don't we define the term at the beginning of the document?

    JH - It doesn't keep people from asking me questions.

    GD - We do have a problem and will talk about it on the list leading up to Friday.

    We shouldn't get confused between link layer and link-local.
    I like the point of presence term.
    Please explicitly state if you're confused

    (Greg D. and Jari A. raised hands)
    GD - that was basically what Carl was going to discuss.

    Erik Nordmark now giving presentation on DNA solution framework.

    This is what our opinions on a reasonable way to put pieces needed for DNA, and what are the actual pieces needed. This is the same terminology JH was using a couple minutes ago. Important to detect whether you're on the same link, or a different link..and then use that to figure out the rest.

    You don't seperately change -- if the router's reachable, have the prefixes changed, etc.

    If it's the same, you can keep all the information you had before. We already have the mechanisms in ND and elsewhere, deal with dynamic nature (routers die, prefixes renumber), as long as you're on the same link.

    Could be link up notification, router advertisement with surprising prefix, etc.

    Receive a RtAdv as soon as possible. You want it to contain enough info so u can determine if you're on the same link, and if you are on a new link, you can configure the things you need immediately.

    Draft calls this RA optimized for DNA

    Most general is that host, when it receives hint, sends RS as soon as possible when AP notices new host, it can send most recently cached RA

    Determines if it's on the same link before, if no, uses RA to configure new parameters.

    So we need notion of what identifies the link. The identity of link could be all global prefixes assigned to link.

    If you come somewhere and you have a different set, it's a different link.

    It could be a new router advertising a new prefix, but you're on the same link. So in some cases you need multiple RAs to tell with reasonable probability

    Vijay - there was some discussion about checking for reachability of router you were using

    Erik - doesn't fit in with this view of the world. Single router can have same LL addr on multiple interfaces

    TJ - some question about how you really tell it's a different link.. If you have MAC address and layer 3, you can .....

    Erik - if you continue using an address on another interface, the response might not come back to you -- it will go to the other interface.

    We'll talk more about this on Friday.

    You can explore an explicit link ID option so that with modified RA, we can tell if we're on the same link

    There's some interaction with things in other WGs like DAD When you get a hint you might have moved, what should you do with DAD?

    Too early to send DAD -- you might be at the same place. But if you have moved and might have a duplicate, you don't want to disrupt owner of that addr.

    Treating addresses as tentative after you get a hint might be a good approach.
    RS would have Temporary Source Link Local Address O. draft

    Work needed - link identifier option, complete prefix list when LI is not available, single RA as quickly as possible, ideally with no delay beyond propogation.

    Optionally, ability to have access points at the other end of the "L2" connection

    Pieces related to DAD - if you moved you need to make sure you join multicast addr on new link as well. There is an ordering because some multicasts are needed to do DAD

    GD - Who thought that things were clearer having solution framework presentation.

    Who read draft? about 8. Who thinks it's useful (all).

    Erik - States certain directions about what solution should look like, at a high level

    GD - If you have reviews of that doc, we'll be able to discuss and improve WG's idea of that solution space as well.

    Pascal - For link up, seems visitors are able to move, but routers are not able to move.

    GD - routers are able to move, because it will appear there will be relative movement.
    Pascal - If there is shared media, and some routers may pop up and expose a prefix and then go...I'm not interested in knowing if it's the same line, but rather if the router is still available from the same link.

    If the shared media is there, but the router that's there has now gone, it's different

    EN - In ND, you have a link and there's a set of prefixes and routers, but there's no relationship between them.

    Prefixes don't matter in terms of what router you use for sending packets.
    If a router has a prefix only it can route to/from, and another router has prefix it can route to/from, it won't work because of architecture in ND and elsewhere in v6

    Pascal - so I can't come in with a router and expose prefix

    Erik - fund. problem, when you deploy it, R1 belongs to ISP1 and R2 belongs to ISP2, there's ingress filtering.

    So if you use COA1 with R2, packets will be ingress filtered.

    Erik - in 802.11, could I run separate VLANs and have that as a mechanism

    Vijay - NEMO says that MRs when they're not at home can't send RAs on egress interface. and When they're at home, must send lifetime as 0 so other nodes can't configure

    TJ - depends on concept of link -- might not be an advertisement when a router, with certain prefixes, goes off a "link"

    pascal - ingress interface of MR ....

    Erik - but that's not IPv6 as currently defined in current set of RFCs (Erik N. shows IPv6 host moving by waving his laptop around)

    GD - It's interesting, but may not be relevant

    There is some implication that ND infrastructure is there as in RFC2461. Might mean fixed wireless BS, might not.

    Wassim Haddad Taking minutes.

    JinHyeock Choi (Choi) is presenting....
    - Renumbering
    - Incomplete prefix list
    - Superflous prefix list
    -> Pascal: What the cost if we cannot know for sure that we've moved or not. in case of LMM, the cost is close to 0 also we are doing DNA and we are changing the ... basically we are constraining its behavior
    -> Suresh: Something is missing: how to be with multi-homed host or a host with two interfaces on the link. Do you need to start signaling again?
    -> Choi: We assume that if you have 3 interfaces then it is not covered!
    -> Greg: It is possible to do explicit signaling if you have time
    -> Nick: ...
    -> Pascal: I don't agree. Loosing the default gateway is loosing the default router...
    -> Erik: One comment: Pascal says it may take 40 seconds, the worst case is RA takes 3.5 second. It depends if you are talking about average or default case.
    -> Nick: Another issue is dealing with mobility
    -> Pascal: The key thing here is to have a hint.

    New Presentation Sathya Narayanan.
    Detecting Network Attachment

    - Current Practice for DNA
    - DNA Initiation
    - Validation of configuration
    - Reachability detection
    - Special cases in each of the topics
    - Analysis
    - Security Considerations
    -> Erik: If you're host what do you recommend to implement DNA?
    -> Nick: It should be specified what to do when you get a new attachment. How optimistic it would be if you get a trigger?
    -> Pascal: ...
    -> Greg: We make no mention of optimistic DAD.
    -> Choi:
    -> Greg: ask for consensus: does this look like an acceptable way forward for this document (the presented structure)
    Answer: OK.
    -> Greg: let's leave the details to BCP.

    Greg presenting
    Link Identifiers
    - Identifiers which aim to unambiguously represent a link.
    - Link identifiers (not identity)
    - Suggest include in router discovery messages
    - critical that adjacent links have different identifiers (and identity).

    Why would you use LinkIDs?

    - Check if link change has occured with a "single" RA?
    - Receive Router Advertisement, determine if Link IDs match
    - Difference with known ID implies that router believes is a different link
    - Unless ID changes

    World without Explicit Link IDs
    - RFC 2461 allows incompatible advertisement of routing info
    - Not all routers will know or care about LinkIDs
    - Mixed 2461/LinkID

    -> Pascal: if you say that then you lose the detection that comes from that link.
    -> Greg: What I am trying to say is not to cripple link IDs because they are transition cases that we cannot ignore. Don't want to do anything dangerous!

    What type of Link Identifiers is useful?
    - Globally unique vs Locally unique
    - May be an address or prefix on the link
    - Size may matter; Prefixes are bigger
    - Changes to identifier's uniqueness or allocation need to be...

    -> Pascal: This case is
    -> Greg: you need to change local unique ID. We can have disjoint prefixes
    -> Nick: Collision?
    -> Greg: For a network with 10000 neighbours there's about 1% chance of collision.
    -> Christian: a malicious node who can spoof the router is out of the scope of this document?
    -> Greg: yes it is, we assume that we can use SEND. What if you have SEND and Non SEND router?
    -> Nick: this would be covered in the security considerations
    -> Christian: Would it make sense to consider the RTT to do a trade-off in order to decide if/when to do the move?
    -> Choi: We thought about whether a host is having a session or not.

    -> Greg: We done????

    Choi's Presentation: RA Caching/Fast Router Discovery

    Draft suggests a way to send a host an RA with minimal latency upon
    network attachment
    -> Pascal: How does it work. Does the RA get modified by the AP?
    -> Greg: the idea is not to modify the RA but to select the best
    -> Pascal: ...

    - RA Caching Operation
    -> Unknown:
    -> Choi: This works between L2 and L3
    -> Unknown: How does the AP know which RA to choose?
    -> Pascal: Unless there is an algorithm
    -> Choi: ...
    -> Nick: It is an interesting idea
    -> Pascal: I am wondering what you really have to standardize

    Fast Router Advertisement
    - Preventing Denial of Service

    -> Pascal: Is changing these values media dependants?
    -> Greg: We can make them media dependant....
    -> Nick: Is this a topic for DNA charter or MobOpts?
    -> Greg: It is for DNA. Getting RA information quickly is in charter

    - Deterministic Fast RA?
    - How it is deterministic?

    -> Greg: How can we move with RA caching in AP?
    -> Nick: there would be scenarios where it would be better/easier to modify the AP rather than the AR...
    -> Greg: Do you people see an interest for a fast RA?
    -> Alper: Can we talk about next steps more concretely? We should start converging


    DNA solution framework
    Link IdentiŁers
    Fast Router Advertisement
    Deterministic Fast RA