IETF 72: dna working group minutes THURSDAY, July 31, 2008 1510-1610 Afternoon Session II ====================================================== Chairs: Greg Daley, Suresh Krishnan Minute Taker: David Miles -- Simple DNA -- Received reviews from last meeting. Started to use an issue tracker (tool.ietf.org). It will list all issues in the document and whether they are open or closed. There are currently no open items. Only the chairs have access to the tracker. If any issues send to mailing list. Issues: A simple DNA host should not perform DAD after re-attaching to a known link: - If you knew the link there may be no need to do this. - You have the same issue if network breaks and heals again. There is no need to address this here. - If the host finds link change, it should do DAD, if no - no DAD Jin: "no link" can be ambigous - if go between links and return to the original link, i need to do DAD. Suresh: It is a known problem, and its should not be addressed here. Its the same as healing networks Dave: In the stateless case, you had to do DAD. Link in DNA documents is used differentely. If you are reconfirming the same address that you do NOT need to do DNA. Suresh: Want to clarify, you cannot use the address if the valid lifetime has passed. Erik: Those are typically very long. If you have been gone for 10 seconds, i dont see you have to redo DAD. DAD is not reliable. If you have been gone for a week, even if its a known link you need to recheck. Not sure of valuse. Suresh: So should we say "if gone for a time period, redo DAD"? Erik: Yes it may be useful to have somethnig that requires you to do DAD if you have been gone for more than a few minutes. If I've been gone for a few minutes it shouldnt hurt Jin: The problem is not DNA. DNA proposes a solution. A host may not need to perform DAD - why forbid it at all. Suresh: Should we make this MAY? Thomas: MAYs are for wimps. We dont want to do full DAD when there is a penalty. This is seen when there is a hiccup while reattaching. If you have been off the link for say 2 hours, it doesnt really hurt you that much. Suresh: What we want to address someone moving between network segments. moving between two links all the time. The goal was to allow you to use the address straight away on your return to the old link. Its not just that case btw. Thomas: What is the principle? Bernard: Sometimes there is no need for DAD, say using DHCP. Another case you reattach prior to when DAD could have been completed. You wouldnt need to do it at all. It seems to be suggesting you should do DAD. Im not sure if I am agreeing with Thomas - I dont think this text is right - sometimes it should say SHOULD NOT. Suresh: Stateful case DAD is not applicable Jin: What about if you use DHCP and have been away for a long while you can still use the same address. ?: The penalty of doing DAD when you shouldn't - the impact is being in tentative state. We are not recommending doing optimistic DAD. This seems to be addressing a technology that knows how to switch many times. The time you have been gone from the known network is a useful thing to do. Suresh: I want to clarify that hosts should or shouldnt do optimistic DAD. Any comments? Berard: Its not useful to require something that doesnt make a difference. I do not think its needed to do optimistic DAD. This should not require optimistic DAD. Jin: I agree that if its a short delay, we can skip DAD. But can a host measure attachment time? Suresh: we need to put a timestamp in , its possible. Jin: It is starting to sound like this is getting complex Suresh: Can we change this to MAY? Dave: Can we note that its important in some case and not others. What about state machines, preferred, tentative, etc. I do not know what Microsoft will do, but Vista was implemented prior to optimistic DAD RFC, but it does something similar. When using random address ID you get a similar behaviour to optimistic DAD. Its not optimisitc DAD compliant, but it has the same end result of optimistic DAD. ?: Some interfaces are more unique than others - such as the use of U-bit in interface ID Suresh: A lot of standard technology may not honor or use the U-bit. There is nowhere it mandates the U-bit means nothing Thomas: Its not true, why engineer out stupid people. How the U-bit is formed is clearly defined in the addressing architecture. Suresh: It is defined only for Ethernet MAC addresses. Thomas: I dont think the Ethernet is a big / practical distinction. Suresh: Can I propose something and take it to the mailing list? -- Where we should do dad, and when we MAY do DAD. Vs. SHOULD NOT and MAY. Prefer latter. SHOULD NOT: if detatched from the link for less than X time period. MAY: all other cases Dave: if in the future IPv6 needed to solve the merge problem, a solution may come about. This says should not do DAD in certain circumstances. Would this new solution require an update to this RFC. You may want to do the former (SHOULD/MAY) so it requires less RFC updating. --- Which option to prefer, SHOULD/MAY, vs SHOULD NOT/MAY. Thomas: I have objection to MAY. Its a copout. I think there is more descriptive text than MAY and SHOULD. Give enough rationale for the implementer. Dave: Can we change the question SHOULD NOT (remove the MAY). In the former we just have SHOULD (again no MAY). Jin: We talk about X time. We need to talk about which X time, and what mechanism. This may be too complex for DNA. I thought DAD was out of the DNA charter. DNA is about detecting attachment - DAD is related but not identical to detecting attachment. --- Suresh: Does this cover all the cases Erik: I dont even think these are shoulds. You may need to say its not useful to do it if you go back to a link after a certain period of time. Thomas: Should say in some circumstances I should run DAD. By saying SHOULD you can cause implementers to blindly go and do anything that is SHOULD. Put context around the SHOULD/SHOULD NOT argument. Suresh: Should we do SHOULD or SHOULD NOT? Thomas: SHOULD --- Scope of SDAT. Is the scope on a per-interface or per-host basis. Added text to make this clear. Do we need stronger text? -- When is DAD done. Is DAD done after link-layer notifacation or after performing simple DNA. - Default Router Selection: When you attach to a new link, and you confirm the router is reachable, you can put the router straight into RECHABLE state for default router selection. Dave: How do you know the router advertisement is a reply to the router advertisement? Only can do this if it unicast to you. Thomas: its not clear " what does it mean by communication fails?" Suresh: you wait until neighbour cache entry is incomplete at the moment. Thomas: if you just switched for a second, you dont want to do anything differentely. If you have been away for 2 hours you would be in a PROBE state. Suresh: 4861 only differentiates between INCOMPLETE and non-INCOMPLETE. Thomas: isnt this in the default router list already? dont you prefer reachable routers? Suresh: actualy it only says prefer ones that are not incomplete Thomas: why isnt this a general problem for ND? ?: If I have been to the link and come back, what is this trying to solve? Suresh: Assume 3 routers and on a link and that you are using all three Suresh: You have a SDNA table that keeps a list of routers you have previously talked to. You try to probe the router to those that have been known before. You send NS for checking whether any of these router is available on the current link. Suresh: Link B has a set of routers. I also remember link A default routers. If i move to link A, i do a NS for routers I have learnt previously. One you detect on the different link, flush the NC, default router list, etc Dave: I think you want to CACHE that stuff, you deactivate it, not delete it. Suresh: Ok -- Source Address in RS could be previously set to any address that is valid. Text now says to use link-local --- Draft didnt define "valid address". New terminology "operable address" and valid address to distinguish two cases Jin: Usually valid means an address i can use on an attached link Suresh: No, in this document it means an address with a non zero valid lifetime. Jin: Is this independent of my current attachment point Thomas: Yes - its a property of lifetime Jin: Operable adds the attachment. -- way forward, I will propose text and see where to from there Is there anyone who will volunteer for review? Dave: Case, two eth, I use DHCP. Plug in 1 and get a DHCP lease, Unplug and plug the same cable into my second eth interface. Is it legal or illegal to use that valid address as an operable address on that new interface? Jin: No, in DNA before it would not be allowed. Suresh: I dont know if it is allowed in 4861 ?: With addresses its not a big deal, but you dont want to carry across prefixes. You dont know the security properties of the two interfaces. Dave: I think thats persistent with per-interface and not per-host. This needs to apply equally to valid/operable address. Jin: This is a big change. DNA was about link identification. Address is verified on the router. Can we make this clear in the draft. Make clear address is verified on a per router basis. what about MTU and other information (other than address). Suresh: verify though a NA or RA from a known router. If a RA from the know router gives you different parameters, this overrides the old parameter. ?: What about doing SLAAC - confirm the router but someone changed DHCP, then you do stateless DHCP. Overrides config but not address. Suresh: Ill try to make it more clear Jin: Now we need to keep all these things now. Id like more clarity about existing configuration.Assume I send NS to known routers and get NA. I am on same link. But then I get a RA that has different prefixes. What do I do? ?: If you try to describe DNA state machine, when do you know that you are done with it? If you receive an RA that has no common prefix with what you know - you dont throw away what you know cause its a rogue RA. need a termination criteria. Jin: DNA process should start and stop? Suresh: stops when you get an NA or RA. Jin: NS/NA takes precedence. ?: What gets to override what is not a state machine issue. Jin: SDNA only works when host revisits the same link. -- Complete DNA -- Suresh: This document was earlier on standards track - but in the last meeting we had consensus to publish this as either info or experimental with a preference for info. Cant request codepoints as info. Document changed to remove codepoints. Erik: i think one has to add a paragraph to explain relationship to DNA simple. This is an alternate design. Jari will take up this document once this edit is made. --- Advertising link properties --- How do deal with radio modems that have varying link capacities over time. Any adaptive rate modem. Router is not directly attached to the variable speed link. How does the router find out what the performance is. Get the router to know what the speed of the link is. Cant clock serial interface. Could do it using PPPoE using RFC 4938. Could use flow control or ICMP. Used a simple UDP packet. Modem sends UDP traffic to link-local with new parameters. Interface flags, rate, etc. Just a strawman. Could provide other information. Is flow control needed or can we just provide explicit rate.