IETF 73: dna working group minutes THURSDAY, July 31, 2008 1510-1610 Afternoon Session II ====================================================== Chairs: Greg Daley, Suresh Krishnan Minute Taker: David Miles Suresh: No further meetings expected. We will close down the working group soon as all docs are progressed past the IESG. Document status per the slides. We will not be re-chartering, just closing the WG. We don't know what text to put in about when to do DAD and when not to do DAD - this will be discussed today. Also need to make changes to the Simple DNA draft. Simple DNA - Suresh presenting ============================== Most of the issues have been resolved for the simple DNA draft. Every issue has been address except one - the DAD issue. Because of this issue a new issue (source link layer address option) has been raised. Once we agree on DAD we can address SLLAO. In summary (since Dublin): - Submitters have agreed to all resolutions - Simple DNA has a different ID model to complete DNA. Complete DNA tries to identify links and then gets new parameters again - an old link will not try to get new parameters. - Simple DNA has a history of more than one link. It also tries to validate IP addresses of routers. - New text was proposed. Suresh: We had text that said we need to send ND, RS packets - but there was nothing that said what is in the messages (such as SRC/DST addr). A new section has been added that describes the messages. This raised a new issue. Also people wanted pseudo code that describes simple DNA. It has been added to section 6 of the draft. The simple dna process completes when all the sent messages are responded to or timed out. Suresh: Simple DNA is optimised for a specific set of situations and does not work all the time, and when it doesn't work it works no worse than IPv6 ND today. A new applicability statement has been added. Simple DNA is useful when you move between a known set of links often. If you always move to random (new) links you will not get any benefit, but you will be no worse than today's IPv6 Neighbour Discovery. Dave: Text is great, but it would be useful somewhere to have one paragraph that says whether the intent is to be similar or different to DNA v4 - it seems like a FAQ that should be captured somewhere in the documents. Suresh: When to perform DAD: In my view we would always do DAD on the address. This is an efficiency concern, if you detach for only 2 seconds there is insufficient time for another host to perform DAD. No resolution to this issues yet. Bernard: One point we discussed whether this draft applies to DHCPv6 or SLAAC cases and we concurred it should apply to both. I think the situation is different based on how you got the address. When it was DHCPv6 I don't think you need to do DAD again, only in the RA/SLAAC case. I'd like all this text to be in one section. Ie, DHCPv6 you don't have to, and these are the cases where you should do it. Dave: You gave an intuitive rule of thumb which is if ive been gone for a short period, noone else could have completed DAD. I think you are asking the question of where to draw the line. If you are certain no one else has completed DAD what is that value. Erik: In order to do DAD, if you miss DAD messages it seems that you would have to use a value of 0. This is for where dup-detect is 1 (Ethernet) and you are getting it from statless stuff. Suresh: So, we agree that if the address was obtained using a stateful addressing mechanism like DHCPv6, the host SHOULD NOT perform DAD. (Room agrees) Erik: What about 802.11 when you change access points and keep getting link-up events. Suresh: Each of the link up indications will start up a new confirmation process. Suresh: Final conclusion: We will not have any text regarding DAD in the draft as it has nothing to do with DNA. If we got the address using SLAAC, and its a link-local address, and the probability of collision is low, we will include SLLAO.