DNA BoF - 2003/07/18 - notes by Brett Pentland and TJ Kniveton Minutes. Introduction Greg Daley (GD) GD: slides are online http://www.ctie.monash.edu.au/dna/ GD: Detecting Network Attachment - mechanism by which hosts can determine whether they're attached to networks through existing means. Applicable to intermittent connectivity, etc. so you can determine whether address configurations are valid. This is important for upper level sessions with time constraints, or are sensitive to packet loss. Concentrates on how can we reliably detect attachment. Upper layer protocols - IP mobility services, DHCP configuration, DAD, protos like TCP, .. Determine whether these mechanisms are available for v4 and also v6. We have some ideas already, is BOF interested in this? Existing previous work in mobile ipv6, zeroconf, dhc, We'll cover this first with a couple of presentations Movement Detection in Mobile IPv6 - JinHyeock Choi (JC) JC: Table of Contents: * MD overview * process * methods * problems, req & further steps Movement Detection Overview: ---------------------------- As an example: MN is attached to AP1, which is in front of AR1. Then it connects to AP2, connected to AR2. The MN receives some hint that it might have moved.. Then it checks whether it can still reach AR1 using NS... Movement Detection Process: --------------------------- step 1 - Hint, step 2 - Check reachability of current AR. step 3 - Check validity of current CoA. step 4 - Router discovery with all necessary information. A Hint may be an L2 trigger, new RA msg, RA beaconing. Check reachability of current AR uses either: NUD (3 NS probes) one NS and timeout or RA beaconing Checking validity of current CoA. undertake RS/RA exchange, check whether prefix of current CoA is in RA. Router Discovery with necessary information - RS/RA exchange. Movement Detection Problems: ---------------------------- Inconsistency of RA information (link-local scope of rtr addr, prefix may be omitted). Delay to check reachability of current CoA. Random delay in RS/RA exchange. Erroneous Detection/Unnecessary Signalling May be caused by Eager Cell Switching (ECS) without L2 support Movement Detection Scheme Requirements. Fast: Low Time Delay Precise/Secure: Little Error Efficient: Limit Signaling (NS/NA or RS/RA) Further Steps ------------- Basic MD scheme as guideline for MIPv6 Optimized MD scheme for faster handovers. TJ Kniveton (TJ): You talked about a lot of different upper layer protos and applications. What are the parameters for supporting movement detection when low latency is a goal versus general. GD: We're looking at the situation where movement prediction hasn't happened: This is the basic operating support when fast handoff is not available. Looking at solutions we'd be able to deploy in next yr or so that can provide operational support for people trying to determine these things within 30-40 ms JC: I've talked to implementors and they don't have a clear way to detect movement. Required at least for MIPv6, but we don't want to require FMIPv6. GD: There is a general requirement for this in MIPv6, and it's good to have one set of messages over the link which we can rely upon for network attachment detection. TJ: There are general ways of Movement Detection, and lots of Link Layers with different capabilities. Are we aiming at Layer 3 or specific Link Layers? GD: Principally at L3, but might be supported by particular types of enhancements by using ll triggers. If we get a strong hint form 802.11, SSID changed, for instance. We're not going to standardize stuff in L2, but maybe provide general guidelines for people using L2 with these capabilities. JH: It is difficult to support fast movement detection without L2 triggers. But some link layer technologies are more friendly to movement detection. So some solutions only work with certain L2s GD: There's some work on including L3 information in L2 Messages, but we don't want to re-implement for each L2. Presentation by Bernard Aboba (BA): DNA in IPv4. Use/misuse of IPv4 LL addrs. Today's hosts are often mobile. May or may not use Mobile-ip. IPv4 address LinkLocal addr usage in v4 is usually a *mistake*. How do we make address assignment more resilient and hopefully faster? Hints are non-definitive indications. A host has to test them. L2: * 802.11 SSID * ifra/adhoc * IEEE 802 LLDP traffic L3: * IRDP. We define a "most likely" point of attachment (POA). This is a best guess, based on hints. By default this is the previous POA. Reachability detection: ARP request sent to most likely default gateway. If most likely POA was autoconf network, then ARP request is sent to an autoconf neighbor. Also, you have to test MAC address as well. This is kind of tricky, because network might now be configured instead of zeroconf. As a strawman proposal, we formulate most likely POA. Is IPv4 LL ever "most likely"? Maybe if previous POA was autoconf. With DHCP, Check for valid ip addr lease ( L2 Triggers Presentation By Alper Yegin (AY): Detection and Reaction cycle: Collect Clues: linklayer hints, network layer hints. Make Determination. Change Configuration: use some of the network layer hints,learn others. Network layer can: detect presence of new router (or absence of existing rtr), detect presence or absence of dhcp server. detect presence or absence of on-link prefix by promiscuous snooping. TN: What do you mean detecting on-link prefixes by promiscuous snooping? What if the networks are transit networks, with lots of different networks' traffic on them? AY: We're basically looking at theedge of the network TN: I think that's a really weak assumption. SD: We're starting to see networks hanging off what used to be hosts. TJ: We're seeing this in NEMO. AY: The link-layer could: * tell ip when link is torn down * tell when link is established * tell the link id (i.e. ssid) * other fancy features Hosts may passively collect hints * new prefixes advertised * prefix goes stale * prefix part of IP addresses change * link up received actively collect hints * send rtr advertisement[do you mean solicitation?], * learn the current link id Who receives L2 Hints? Preferably the host, but network side (e.g. Router) hints may be useful too. Interpreting detection of a new link Doesn't necessarily means configuration change for network layer There are some security concerns BA: I think this is called a hint because may be garbage. They're not authoritative. If it's wrong, will I still end up with the right result and just lose time? AY: Collecting numerous hints leads to a decision. We need to evaluate each hint and weight them accordingly. RA: With security, you should not end up damaging environment, or you could have damage amplification system. What can we do at ietf? - define useful or practical link-layer hints. The details are link-layer specific, so we must use an abstration. One example of this is defined in: www.yegin.org/alper/draft-manyfolks-l2-mobilereq-02.txt We can communicate with other SDOs: IEEE handoff Exec Comittee Study Group(ECSG). one of their reqs is to get requirements from IETF wgs. Finally, we can define two movement detection schemes: * when l2 hints available, * when l2 hints are not available(partial mobility?) BA: In the case of ECSG, traffic goes other way. They're looking for needs from us. i.e. should SSID change be detected as default? Should they advertise information elements with prefixes? So they're looking for requests from us, so we need to ask them. SD: Been talk in TrigTran about complexity of solutions we have (increasing). In trigtran they had advisory notifications. Now you have a state machine to figure out the hints. We've even been trying to decide if hints are lying to us. This adds complexity, which we mustn't lose track of. We need to be careful to not go too far down this track. AY: We need a scheme that doesn't need hints to work, but also need a scheme that can make use of those hints that are available. RD: I agree l2 is useful and can provide hints. We may have a different point of view on l2 hint details. We need to at least capture pointers to l2 details so we can know where to go to find these things. TJ: I'm thinking about Link movement without layer two hints. May be cases where it can't be done Are you just surveying things to provide guidelines or proposing changes to layer three technologies? GD: Mostly guidelines TN: Certainly want to at least survey the landscape. We might notice that there are simple changes to protocols that might aid us, and either do them here or hand off to other groups. i.e. DHCPv4 needs update, or may be able to define another v6 RA option to help. JC: For basic movement detection, link up/down triggers are sufficient. For more optimized solutions we need other triggers. SD: Much better to have a scheme that tells the answer rather than just giving hints GD: Is this stuff in scope? BA This is relevant on collecting information about links. Having a complex model or having lots of state isn't helpful, because it's just a hint. If you can get to the wrong answer based on hint, there is a problem. Erik Nordmark (EN): I get the feeling there are short term operational issues for IPv4, and a desire to do things robustly as well as performing better for v6. Creating suggestions for getting better solutions at l2 is a rathole that might detract from first two. Writing down what's there or not is useful because people can then understand what's going on. TN: A starting point would be a document that tells what hints are available for various L2s and what they are useful for. Maybe if we talk to IEEE we might do something that makes more sense than if we don't talk to each other. GD: Is it worthwhile to catalogue L2 hints as a starting point and leave recommendations for another document? TN: Do you have a potential charter, list of potential work items, then people can say whether they think it's a right direction, etc. GD: There has been some talk that link-up triggers only is a good place to start. AY: TN: It would be useful to enumerate the hints that are available GD: Are we just focussing on those relevant to movement detection? John Schnizlein (JS): It would be a wonderful world if we had a reliable decision of link-up/link-down - We don't have a simple state machine any more because we don't have clear state transitions. In wireless we don't know. We should stop calling these hints triggers. They are really just hints. We should not make state transitions on the basis of hints. A clarification, BCP document might be very useful for implementors. SD: Maybe we need to focusing more on how things get put to use differently as you get higher in the stack. I didn't realize how many people expect to have applications react to these things. We were thinking only of one interface in Trigtranm but many people were thinking of more complex environments, i.e. low/high speed interfaces. I don't want to side-track this work, but there needs to be work done on interactions further up in the protocol stack, which is separate set of topics than what you are talking about. BA: I'd just like to reiterate that even things that are referred to as triggers may just be hints. Even link up. look at definition of link up - it's unclear. 802.11f and 802.11i get triggered by different things for link up. So if you believe that packets are lost, you might end up disconnecting when you shouldn't, etc. Unknown (?): 802.11 beacons are more than just hints; they are real information of what has happened at Layer 2. We have more than hints, we can start defining triggers. AY: This group should look hard into this, because benefits of l2 hints are very clear. If we shy away from looking at L2, we'll come up with a heuristic and when people productize it, they don't know where to stick l2 things in, and they'll break what we do in l3. GD: We've got an indication it's important to look at these, and we'll discuss it on the list. DAD optimizations Presentation by Youn-Hee Han (YH): Proposal is to give background and current work about DAD optimization. Today, DAD is performed on all addresses, independent of whether they're obtained by DHCP or stateless address autconfig. Is this reasonable for all kinds of addressing domain? Why optimize DAD? L3 handover delay in MIPv6 using rfc2462 DAD between sending NS and sending BU is 1s. We want to make DAD optimization an issue in this forum. existing works in this area, for stateless (optimistic dad), and stateful (advance dad) going over draft-moore-ipv6-optimistic-dad-02 going over draft-han-mobileip-adad-00 Next Steps? As MIPv6 matures, the need for reliable and fast address allocation and DAD schemes becomes critical to the goal of providing real-time data services. I: This issue has been done to death in IPv6 WG. We don't need to do it again here. GD: It's been discussed to death with no solution, but 1000ms is too long if you have existing sessions. TN: IPv6 views DAD as being necessary against disaster. It's hard to debug and track down in the field. OTOH, for MIPv6 this 1s delay seems to be extremely high. What i personally would like to see is for somebody to go through and do an analysis which explains what all the delays are when you arrive at a network until you can exchange packets, so we can do a systematic analysis. GD: Maybe a draft like this should be submitted to MIP6? TN: When people say they need this, it would be nice to know what real-time means. Keichi Shima (KS): We're implementing MIP stack in KAME. In our implementation, the biggest blocks of time are not DAD, but detecting if the link is up or not. It is more important to determine if the current CoA is still valid. Modified MIPv6 proposals have effects outside of core group. For example, the proposal to relax the router advertisements interval. So we relaxed to 30ms. Almost half of our CPU time is taken by router advertisements. GD: This is a motivator, we need to find ones which don't consume Network bandwidth and CPU load. Pekka Nikandar (PK): DAD is needed in some way. There's a big difference between using random identifiers and those that are not. For random addresses, waiting at all is too long. With random addresses, probability is low and we should use an optimistic scheme. SEND decided to use CGA which are (almost) guaranteed to be random addresses. BA: It's nice if a working group has a very well defined set of things so it has a chance of succeeding. Then if you do those simple things right, maybe you can feel good about yourself and take on a different problem. EN: I'm on the fence with this one, because I agree with Bernard, but lots of people want to make DAD faster. So we need to make sure DNA is robust for v4 and v6 and people want to do work for v6 and make it faster, and DAD is one part of that. Yes, we should pick a small piece and start with that, but running in parallel independently is a bad idea, because it may be a difficulty to get a fast and robust protocol. JC: Do we feel dad optimization is useful, and is this BoF a good place to do it? 1st question is yes, and if 2nd is no, we should find somewhere else to do it. Francis Dupont (FD): The decision for DAD optimization should be in the hands of network managers, since he is the one that has to clean up the mess in the unlikely event of a collision. tsatsuko from hp (T): I support this issue because DAD issue in this WG is targetted for mobility enhancement. I'm interested in DHCPv6 with optimization. Currently we have stateless and stateful DAD approach. It would be good to have a framework document to describe this. GD: Hopefully this is not a movement detection group. This should be useful for hosts that are not doing movement detection, but get detached and attached. I think there are 2 issues: correctness and swiftness. If we can handle both in one group neatly, I would personally like to, otherwise I would like them split off. Question from Chair: Who thinks DAD optimization is interesting for the IETF in some form to look at and worth looking at? (pretty much unanimous yes) Who thinks this is a good match for the DNA working group? (about 50/50) TN: I don't think this is a good match. This problem is pretty self contained: The cost of DAD is too high, and how do you get around it? DAD comes in after you've already attached to the network, so i don't think it's a good match for this WG. But DAD work has been homeless for a while. PN: Reason why I'm saying no is because this is all part of a much larger problem, which is being able to attach fast. Saying DAD is afterwards, you make it serial, but these are things that can be done in parallel, at least in some cases. TN: I think there's a fear in the group that if we don't do it now, we delay for another 4 months until we start it. GD: This BoF could also lead to more than one working group. Gabriel Montenegro (GM): I want to point out this is the 2nd round; we started in MobileIP wg. As we were rechartering, we were told by the AD that maybe this part should be left out of MobileIP groups. So if we're now told this is not the place this should end up, we've already lost at least one round. We should find a home for it immediately. A v6 group that concentrates on correctness and swiftness would be good. Even servers could be on wireless links because people don't want to lay cables. GD: Is there an interest for putting v4 DNA alongside v6? TN: A lot of ll hints, etc is generic to v4 and v6. But what you do about it (i.e. router advertisements), is different, so split might be useful. I'm not sure which would be better. doing them together brings more v4 experience and v6 goes off more into theory land. EN: There is commonality, but protocols that you use to do this might be different, so they might be different documents in the same group. PN: I feel majority of wireless links in future are going to run v4 and v6 at the same time. So it makes sense to work on both in the same place. The main argument against it is that some may not be interested in v4. GM: Thinking about what bernard said, only 2 times he used link local, all others were mistake. So maybe when you do preferences, maybe you leave link local at the very end .. assume it's in v6 or then v4..?? Many of these stacks will be dual stacks, so they have to decide between v4 and v6, not just whether link is up. GD: Haven't thought about that. I don't think that would be a very good match if v6 detection was used to configure v4. RD: Can you clarify direction of information flow? Are you expecting for DNA info to go into DHCP, or get info out of? GD: We'd like to document what is available and how it can be used. RD: Information flow is in both directions: Collect information on what is going on in DHCP, and provide information from DNA into DHCP. BA: No opinion on where it should be done, but opinion on for it to be completed. When you touch IP, you need a lot of eyes. It takes a lot of skills, and you need a good review plan and put together a set of scenarios that need to work. Expert reviewers need to make sure it really does work. So people in other groups need to be included in review process. Questions from chair: What sort of deliverables might be possible to get out. Should we handle version 4 and version 6 together in 1 wg? (about 25 yes, 11 no) TN: Is Network Attachment worth doing in a working group? (most of room yes, about 4 or 5 no) TN: Who wants to have IPv6 DAD opt within this group? (25 yes, about 6 no) Going to try and form WG which handles these things. TN: Need to go to the mailing list to define a charter. Looking at the charter now isn't going to tell us much more than we already know. GD: Group will take on v4 and v6 and DAD optimization. EoM.