Autoconf Minutes ================= --------------------------------------------------------------------------- Ad-Hoc Network Autoconfiguration (autoconf) ---------------------------------------------------------------------------- WEDNESDAY, November 10, 2010 1300-1500 Afternoon Session I ---------------------------------------------------------------------------- - Notes takers, blue sheets, agenda bash 5 min, Chairs - WG status update (including new charter) 15 min, Chairs - "MANET address autoconfiguration for legacy hosts", 20min, Charlie http://www.ietf.org/id/draft-perkins-autoconf-leghost-00.txt - TBA ---------------------------------------------------------------------------- Minute taker: Emmanuel Baccelli Charles Perkins MANET address autoconfiguration for legacy hosts" ----------------------------------------------------------------- C. Perkins: before I start the presentation, I would be interested in a working group that addresses on non-DHCP based solutions, and I'm not the only one. J. Arkko: In my opinion you are in such a working group. T. Clausen: I agree. We will discuss that later on in this meeting, we have a long slot so let's use this time to discuss that. J. Arkko: What do you mean by allocate a "short prefix"? C. Perkins: the "short" part of it relates to the fact that it could be shorter than /128 T. Boot: can a legacy host ask to use a preconfigured address according to this draft? C. Perkins: it could ask to prolong the "lease" of an address. But something else is needed for other preconfigured addresses. F. Templin: are you talking about a host that attaches a (wireless) link to a router that attaches to a MANET? Does it mean that the host should stay near the router that leases the address? C. Perkins: Not necessarily. A router may have network wide information (for instance with a proactive routing protocol) that would enable to configure the host in a way that is valid even if the host moves to another location in the MANET. F. Templin: Are we not risking routing scalability issues, if hosts all have /128?  C. Perkins: This is a problem we had since the first BOF of MANET, for now there is only flat MANET routing. Let's keep this discussion to MANET wg.  J. Arkko:  I agree that this discussion belongs to MANET. But if every MANET router needs a /64 we have some scalability implications. T. Boot: Would the legacy hosts (for instance any laptop in this room) be part of the MANET? C. Perkins: Yes, that's my hope at least. But the host is not going to participate to the coordination of address allocation. It just requests an address from a router, as usual. The only special thing is that the host does not need to specify which protocol to use to do that. T. Clausen: I think that MANETs are constituted only by routers. And these routers may have hosts hanging off of them. The way I understand this draft is that you can run a MANET routing protocol and legacy host configuration on the same interface. J. Arkko: I agree. The difference is the number of interfaces on MANET routers, and the fact that with this new approach, you may not need to change addresses if you connect to another router, whereas before you had to change address. T. Boot: we have to be careful about the issue of maintaining connectivity to the host when it moves to another location. C. Perkins: MANET routers will heal the situation. Let's take to the list, I don't think there is an issue. T. Clausen: I think we should have this discussion here. I agree with Teco, assuming a host/router can detect that topology has changed and host/router association has changed, then how do the old router and the new router synchronize to change their behaviour? It's a question that is worth asking and for now I am more in favor of changing addresses if a host changes router "attachment". G. Mulligan: We had to invent a lot of new stuff to achieve that in 6lowpan. But I think this draft does not focus on that. It just describes how a legacy host can still work in a MANET. J. Dean: I think dealing with the problem of configuring a host with an initial address can be decoupled from dealing with the problem of hosts moving in the MANET. I don't know if the latter should be solved here. F. Templin: topology might constantly change over time. T. Clausen: I agree with the dichotomy proposed by Justin Dean. The first problem (how to configure a legacy host) is a good mouthful for starters. M. Townsley: this has been done a dozen times (how to deal with legacy hosts). J. Arkko: We have to check out if this is in scope. E. Baccelli: I think the main issue that this draft focuses on is to have hosts and routers being able to communicate on the same physical (MANET) interface. Is that right? C. Perkins: We do not need any logical interfaces. T. Clausen: if two hosts get an address from the same router, will they get the same on-link prefix? If so we have to solve tunneling problems. C. Perkins: not if you get a /128. If you get a shorter prefix, it is from a gateway somewhere. E. Baccelli: we have a terminology problem here: Thomas is talking about on-link prefixes only, while Charlie is talking about a subnet prefixes in general. U. Hergerg: Where do we divide the work that should be done in MANET and the work that should be done in AUTOCONF? T. Clausen: Issues that pertain to addresses should be solved here. Issues that pertain to signaling between routers should be solved in MANET. T. Boot: I'm not interested with something new. Let's reuse the existing protocols. C. Perkins: I think we agree. E. Nordmark: We have to be careful about the differences between IPv4 and IPv6. With DHCP in v4 you have to use a /30 or shorter, whereas with IPv6 you can get a /128.  R. Wakikawa: Please update the draft to clear the points that were raised. We always have good discussions during the meetings, but it too rarely translates into good discussions on the list lately. So please do discuss this soon, on the list too! Rechartering discussions ------------------------ C. Perkins: we have worked for years on non-DHCP solutions that are interesting and that work, so why restrict ourselves to DHCP? J. Arkko: you are indeed encouraged to work on non-DHCP solutions! We have to pick one first and that's why there is the analysis listed as second item in the proposed charter? But we still have time to reformulate the last item of the charter. E. Baccelli: Charlie, are you saying that the second item is not well formulated or are you saying that you already want a third item in the charter that already state that we are to work on a non-DHCP solution? C. Perkins: I just wish that the working group would be allowed to work on a non-DHCP solution. J. Arkko: you are allowed to do that. And you may decide to do several experimental RFCs, and later on standardize the one that has the most market traction. And again, we still have time to reformulate the last item of the charter. T. Boot: there is interest. The chairs should form design teams and let's start! We have already waited too long. Let's just finalize the charter. J. Arkko: Sorry about the time it has taken for the chartering. It's partly my fault. But you can already start work! R. Wakikawa: you can already start work. But we will form design teams once the charter is formally approved. J. Arkko: you can start informal design teams. They will be formal later on when charter is approved. It's up to you. F. Templin: What about routers that already have provider independant prefixes that they carry around, so they don't need DHCP or SLAAC. They are not in scope of AUTOCONF right? T. Clausen: Right.