DNA wg minutes of meeting IETF 68, Prague, Czech Republic 2007-03-20 Afternoon Session IV 1850-1950 JA, the internet AD in charge of the group, could not make it to the meeting due to a scheduling conflict. He would like to merge some of the intarea wgs to prevent this. SK mentions that there is only one item on the agenda. The open issues on the protocol document. SN presents the current state of the protocol document and lists the open issues Issue: Flash Renumbering ======================== EN would like to add a recommendation to network administrators to not do immediate reassignment of prefixes. SN agrees with EN Issue: Router Configuration Variables ===================================== SN would like to get some feedback from the wg on whether all the router configuration variables listed in section 5.1.2 are necessary. EN would like these variables to be replaced by protocol constants. TN thinks that they should be protocol constants if they do not need to be tweaked. Otherwise they can be configuration variables. But he thinks that the variables in question are too complicated to tweak. He does not want to force implementers to implement a knob that may never be changed. He thinks that dna is an extension for Neighbor Discovery and he thinks documents may override these constants on a per link type basis. Issue: Complexity ================= TN is worried about the complexity of the protocol. He thinks it is trying to do too much and handles too many corner cases. JA agrees with Thomas' worry about complexity. Off mic discussion between TN and EN. Looks like TN has been convinced (albeit partially) by EN that the complexity may be necessary TN wants to include the list of routers that the host heard from when it sends an RS to make creating the complete prefix list easy JHC thinks that CompleteRA can do this efficiently EN thinks (in an upgraded router scenario) the only reason the host does not get a completeRA is that the prefixes do not fit into a CompleteRA SN and JHC argued about which method is more reliable. CompleteRA or Complete Prefix List. (No Conclusion) Issue: Ordering of DNA steps ============================ JHC believes that the steps can be reordered SN believes that the steps are in order of confidence and need to stay that way. He believes step 3 may be removed without much of a penalty. JHC looks convinced Issue: Learned prefixes ======================= TN is concerned about using learned prefixes for determining the smallest prefix. He talks about a hostile router advertising prefixes. He does not like the idea of a trusted router learning stuff from an untrusted router and passing it around EN does not agree and he thinks the host would get the polluted data anyway. He also mentions that hosts do not autoconfigure addresses from these learnt prefixes, and the effects usually timeout TN needs more time to think about this Issue: Security Considerations ============================== SN wants to update the SecCons since it has not been updated since the merge. PS wants routers to always advertise all the prefixes they have i.e. MUST . TN to keep it a SHOULD as it may not be necessary to do so. PS thinks that would simplify the algorithm if the routers do so EN wants to know how dna can be done if the prefixes cannot fit into a single RA PS does not see this in real life. Only in attacks and in interop tests will the number of prefixes be high EN does not believe that making this a MUST. He thinks that routers MUST NOT do a dna RA if the prefixes do not fit into a single RA EN now has a stronger view now that such a router MUST NOT do dna at all if the prefixes do not fit into an RA JHC disagrees with EN. He thinks in case of RS with landmark it is still useful to send dna RA. PS (with his implementer hat on) would not spread prefixes across multiple RAs but he thinks some other implementations may do so. EN thinks that in some networks like 6lowpan where it does not make sense since the power consumption is proportional to the number of bits received but he thinks there might be some issues related to link layer fragmentation which may make this useful SN to initiate ML discussion on Open Issues and come up with a new revision of the draft once the issues are closed. People: JA: Jari Arkko SK: Suresh Krishnan SN: Sathya Narayanan EN: Erik Nordmark TN: Thomas Narten JHC: Jin hyeock Choi PS: Pekka Savola