Autoconf Working Group Meeting - Friday, 26.03.2010 o Administriva - Chairs: T. Clausen / R. Wakikawa - Mailing list: autoconf@ietf.org - Jabber Scribe: Ulrich Herberg - Minutes takers: Emmanuel Baccelli Veronika Bauer Chris Dearlove (on IPhone) Ronald in 't Velt - Blue Sheets - IPR - RFC3979 o Working group status update, Ryuji Wakikawa: Only chartered item is in RFC editor's queue. Now the decision needs to be taken as to whether recharter and focus on solution space or close up the working group. Today, the objective is not to make a decision, but to launch discussions to allow the WG to make a decision Thomas Clausen: If working group is staying alive, a rechartering should be done in the next few weeks. Thomas Narten: If working group should be continued there is a need to clearly state the problem that needs solving. Just focussing on solutions does not help to explain that. Without a precise problem statement, the working group should shut down. Charles Perkins: Allocating addresses in adhoc networks is a clear and straight-forward problem statement. Thomas Clausen: There are 2 issues that need to be solved: assigning identifiers to the interfaces on routers and possibly prefix delegation on these routers in a mobile wireless environment in order to allow them to assign addresses to other devices hanging off. They seem to form a quite clear problem, however there might be the need to articulate it more clearly. o PRESENTATION Emmanuel Baccelli: state of autoconf working group document Fixed nits raised by GenART and IESG. Removed RFC 2119 language and handled IPv4 and IPv6 issues. In RFC Editor queue. Erik Nordmark: Working group accomplished milestone, but regarding link locals there are different opinions on the mailing list. Possibilities about how to proceed with the document would include communicating with ADs, but generally the document is no longer under the influence of working group. Ryuji Wakikawa: There are 2 kinds of topics, namely address assignment for the manet interface and prefix assignment for the data aggregations, unclear if mandating e.g. address duplication detection. Details should be clarified at the end of the meeting. Editors should discuss feedback with Erik and resolve the issue. Thomas Clausen: If there are mostly editorial things they should be caught in Auth48. Emmanuel Baccelli: Concerning the documents there seem to be no new arguments concerning the documents so discussion should be about how to build solutions given the constraints present. Teco Boot: The document does not specify the use of link locals for v6 as discouraged. In order for expressing this, the document should be updated or a new one including that information should be written. Generally, this working group is not focussed on the use of link locals, so the best way to progress now is to stick to the text of the specifications to keep consensus. o PRESENTATION Fred on RANGER, VET, SEAL, IRON http://www.ietf.org/rfc/rfc5720.txt http://www.ietf.org/rfc/rfc5558.txt http://www.ietf.org/rfc/rfc5320.txt RFC 5720. Network of networks. Applicable to including ad hoc networks. Portable prefixes, do not need autoconfiguration. Recursive reencapsulation. VET RFC 5558. Traversal of single network. Tunnelling, only modifying border routers. Secure direction. SEAl RFC 5320. Tunneling has overheads and MTU issues. SEAL addresses this, including fragmentation and reassembly to achieve egress MTU. IRON overlay. Questions to mailing list. Ryuji Wakikawa: are there address assignments or prefix assignments in these solutions? Fred Templin: yes, routers can have provider independent prefixes which they take with them wherever they move. o PRESENTATION Zach Shelby on 6-lowpan-nd neighbour discovery in 6lowpan 'PREPONDERANCE LANDSCAPE' ... http://tools.ietf.org/html/draft-ietf-6lowpan-nd-08 Flat stub network. Includes hosts. Host initiated. Includes duplicate address detection (work in progress). References Autoconf RFC. Illustrations of protocol. Host initiated communication with router. Assumes unique EUI-64 for link local addresses. Autoconfigures non-link local addresses. Duplicate address detection in communication with border router. Multihop prefix distribution from border router. Most is generic, one 6lowpan specific mechanism to aid header compression. Similar wireless issues to MANETs. Stan Ratliff: 4 working groups (roll, 6lowpan, manet, dtn) do neighbor discovery but are heading in different directions in the way the solve the problem Zach Shelby: roll is using 6lowpan Stan Ratliff: and the rest? Erik Nordmark: simple interface to host & routers, the other mechanism is just how routers communicate amongst themselves, use 6lowpan if no address resolution Stan Ratliff: Because of mobility in the network there is the need to adapt from static to mobile IP. However, network definitions are sliding into each other, so care must be taken to not building lots of different solutions. Zach Shelby: 6lowpan supports only IPv6. ND is on link protocol, so there shouldn't be too much concern of it working differently in different protocols as it does not spill over to the rest of the Internet. Not each interface has to work in exactly the same way, but 6lowpan work can be reused in many different places. Stan Ratliff: characteristics of network determine ND mechanisms. From a link perspective this could be problematic as different protocols operate differently. Dave ???? [Thaler? Ward? neither of our scribes say which, I think Thaler]: NHDP is supposed to work with IPv4 and IPv6 and is currently being generalized to work with other routing protocols. It would be good to have only one ND protocol for adhoc networks and to favor increased coordination between the different working groups. Thomas Clausen: Keep in mind that requirements for neighborhood discovery in a MANET are different from ND in e.g. 6low-extensions. There are 2 different things to be done which justifies the existence of different protocols. Commonalities should be taken into account but I don't see any right here. Charles Perkins: The number of solutions for ND should be reduced as there are a lot of commonalities between different solutions. We should try to understand why there are differences and why they can't be resolved by minor changes to a protocol. Emmanuel Baccelli: The goal is to find one solution, which could be Zach's if it's applicable in that context. In response to Stan: there is a fundamental difference in what to do in ND and in autoconf- which is to configure addresses. Estimating the quality of the links we have to our neighbors is a completely different issue so there is a need for different protocols. For finding one solution to solve our problem, we don't need to care about link metrics; the main thing is to get an address. Charles Perkins: NHDP could be used (although it might be heavy-weight) for finding out about the one-hop neighborhood of a node when aiming for arbitrary routes over the network. If one wants to have only rooted routes through a distinguished node, NHDP is not helping very much. Zach Shelby: Agrees with Emmanuel in terms of using and extending the 6lowpan solution in autoconf. Addressing issues, router setup, and link metrics are not addressed in the 6lowpan documents. o PRESENTATION Hassnaa Moustafa "Survey of existing protocols" https://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 Survey of autoconfiguration mechanisms for MANETs. Not updated since November 2008. Needs updating to current documents and terminology. Classification characteristics listed (four slides). Should the document should be updated and improved? Charles Perkins: valuable document, should be updated. Thomas Clausen (floormike): It's an interesting doc, which however still has some terminology issues that need resolving. It should be updated. Ulrich Herberg: valuable, should be updated. Ryuji Wakikawa: should be updated. o PRESENTATION Hassnaa draft2: autoconf solution space analysis https://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02 Is there an interest in an updated version of the draft? Should the two drafts be merged? Thomas Clausen (floormike): It is unclear what purpose of the document is and how it relates to the working group scope. Also, the document doesn't draw any conclusions from the analysis that it performs. Hassnaa: The document is comparing different autoconf solutions according to different criteria and scenarios. Thomas Clausen: Right now the situation does not permit to accept new documents as working group documents, as the group needs to find out how to move on. Authors of the documents are encouraged to restart discussions about drafts and update them. We can use the discussions to find out in which direction a rechartering might be going. o PRESENTATION Charlie Perkins "Autoconf via XREQ/XREP (Global6)" 9-year anniversary edition.. https://tools.ietf.org/html/draft-wakikawa-manet-globalv6-05 Based on considerations from a system design. Discussion of standalone or gateway operation. Want solution works in both cases, as may not know which is case initially, and can change. Node gets an address by requesting it. But need address to route. Pick random address for temporary (milliseconds) use. Great for IPv6, good for IPv4. Standalone no beacon from gateway, so floods XREQ. If XREP arrives then address us taken, so try again. With gateway hears a beacon and unicasts XREQ to gateway. Multiple gateways, node picks one. Works with Mobile IP. Seven contributors circa 2001. o PRESENTATION Teco Boot "Border Router Discovery Protocol (BRDP) based Address Autoconfiguration" http://tools.ietf.org/html/draft-boot-autoconf-brdp-02 BRDO based address autoconfiguration. History described. Based on tree discovery for scoped flooding - now used in RPL (ROLL). Single and multiple-homed MANETs. BRDP distributes information from border routers, distributed in MANET using scoped flooding (required in large MANETs). BRIO message format presented. Zach Shelby: Adding multipath to the solution increases complexity as there are some difficulties with distributing prefixes within multihop networks. Things get sticky when distributing information in multihop meshed network, and trying to keep it fresh and to be sure a router does not advertise different sets of prefix information from different border routers, called authoritative border routers. With multiple border routers advertising same prefix the complexity is getting worse in terms of synchronizing etc. In terms of scoping the really easy problems should be separated from the difficult ones. Also, make sure to carefully scope problem in the working group. Thomas Clausen: How much of the problem has been solved in 6lowpan? Zach Shelby: 6lowpan tried solving the scenario with several border routers on one backbone, all injecting the same prefix to make mobility easy for nodes. However, the complicated part was split off and P. Thubert is writing a separate draft on it. Thomas Clausen: Where can we find information from 6lowpan? Zach Shelby: ND07 Charles Perkins: There might be solutions to solve the problem with routers advertising same prefix, which is out of scope of this working group. Also, keep RPL out of here. Henning Rogge (via Jabber): we have the Funkfeuer and Freifunk networks deployed, and we have a few scenarios that come from this experience that we would like to see covered by autoconf. Henning Rogge: Concerning BRIO, determining the best gateway for a given node is tricky, "better" means different things depending on the node you consider. Partial flooding is problematic. Teco Boot: The rules for flooding are policy based, so there is no problem as long as address selection works. Pick best border router based on metric. Use EUI-64 suffix. Zach Shelby: 6lowpan ND does similar things as shown in Teco's solution. We have come to the same conclusions in similar environment, and a working group document exists, which optimizes RFC4861. Autoconf could probably reuse some of this information. However, 6lowpan deals with a very specific type of network so some adaption will be needed. Communication between the working groups could improve the development. Thomas Clausen: We need to be careful about whatever causes flooding, and it seems to me in some cases something like flooding may be happening here? Thomas Clausen: What about IPv4? Teco Boot: This focuses on IPv6. But you could use IPv6 connectivity to provide IPv4 address. o PRESENTATION Ulrich Herberg "Yet Another Autoconf Proposal" Protocol to configure MANET- scope addresses. Consistent with WG document, not using link local addresses, aggregatable. IPv6. Unique local EUI-64, not necessarily across MANET. Formally verified (model checking) protocol. Charles Perkins: But what about mobility? Causes neighbourhood changes. Hasnaa Mustafa: Is this work a proposition of some components? Ulrich Herberg: Yes. o Open discussion on the future of the working group: Ryuii Wakikawa: What should a new charter contain? Or should we close down? Charles Perkins: There is this document with Emmanuel describing wireless communication which is pretty mature, is there interest in making this an informational RFC? http://datatracker.ietf.org/doc/draft-baccelli-multi-hop-wireless-communication/ There is now a very good understanding of the address model with candidate solutions. Also the new stuff seems to justify continuing. The comparison document [draft-bernardos-manet-autoconf-survey-04] could also be informational RFC Zach Shelby: I agree, this document [draft-baccelli .... ] is also interesting outside autoconf, for 6lowpan for instance. Alexandrecu Petrescu (via email): Need to allocate prefixes, not addresses. Charles Perkins: Doesn't exclude prefixes. Note that DHCP also took this approach. Jari Arkko: What will be the precise problem statement? Unique addresses & prefixes? I want to see it before defining a new charter. Thomas Clausen: Need a step as to why existing protocols do not do the job. Mustn't be nebulous long drawn out process. Jari Arkko: Don't say e.g. DHCP doesn't work, explain what is needed and the conditions in which it should operate. Stan Ratliff: Let this working group die. It achieved too little in too much time. Ryuji Wakikawa: I want to see scenarios first in order to prevent an overlap with other working groups. Maybe it would be best to focus on one, small problem first. Emmanuel Baccelli: There are 2 goals of this working group: prefix delegations & address configuration in automatic way. For continuing, focus on simple scenario with a clear and short description. Separate this from link descriptions. Charles Perkins: I disagree, we have steady progress since the last year. And we have a soon to be RFC, and low hanging fruit with further drafts that are pretty mature. Ryuji Wakikawa: Who plans to actively contribute to the working group? (10 people raise hands) Jari Arkko: How does having each new document that we envision advances towards our goals? That's an important question. Also about the link description draft, which used to be a difficult document if I recall correctly. Thomas Clausen: Yes I agree, we need to be careful not to get stuck again, this group has a history of difficult progress at times. Emmanuel Baccelli: Agree, not another five years. Christopher Dearlove: MANET author but didn't agree to participate, although wants protocol. Not agreeing with Stan Ratliff, but need a faster process to be able to be able to sell participation. Charles Perkins: For the ad hoc wireless communication draft, I think it is important to have it because it influences the solution space and it is needed by other working groups. Ryuii Wakikawa (floormike): The document is needed as reference and is important to skip duplicate discussions. Jari Arkko: This document could also be published outside this working group, as independent RFC submission. It should, however, not be moved to another working group. It needs to be made clear how big, a benefit this [or, indeed any] document would be to the ultimate goal of the WG. Thomas Clausen: I encourage to continue the discussion about rechartering on the mailing list. The goal is to converge on a result till April. In terms of our problem statement we need to be concise. Meeting adjourned.