================= Autoconf Minutes ================= --------------------------------------------------------------------------- Ad-Hoc Network Autoconfiguration (autoconf) ---------------------------------------------------------------------------- FRIDAY, July 30, 2010 0900-1130 Morning Session I ---------------------------------------------------------------------------- - Notes takers, blue sheets, agenda bash 5 min, Chairs - WG status update 5 min, Chairs - RFC5889 update 20min - New Charter discussion, as much as we want, Chairs - "Survey of IP address autoconfiguration mechanisms for MANETs", 15min, Carlos Bernardos http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-05 - "Router Advertisements for Routing between Moving Networks", 15min Alexandru Petrescu http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 ---------------------------------------------------------------------------- Minute taker: Ulrich Herberg, Emmanuel Baccelli Scribe: Teco Boot ---------------------------------------------------------------------------- Ryuji Wakikawa: Intro, bluesheet - Today mainly discussion about rechartering planned. - WG status update: History of Autoconf in the last 5 years. I-Ds that never have been published: autoconf-statement, autoconf-manetarch Thomas Clausen: - autoconf-manetarch went through WG LC, AD review, got killed then, even after Jari and Dave Thaler agreed on the document Ryuji Wakikawa: - 2009: recharter to write autoconf-adhoc-addr-model (currently suspended in AUTH48) Jari Arrko: - Core reason for not succeeding for autoconf-manet architecture work: too complex. That's the reasons for rechartering to write "an example" of address architecture. ---------------------------------------------------------------------------- Thomas Clausen: RFC5889 Update - in Anaheim: WG LC + AD review + IETF LC + IESG Processing, all okay, ended in RFC editor's queue - But then two issues have been raised by Erik Nordmark. Unclear what WG consensus on this issue is. Jari Arkko (as presenter): - We have RFC number (5889), approved in March 2010, but then issues have been raised in June 2010. In parallel, RFC edited the doc. Process for changing a document after approval: changes are accepted, but only for clear errors. Typically, AUTH48 is only for minor editorial fixes; for major changes the doc has to be brought back to WG. Judgment if IETF LC is needed again. No formal rules for AUTH48. Personal rules: (i) don't reopen any discussion/rough consensus already taken before in WG, (ii) no individuals can decide anything, only the whole WG, (iii) correct evident errors. Erik Nordmark's complain is: The document unclear that many routing protocols use link-locals (e.g. ISIS). No change to the conclusion of the document, just the argumentation. Issues about scope: router addresses only or application aspects? Suggested changes: 1) Change title to "A router addressing model in ad hoc networks" 2) Changes relating how some routing protocols require unique addresses. In addition, the model applies to the widest array of routing protocols. Charlie Perkins: - about title: addressing models not only applies to routers, but also for non-router nodes. Document should be clarified, but title not changed. Jari Arkko: - I understand the argument. I agree to add the "a" to the title, but not sure about "router" word in title. Erik Nordmark: _ agree. We should not limit that to routers. Thomas Clausen: - I thought that we were configuring MANET router interfaces, not other interfaces of hosts. Charles Perkins: - Isn't it possible to have a MANET where many nodes that forward, and others that don't forward (hosts), and these non-forwarding nodes are allowed to acquire an address by an Autoconf-mechanism. Thomas Clausen: - What is the difference to an OSPF router with an Ethernet and hosts connected to that link? Charles Perkins: - A lot if hosts are mobile. Thomas Clausen: - How would this host acquire a topological correct address? Charles Perkins: - we have not yet talked about topological correctness. If you have a MANET with many PTP links served by routers establishing the connectivity, then you could move a host from a place to another, keep same address, and routers have to assure correct routes and forwarding of data packets to that destination. Teco Boot: - new title is better addressing the document is about routers. I would have issues with the address architecture when the routing protocol is not running on a node (i.e. it is a host). In this proposal, we need the routing protocol to advertise the longest prefix. Thomas Clausen: - in San Diego we spent two hours on presentation to understand what a router and a host is, and that we do not need to rewrite host applications and protocols. - I fear that we are reopening issues the WG has already agreed on. Jari Arkko: - do you agree or disagree with the title change? Thomas Clausen: - I agree with the current document as approved by the IESG, otherwise I would have raised issues. Jari Arkko: - continuing changes (4/4), new text: "solutions which apply other addresses than LL is generally of more use". Personal opinion: original text was better. - my view is that WG agrees to the changes (even though not seen as necessary) We already had list discussion, now we are meeting face2face and should decide on a consensus. Erik Nordmark: - We cannot test for uniqueness of LLs, but with global addresses neither. The routing scope and the uniqueness scope is global, but we cannot guarantee global uniqueness. Jari Arkko: - But how about the uniqueness test in RFC4862? Erik Nordmark: - It does not guarantee global uniqueness, just on the link. Thomas Clausen: - you propose that EUI-64 addresses are globally unique by definition. Should we propose to remove DAD from NDP? Erik Nordmark: - No, that's not only there for LLs. Originally, it was intended Thomas Clausen: - If you generate an address using EUI-64, you cannot say it *is* and *is not* unique, it is either one or the other. If you say in the document an EUI-64 generated address is unique, you cannot say it is not unique in another context. Erik Nordmark: - We define things not on what they are, but what their intent is: a global address is intended to be unique globally, but that requires that IANA, RIRs. etc. do not make any mistakes. In case of MAC addresses, IEEE assures uniqueness, vendors. In both cases, they can fail. No difference between these two. Jari Arkko: - But this document does not talk about the intention, it says that we do not have a mechanism to assure uniqueness of LLs. Erik Nordmark: - But we cannot assure global uniqueness either. Teco Boot: - I agree with Erik. Many mechanisms rely on unique MAC addresses. Conclusion of the document needs not to be changed, by modifying the argument in the document. Thomas Clausen: - at least one remark (by Dearlove on the mailing list): objection to modify text from "discourage" something towards "how to do that". The WG should pronounce about it. Erik Nordmark: - Intend is to say that there are globally unique LLs and others which are not. Charles Perkins: - Do you want to add that text to the document? Erik Nordmark: - yes Charles Perkins: - I agree to that. Jari Arkko: - I don't have a problem with that change either. Erik Nordmark: - I came up with new text yesterday, also including some more explanations. Jari Arkko: _ I don't want change too much text. Alexandru Petrescu: - I agree with the latest modification. My opinion is to change the conclusions. But I will not reinsist. Jari Arkko: - Yes, we will not change that, during WG LC, the WG has decided on the issues. Alexandru Petrescu: - As I read it, the text reads "LL cannot be assured to be unique", _as opposed_ to globals. So I support the modification. Thomas Clausen: - I (personally) oppose to one part only, whether there are applications that should run on routers. Applications run on hosts attached to routers, we know how to configure hosts. But we don't know how to configure MANET router interfaces. Only routers are MANET aware. Jari Arkko: - Which point are you opposing to? Thomas Clausen: - The last part of section 6.1 (bottom of slide 13 on chairs' slides) Erik Nordmark: - I do not insist on that one, we can leave it as it was before. The one on top of that slide is important for me. Jari Arkko: - My read of the WG rough consensus is that the title change has been accepted. Thomas Clausen: - If we get rid of the "application" change, I agree Section 6.1. changes, with out without title change. Erik Nordmark: - Do you disagree to the last sentence of that proposed change: "Thus if link-local addresses are used to reliably identify routers then they must be of the modified EUI-64 form."? Thomas Clausen: - No, that was Chris Dearlove's remark. The "must" in that sentence, is that an RFC2119 "MUST" or a normal "must"? It seems it is a normal "must". Jari Arkko: - We need rough consensus, even if Chris' or Erik do not agree. Thomas Clausen: - but I value Chris; opinion. Ronald in't Velt - I agree with the changes in section 6.1 that LLs cannot be forwarded. I suggest to drop it, since it is redundant (the original text in the bottom part of slide 13) Jari Arkko: - I remind that we are not reopening for editorial changes. It is okay if it is redundant, it is not okay if there is an error. Charles Perkins: - I am against the title change which implies that we are not configuring hosts. It is crucial that we develop solutions for non-routers. Henning Rogge: - LL change is okay (first part of 6.1.). In MANET WG discussion about whether originator address of a router is routable / originator address. If the originator address is an LL, then it is not routable, but just identification. It would be contradicting to say that we cannot identify a router by an LL. Thomas Clausen: - We configure interface of routers, not host interfaces. Ulrich Herberg: - Agree, we are configuring router interfaces, not host interaces. We know how to configure host interfaces (DHCP, SLAAC,...). Only MANET routers are aware of MANET characteristics, not hosts, similar to OSPF. Charles Perkins: - disagree with Ulrich, what about nodes in the MANET that don't want to run a MANET RP? Thomas Clausen: - Two ways of doing it: attach to a MANET router interface, or running a dump-down MANET routing protocol, but not forward packets, e.g. WILLINGNESS=0 in OLSR. We don't want to configure interfaces on hosts. INT area people will disagree. Jari Arkko: - We should not add host configuration to the document. Is the title broken? Thomas Clausen: - I like the title better. The old title is broken, because people might that think that the document permits to configure hosts. Charles Perkins: - routers with WILLINGNESS=0 (routers that don't route): that's more broken than the title as it is now. Thomas Clausen: - I agree that this is broken, but you can do it if you want to. There are commonly three (conflicting) definitions of a routing protocol: 1) it runs a routing protocol 2) it forwards packets 3) it issues RA messages. I agree that such a deployment (with WILLINGNESS=0) is not good. I would not deploy it like that. But there are people doing it. I would prefer roaming to another router. Teco Boot: - This document describes how to configure router interfaces. The document has not fully analysed host address model. We could work on this (now or later). But the current document is not about host addressing. So, I agree on the title change. Ryuji Wakikawa: - The old title is not broken, but I prefer the new title. Upper change of 6.1. is too big. It is more a general explanation of how it works in the Internet, not MANET specific. I am fine with these modifications. Charles Perkins: - return this issue: do we allow addresses for non-routers by using mechanisms developed in AUTOCONF. If specific to routing only then someone may bring up solutions for hosts too, then that would be out of scope. What I thought was that the addressing model should be applicable to hosts, too. Why do we enforce that hosts that don't want to run a routing protocol, to run the routing protocol with all its complexities. Ulrich Herberg: - support title change. We should not discuss how to configure hosts, because we know how to do this already. If there is a good argument to think about that, we could do that later, but we should not delay the process of the document. Jari Arkko: - It is already defined elsewhere how to configure. Samita Chakrabarti: - I support upper change of section 6.1. Thomas Clausen: - let's not get stuck on WILLINGNESS=0. Advantage of 2-tier architecture of the Internet is that isolating routing behind an IP hop makes it easier to configure. Henning Rogge: - I agree with title change. We can discuss how to configure hosts in another doc. Jari Arkko: - We will send changes to the list and decide on that. - We should include my changes 1 to 3 (including title change). We will drop the recommendation I had asked for about the configuration. Change top part of 6.1. Add minor thing (instead of configuration, factory programming). Voting: 16 yes, 0 no. Rooms opinion is in favor. Teco Boot: - Please collect complete set of changes, and send. Thomas Clausen: - probably not before monday. Ryuji Wakikawa: - issue closed. Will send consensus call to the mail. ---------------------------------------------------------------------------- RECHARTERING: Thomas Clausen: - presenting strawman charter. DHCP over MANET. Lots of issues raised: centralized vs. decentralized. We can accomplish DHCP in short time. - Propose to add to charter: analysis of problem space for distributed address assignment and service discovery (the latter is similar to NDP/DHCP - gateways, DNS,...). Problem is more complex than it seems, therefore in parallel with DHCP. milestones. Teco Boot: - Is it DHCPv6 or DHCP? - For hardware routers, they only have read-only flash. Duplicate addresses! Wrong choice to use DHCP. Choice too fast. Jari Arkko: - There are ad hoc networks with connectivity to the Internet/gateways etc. and where it is easy to use DHCPv6(-PD) for configuration. DHCP(v6) is used today, the document should just explain how to use them. I am aware that does not cover all cases, but it is fast to be achieved. About uniqueness, routers with non-volatile storage could use random iface identifiers. Teco Boot: - packetbb address compression; overhead for IPv6 can be large. Use aligned addresses (nearby). Likely that people will use it. Danger if relying on central node alone. Jari Arkko: - I don't see a reason why a router running a DHCP server cannot lookup the prefix it has been assigned. DHCP does not cover all situations, it does not work in a distributed case. Teco Boot: - Charter text is not correct. "It is expected that address uniqueness is guaranteed by the central node alone". Jari Arkko: - But the central node will not allocate duplicate addresses. Thomas Clausen: - That is a general problem, not specific for MANET. Jari Arkko: - We could use simple case. There is no absolute guarantee. There will be corner cases. Teco Boot: - I observe these problems every day. Henning Rogge: - We should specify in which scenarios the simple solution works. We should define strategies of how get back information lost after reboot of the DHCP server. Thomas Clausen: - I have used DHCP in my networks. If DHCP Server reboots, it will look into OLSR topology table and not reconfigure these addresses. Alexandru Petrescu: - Reply to uniqueness discussion. Why do we need DAD when addresses are guaranteed to be unique. We would need recommendations when to do DAD. Thomas Clausen: - My version of DAD was using information from the routing protocol. We may specify to generalize that. Carlos Bernardos: - Comment on second charter item. I am against service discovery. Without, one can run DHCP with less complexity. Change "assignment" to "configuration". Problem space vs. solution space? Which are we talking about? I agree with 1st part of charter. Alexandru Petrescu: - Do chairs ask for problem definition or solution space? Thomas Clausen: - WG will figure out what should be done. Carlos is right about 2nd charter point, a conclusion from the problem space analysis MIGHT be that service discovery is too complex (or the opposite). Merits reflection. - Problem space vs. solution space. I prefer Problem Space. Look at the problem space. Important for WG. You are right for assignment/configuration. Jari Arkko: - Agree to look into problem space analysis. Take step backward and understand problems. Use cases, problems, etc. Carlos Bernardos: - We may follow NEMO WG. No solutions were specified. Solution space doc and problem space doc. Ryuji Wakikawa: - We now have address model. Not all autoconf solutions support address arch. Solution space does not apply. Better to look into problem space first. There is other ongoing work in other WGs. Thomas Clausen: - Once problem space doc has been finished, one of the first things to look into after rechartering is solution space. But in that order. Carlos Bernardos: - Clarifying question: That new problem space analysis, how different will it be from the problem space doc we had in Autoconf? Thomas Clausen: - More descriptive then prescriptive. Look at deployment, applications, mechanisms, what are limitations/constraints, rather than you MUST to it like that. Carlos Bernardos: - agree. Alex/Thomas Clausen: - start with problem space analysis, then problem statement. (i.e. "what to do"). In that order. Thomas Clausen: - A DHCPv6-based solution would commence immediately. As well, problem space analysis in parallel. After that, we would recharter (problem statement, solution space analysis). Carlos Bernardos: - Clarification: problem space before problem statement? Thomas Clausen: - we have very different deployments. We need to understand as WG the different requirements/deployments/problems. Carlos Bernardos: - I fear that the analysis will lead to long discussions. Just focus on addressing configuration, and start the analysis later. Emmanuel Bacelli: - I share Carlos concerns. Maybe everyone could describe his deployments and then come up with problem space analysis (as done in ROLL). Henning Rogge: - it may be difficult to split address assignment and service discovery (e.g. assignment of default route). Ulrich Herberg: - agree. But it is not now time to discuss this (should be done in problem space analysis) Carlos Bernardos: - Regarding router discovery, isn't that part of the routing protocol as well? Henning Rogge: - No, you have to have a policy which gateway to use (could have several 0/0 default routes). There must be user policies. Thomas Clausen: - This is a good discussion, which indicates that we need the problem space analysis. Alexandru Petrescu: - Service discovery and address assignment belongs together. Important to me are the scenarios. Other problems (mobile DHCP servers, DHCP server-to-DHCP server ..). Are these other scenarios considered as well? Henning Rogge: - No reason why the border gateway must be DHCP server. Jari Arkko: - It sounds like is there is interest. Is there active work resources? Ulrich - agree to charter. I am willing to participate in first item (DHCP). Thomas - I know at last two groups that are working on that. What we need is a Design Team, editor, actively prodding those who have built it. Teco Boot: - I think that industry will use a distributed solution. I don't see future for DHCP for address configuration. I don't say it doesn't help, but jumping into one particular solution is too early. Thomas Clausen: - Do you think there is sufficient understanding in the solution/problem space to come to a solution within a year? Teco Boot: - I say we should work on DHCP. But don't rely on uniqueness. Your implementation relies on a specific routing protocol. - For IPv6, we can use products we already have. We can do it in parallel. One problem: How to find central server. Jari Arkko: - Teco, do you propose changes to the charter? Teco Boot: - In 1.1, I propose to use SLAAC. Thomas Clausen: - addresses you construct in SLAAC are link-local. Teco Boot: - start with ULAs. Jari Arkko: - My point was to have the use case of getting a global prefix/global connectivity. Maybe there are other solutions, but DHCP seems to be obvious. It's doable. For the more complicated case, the distributed scenario, we will need other protocols. Carlos Bernardos: - I am willing to work on item 2. Boundaries to problem space is needed. - Are we limited to IPv6? Thomas Clausen: - no, just start with IPv6, and then we can easily do IPv4. Carlos Bernardos: - are we working on "connected MANETs" only? Thomas Clausen: - "connected MANET" is wrong term. Jari Arkko: - vote for charter? Thomas Clausen: 13 for, 1 against Ronald in't Velt - I share concerns that problem statement will take more time. Thomas Clausen: - If you are right that people are most interested in distributed solution, we will have enough resources to do it. Ronald in't Velt - It may backfire on us to concentrate on DHCP solution. Thomas (as non-chair) - I have a need for the DHCP solution. Ryuji Wakikawa: - State on mailing list if you support charter / have comments. Alexandru Petrescu: - I will not do my presentation. You can see the slides on the web. ---------------------------------------------------------------------------- Autoconf Mechanism Survey Presentation Update on draft-bernardos-manet-autoconf-survey-05 presents: - history since 2005 - survey of known solutions, classified, analysis of characteristics Update on draft-bernardos-autoconf-solution-space-02 Next steps: - keep updated, merge with other draft? is doc good starting point when rechartering? Thomas Clausen: - read proposed charter rather to produce two goals than two documents. How that will lead into a document depends on the decisions the WG takes. Ulrich Herberg: - I appreciate the work. Vote: many have read the draft Thomas Clausen: - It is difficult to get survey documents into IETF. Once they the survey is published, it is out of date. Maybe better look at general solution approaches that last. draft-bernardos-autoconf-solution-space-02 is more likely to be persistent. Teco Boot: - question about draft-baccelli-multi-hop-wireless-communication - I think this is an important document. Ryuji Wakikawa: - it is not chartered. Please give comments on the document. Thomas Clausen: - There are technical issues with the document. I don't know whether it is the right WG for this document. Maybe INT area. Teco Boot: - best way as individual RFC, directly to RFC editor. Ryuji Wakikawa: - we should not discuss this right now. Emmanuel Bacelli: - I have received comments from Thomas on the doc. Agree with Thomas, that it is not sure where to put the doc. Let's see that. I will continue to work on doc. Ryuji Wakikawa: Closing meeting. ---------------------------------------------------------------------------- - "Router Advertisements for Routing between Moving Networks", 15min Alexandru Petrescu No time for presentation. ---------------------------------------------------------------------------- END