Agenda ====== Chair: Greg Daley Introduction/Agenda Bash (5 Min - Chair): Problem Description/Existing work (40 Min): - Movement Detection in Mobileip (JinHyeock Choi) - Link Detection in zeroconf and DHCPv4 (Bernard Aboba - Address confirmation in DHCPv6 (Ralph Droms) - discussion Issues (40 Min): - Link Triggers (Alper Yegin) - optimized DAD (YounHee Han) - Discussion: Common ground - Mobileip, IPv6, zeroconf and DHCP - Discussion: 'v6 only' or 'v6 and v4' Interest and Focus (15 Min - Chair): - Work Plan Proposal - Interest in WG Formation BoF Description (If you don't have one) ======================================= Detecting Network Attachment (DNA) BoF Description: Network Attachment occurs when a host arrives on a new IP subnet. When attaching to a network, a host either already has a valid configuration for this subnet or must configure addresses. A host determines whether it requires additional configuration by Detecting Network Attachment. When a host has existing upper layer protocols sessions, it is important to receive a timely indication that attachment has occurred. This may be the case if a host is connected intermittently, is moving or has urgent data to transmit upon attachment to a link. For these nodes, it is also important detect if an acquired link is new, or has already been visited. This information may be used to distinguish between events where configuration must be initiated, or a host already has valid configuration. This meeting hopes to providing a forum for those interested in developing generic attachment detection technologies for IPv4 and IPv6. The BOF aims to: * Describe existing issues encountered in DHC, ZEROCONF and Mobileip WGs, which could benefit from work on detecting network attachment. * Define the problem scope, and environments where network attachment detection is desirable. * Determine if sufficient interest exists to form a Working Group on this topic. * Reach consensus on the area of work for a potential WG, including which problems are outside scope. Meeting Summary: ================ Summary of the DNA BoF Meeting at IETF57, Vienna, Austria Friday, July 18, 09:00 * Text (Contributed by TJ Kniveton and Brett Pentland) of the meeting discussion is available online at: http://www.ctie.monash.edu.au/dna/minutes57dna.txt Decisions --------- 1. DNA Worth doing as a working group. (most hands for, 4-5 no) 2. V4 and v6 should be together in the working group. (for 25, against 10) 3. DAD optimization within the working group. (for 25, against 6) Action Points ------------- AP1. Develop a WG charter for Detecting Network Attachment. AP owner <GD> Target Date: BoF LC to be completed by late August. AP5. Discuss whether cataloguing L2 Hints is useful (consensus call?) AP owner: <TBA, initially GD> Target date: mid August AP2. Link Localv4/DHCPv4 interaction clarification AP owner: <GD, Zerconf, DHC WG Chairs> Target date: to completed before mid August AP3. Link Localv4/DHCPv4 issues and guidelines document (informational?) AP owner: <TBA, not discussed> (suggested by TN/BA) Target date: to completed before mid August AP4. Mobile IPv6 Handover Delays Description Document AP owner: <TBA, initially GD> (suggested by TN) Target date: mid-late August AP6. Establish Liaison with IEEE ECSG (? Not agreed, depends on L2 Hints in WG) AP owner: <TBA, intially GD> Target date: end of September Meeting Minutes: ================ 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 (<t1). If this is valid, perform reachability detection on default gateway of most likely. If this succeeds, reuse the address. Otherwise, send a DHCP Request in INIT-REBOOT state. If there is no valid IP address lease, or no response to DHCP Request after retransmission, go to INIT state. Empirical evidence is that this is invalid much of the time (you just end up disconnecting yourself from the network for about 5 minutes), but it could be required. If IPv4LL is allocated, how often do we attempt to obtain a routable IP address? What RFC2131 says.. Sec 2.2 server and client probing. Sec 3.1 Retransmission of DHCP Request: 60s Max (is kind of long for mobility). Sec 3.2 If you don't get an answer to dhcp req. you may choose to use previously allocated network address anyway. Sec 3.7 Reacquisition. "should use DHCP to reacquire after disconnection from local network". -- Probably want to run on link-up, not link-down. You might have multiple different addresses that you can continue to use. draft-ietf-zeroconf-ipv4-linklocal-08 probing isn't always mandatory, Why DHCP shouldn't alloc LL addrs. Someone else could have acquired your address while you were asleep. you wake up, and now you have a conflict. So you have to claim and defend. But you may have woken up on a different network than before. but you may now be on a routable network instead of zeroconf. So you may roam around and never actually be connected. Solution - don't select an IPv4LL as a first resort. Test reachability of autoconf neighbor(s) first. But you could be all wrong! Summary: There are multiple ways you could have mobile hosts that are never connected.. i.e. 802.1x + premature DHCP + LLv4 + 5 minute timeout, Naive IPv4LL implementation. Where should this work be handled? Ralph Droms (RD): Thank you for taking on this work. Clearly we tried to capture this in rfc2131, and sort of got it right. We got disconnected vs connected incorrect in DHCP, and it will be corrected. Your document really does span two separate pieces of work. Also it spans 2-3 WGs. We could take the document as is for the intersection of WGs, or break it into pieces: * Here are the hints * Here are the things which need fixing in DHCPv4/LLv4 etc. I wonder which way we move forward on this. Spencer Dawkins(SD): On heuristics of figuring out where you are .. conversations about similar thing in different context - In Trigtran, we discussed instability of certain triggers. For example, in 802.11, we're not sure if the link is actually up or down. Is this covered? BA: Yes, there is a danger from spurious triggers. There has to be some damping. It's a 2-edged sword, because when you do it, it makes it slower. We don't know correct damping constant to satisfy everyone. We have seen situations where hosts have received 10 up/down indications per second. This would be something we would talk about: What do you do with a link-up in the last 0.10 second? But someone will probably come up with some supersonic flight situation where you need it.. Thomas Narten (TN): It may be useful to break these into several documents. We don't want to hide all of this information inside bigger documents where the implementors won't see it. Some of the stuff the mobility community is doing is general purpose not just to do with mobility. It's just fast detection of link-up at lower levels. I'd like to see this all in one place, but in a location where mobility is just one customer of the information. BA: Interplay between these things that might not be appreciated in individual documents. Rob Austein (RA): (Without IAB hat, w/operations hat).n We see this. In Atlanta on the IETF network, it's a real operations nightmare. BA: By the way this is not always LinkLocal. RA: Card drivers, Pulling laptops out of suspend, etc. usually end up with tech support claims. It sounds like this work needs to be heavily focused on getting LL fixed. Do we do this in the zeroconf WG? or they need it as input at least. TN: (AD hat off). I think there's agreement that the zeroconf document needs to be clear about using it as a last resort instead of leaving it neutral. We need to bring it up in zeroconf to clean it up in that document. RD: We may need to feed this into zeroconf. More strongly, we also need to adress interaction between what zeroconf is writing down that affects operation of DHCP hosts with RFC 2131. BA: We have to send this issue to zeroconf WG mailing list. Itojun(I): Assuming that zeroconf and DHCP are fixed, what kind of document would be created, standards track or informational? I prefer informational better. BA: It shouldn't change protocols in any way, so informational might be better. TN: Need a document which says here's a bunch of issues, and provides guidelines. We need to get more experience with it. We know how to deal with 80% of cases, but edge cases... BA: Well we know, but this is not necessarily reflected in implementations that are out there. Presentation by Ralph Droms (Some Slides by GD) Following up on bernard's work, I want to say what's done regarding movement detectin in DHCPv6. Section 18.1.2 if client moved to new link, prefix no longer valid, go back to server to find out if on same link (same as v4). Lists times at which client may have moved, 4 examples - Reboot, Physically Disconnected, Return from Sleep, Wireless change of AP's. It's pretty handwavey. We leave it to the implementor to figure out how to accomodate a wide variety of tech's. Send dhcpv6 confirm message that goes to any available server, servers compare link on which received to server's model of network architecture on server side. If the prefixes in the confirm message are appropriate for the link, it sends back a response with completion code of success. If any addresses are not appropriate, send back Not-on-Link reply. In this case, the client knows it needs to go back to DHCP server to get addresses appropriate to the currently attached link. Retransmission and timeouts - Initial random delay between 0 and 1 second. Retransmit delay of client, max of 10s, and randomized exponential backoff. The maximum number of retries? don't remember (GD: none, just maximum duration) Client may use previous addresses if it doesn't get response. The Router Advertisement might not entail you have DHCP unless the M bit is set. Need to know you have server available. Difference between DHCPv6 and DHCPv4: * Use of DHCP can be controlled by RAs in IPv6. * Hosts can avoid latency in determining there is no DHCPv6 ( M bit = 0 )on a particular link. In IPv6 there's no dichotomy betw LinkLocal addresses and assigned routable addresses. In v4, we have to pick one or the other. BA: You only get a timeout if you're: * unable to confirm reachability * RS/RA tells you you're using DHCPv6 * You're not getting any response. This is an unlikely set o coincidences, and the most likely explanation is a bug, rather than no DHCP. RD: usually sw bug or misconfiguration of network. Unknown (?): Do you have sufficient reason to convince that you really need DHCP for v6. In this room, many people are against this idea. RD: I think that's out-of-scope TN: DHCPv6 exists, we have a spec, and something which describes how to use it correctly would be good. BA: I'd like to echo that. If we're using DHCPv6. This is about describing how to use it correctly. TN: We need to Focus on the Big Picture, and find out what is causing the delays in configuration. Currently this is being done in all different WGs, and we need to fix this. RD: We need to clearly identify which problems are to do with mis-administration. GD: Talking about agenda (a little late for that). After technical hitches, slides are available. Is there any other existing work which we should cover? <nothing from floor> 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. <missed> AY: <presentation continues> 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: <missed> 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 Trigtran 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. |