AUTOCONF Minutes / Strawman ================ WG chairs: Ryuji Wakikawa & Thomas Clausen Jabber-scribe: Ulrich Herberg Minute-takers: Fred Templin Mark Townsley Thanks to our Jabber-scribe and minute takers. These final minutes have been compiled by the chairs from the exellent notes provided by Herberg/Templin/Townsley. The WG expresses its profound thanks to the scribe and minute takers, both for their willingnes to serve, and for the quality of the scribing/minutes provided! 0. Agenda (revised) ------------------- ----------------------------------------------------------- What: Autoconf WG Where: Arcacia West When: 1740-1940 Afternoon Session III ----------------------------------------------------------- 1. WG status and update (Wakiawa / Clausen) 2. Ad Hoc Network Adddressing Model a DT/ Baccelli / Townsley proposal b Bernardos / 't Velt proposal 3. Background (brief) on MANET interfaces and wireless communication (Perkins) 1. Status update (Chairs) --------------------------- DT document has been adopted as WG document, WG should move on. ~20 people expressing themselves, ~70% supporting on this - as BASELINE Several issues have been raised: o LL address treatment Differ in the autoconf wg doc and Carlos/Ronald doc Will be discussed during todays meeting o Prefix lengths Current autoconf document suggest /32 and /128 - there are cases where this is required; the wg doc and Carlos/Ronald doc differ will also be discussed during meeting o MANET interface definition - discussion on what it is goes long back. Objective is not to come up with a definition of a MANET interface; this is currently only "for educational purposes" Thomas Clausen (floormike): Notice that whichever direction this takes, we are not "going down the rathole" of link/interface descriptions. 2 a. DT document presentation (Baccelli): Ad Hoc Network Addressing Model ----------------------------------------------------------------------- (draft-ietf-autoconf-adhoc-addr-model-00.txt) o Justifying the situation of /32 and /128 Fred Templin: How aobut just saying "Router interfaces" rather than "host" interfaces on the same link? Dave Thaler: There is a right way to say this. what you are trying to accomplish is, that interfaces should not appear as if on the same link. Apparent conflict with RFC4291 section 2.5 and 2.5.1. Instead, say "It follows the off-link model, there is not subnet prefix" - this is the proper terminology to employ. Emmanuel Baccelli: This changing nothing in the actual solution of /128 /32? Dave Thaler: No, it’s just being phrased improperly. It can be said in a way that is consistent with the RFCs. Discussion of Link Local addresses - why they are "discouraged" in the draft; rather, why other addresses are recommended Teco Boot: Agrees on the "no fwd for LL src'ed addresses" For other two bullet points there is a lot of discussion, even if the result is the same. Let’s remove: "no discrete on/off link events to trigger DAD" "Uniqueness across several IP hops links" Ryuji Wakikawa (chairmike): Teco has a use for link locals Teco Boot: We need to close the issue on LL. If there is no good reason to work on LL, fine, but remove the wrong text. The DAD point applies to all address types, its not just an LL problem. Why call out LL? Emmanuel Baccelli: You may have the impression with LL to have different properties. We should not use LLs for that which they were not designed for, that's all. Dave Thaler: Not sure what you are asking, but the RFC DAD (2463) says that it does not apply to all links...that some of the mechanisms, ND, DAD etc, require multicast. Many links don’t support multicast. So, some parts of the RFC does not apply to all links. So, either "not having one" or "specifying a different one" is not in violation of the RFC. Like, 6to4, Teredo/ISATAP, etc. which do not use DAD because IPv4 addresses are managed for uniqueness. Teco Boot: The RFC… "DAD MUST be performed on all address types. " Dave Thaler: Some sections do not apply to all address types. So, the "MUST" Teco is referring to, does not apply to all address types. Reading from RFC2461: "any doc that specifies v6 over some odd link type, it is up to that doc to specify it [DAD]" Thomas Clausen (chairmike): Summarizes discussion, and states that the conclusion is that (i) "we are not working with LLs in [autoconf]. Not that they won’t exist" (ii) we have a disclaimer about using LLs from the proposal of Erik Nordmark text in Stockholm. Is that clear or not? Is it too much? How would you change that? Alexandru Petrescu (via Jabber): If we MUST be offline [off-link?] and /128, we implicitly rule out link-local Dave Thaler: I think the link-local as described in the document is good. Essentially, it states "you can configure them, but they are not useful" - "link locals are always onlink, and therein lies the problem". Am happy with the text in the document. Fred Templin: Link-locals can be useful for unnumbered modes where the stack needs the address - if you need some address on the interface, you can put a link local just to keep the software happy. Thomas Clausen (floormike): Teco, what needs to be extracted from the document on LLs? I agree with Dave Thaler otherwise. Teco Boot: 3 claims: (1) uniqueness. Interface IDs guarantee uniqueness for globals and link-locals as well, (2) some routing protocols require 1hop communication, but since the txt says "forwarding" I’m OK. (3) remove DAD reference because it applies to non link locals too. But, let’s end the discussion. Thomas Clausen (floormike): Point about EUI-48 uniqueness, brought up as a catch-all solution also enabeling LL uniqueness "effortless": Can it work, e.g., on Bluetooth where there are only 7 possible interface IDs? This is a big *if* - can we get something unique from an interface ID? If not, 4861/2 do not protect us in MANET. Teco Boot: wants to guarantee uniqueness for global addresses also using intf IDs. Charles Perkins: If you can ensure global address uniqueness, can you ensure link-local addresses? Not necessarily. Mark Townsley: No you can't - however if you have a burned-in and guaranteed unique value, then you can use it for any scope address Charles Perkins: You should never pass link-local address info off-link. To guarantee global address uniqueness, you can pass it around in the payload of packets that are fwd'd. You can do that with globals etc., but NOT with LLs. Mark Townsley, Charles Perkins and Dave Thaler: agree that the mechanism should not have to work for LL's Dave Thaler: With these undetermined link characteristics, there are no on/off-link events - it is not a requirement to do LL duplicate detection. Jari Arkko: Everyone agrees that we don’t need to "use" the LLs. We have a long list of reasons why we don’t "use" them… so the conclusion remains the same. Ronald in 't Velt: We don’t "use" them for what? Jari Arkko: Use them for sending on the link and through routers Dave Thaler: Some protocols only work on linklocals. The things that only work with link locals are the same kinds of things that we are to define…. Or at least look at to define. Thomas Clausen (floormike): 5-6 years ago Dave Thaler made us realize something: as long as "regular applications" saw a classic IP hop to a router, and not a MANET, these applications were OK, and that only applications running on interfaces on the MANET router would have to be MANET-aware (i.e. designed for those "undetermined link characteristics"). Important to recall that, because it is true. Ronald in 't Velt: Are we using ND? Charles Perkins: That’s solution space Ronald in 't Velt: Let’s be practical Charles Perkins: No guarantee that ND will survive the eventual product. Also, wants to point out that we are in the addressing part of the discussion here. Carlos Bernardos: Are we modifying IP to make it work over MANET? Dave Thaler: DO we have a list of things that Require LL. RFC 4903 gives this list (or at least a close approximation of it)? Emmanuel Baccelli: Next Steps Continue discussion and identify clarifications Teco Boot: Open items: LL not an open issue any more (Yay!) Shall we deal with Global addresses? Mark Townsley: Seems (unless I am missing something) that it is obvious that we should, and also how, at least as far as the addressing model goes. It may be as simple as adding that "obvious paragraph" to the document: "Global if you can, ULA if you can't"? Jari Arkko: Seems also obvious that without notions on getting addresses that applications can use through to the routers, [autoconf] has not much purpose. Thomas Clausen (chairmike): In the interest of "doing the hard stuff first", we've asked that the document thus far focus on the "MANET interfaces". It is clear that once we have that fleshed out then, yes, we will want to "state the obvious" (to paraphrase Townsley): that addresses that applications might use should be made available to routers. Editors will add text that states the "obvious" case that after getting addresses necessary for the manet to run, addresses necessary for attached hosts and applications will be obtained by some method outside the scope of the document. Those addresses with be "global if possible, unique local if not." 2 b. Bernardos / 't Velt document presentation (in 't Velt) ----------------------------------------------------------------------- (draft-bernardos-autoconf-addressing-model-01.txt) Key points: o complimentary document - not competition o motivation and scope - describe practical IP addressing model o non-MANET interfaces out-of-scope o what are the autoconfigured addresses used for? o source addresses of routing protocol packets o addresses inside routing protocol packets for ndisc and routing o next-hop L2 address resolution o what about running app's over MANET interfaces? o if MANET-local only, ULAs OK. Otherwise, need globals Charles Perkins: What happens if two nodes with overlapping addresses appear in the same MANET? Thomas Clausen: You can do things that can prevent overlapping prefixes, but why have something other than /32 or /128 Fred Templin: You *can* do shorter than /32; /128, because the spec does not *preclude* it. Dave Thaler: The must is not exclusive (in terms of configuring non-overlapping prefixes) Emmanuel Baccelli: If you want to do something other than /32; /128 up front, then you are being more restrictive. Agreeing to disagree Ronald in 't Velt continues presentation: o Link-locals - mandated by RFC4861/2 o at least OSPF-MANET uses LL's o configuration of IPv4 LL not forbidden Mark Townsley: o IPv4 LL is important and needs consideration. o add paragraph on scope of addressing model - not just routing but also forwarding Thomas Clausen (floormike): o MANET interfaces are "wierd", things that bind to them need to be careful - we discussed this already at IETF67 o But, doesn't think this is something that belongs in the addressing model Ryuji Wakikawa (chairmike): o We don't want to repeat the same discussion again and again, but please continue discussing on the list 3. Perkins: Background (brief) on MANET interfaces and wireless communication ----------------------------------------------------------------------------- (draft-bernardos-autoconf-addressing-model-01.txt) Key Points: o Wrote this draft with Emmanuel Baccelli several years ago draft-baccelli-multi-hop-wireless-communications o Wireless media are not new, but not like ethernets either o issues: - asymmetry, time-variation and non-transitivity - what is a "neighbor"? - general terminology issues - radio range and wireless irregularities - what does it mean for two nodes to be "adjacent"? - even though A can hear B, B may not be able to hear A (asymmetry) - at T0 A can hear B, but at T1 it can't (time-varying) - if A can hear B and B can hear C, A and C can't necessarily hear each other - hidden terminal problem - B can start transmitting to A even when A is already engaged with hearing from C (interference results) - exposed terminals - node A might not be able to send to B while C is in the process of sending to D (an unrelated packet transmission) - MAC layer support - e.g., 802.11 RTS/CTS Ronald in 't Velt: o 802.11 RTS/CTS doesn't work for multicast Charles Perkins: o nobody uses multicast" :^} Ronald in 't Velt: o But, RTS/CTS not secure and uses bandwidth papers have been published on MAC-layer scheduling Charles Perkins: o IP is unaware of MAC-layer issues like hidden/exposed terminal, etc. o IP is "best effort" implies "retransmissions OK" o time variations - state can change in time o Conclusion: - wireless media not at all new, - but not very similar to Ethernet either - and we're still arguing about what a link is 4. Concluding Remarks (Thomas Clausen) ----------------------------------------------------------------------- The working group document needs to pick up four items: 1) include addresses which are necessary for operating network (for routing protocol, forwarding) 2) include addresses which are necessary for running applications on hosts attached to routers 3) remove DAD as a reason for not using LLs, there are, as Jari stated, plenty of other reasons 4) Clear up the terminology of the /32 and /128 mode of operation according to Dave Thaler's points on having no on-link prefix The plan forward includes: o Take the summary of this meeting to the list o Publish minutes asap o As we're behind schedule, we will want a short consensus call on list within a week of the minutes, in order to decide upon these 4 issues above o Issue updated WG document document, have WGLC et. al. such that we can get it to Jari Arkko (responsible AD for [autoconf] before the Christmas season.