Working Group: Autoconf Date & Time: Monday 27th July 2009 15:20 to 16:50 Chairs: T.H. Clausen & R. Wakikawa Minute-taker: Christopher Dearlove (with additions by Ronald in 't Velt) Jabber-scribe: Thomas Clausen / Ulrich Herberg =========================================================== [Note: In the text below, DT stands for Design Team, not for Dave Thaler :-)] Ryuji Wakikawa: proposed agenda - Short update on WG status - Update from Design Team (main agenda item) - Short discussion on next steps No changes to the agenda brought forward Working group Status and Update (R.Wakikawa): Slides: http://www.ietf.org/proceedings/75/slides/autoconf-0.pdf DT planned -00 draft in April and WGLC July, actually -00 draft July, and still as individual submission. (draft-baccelli-autoconf-adhoc-addr-model-01) This meeting, principal agenda item is discussing this draft. Running slightly late w.r.t. charter. WG is supposed to finish this work by September. DT Presentation (Emmanuel Baccelli) I-D: draft-baccelli-autoconf-adhoc-addr-model-01 Slides: http://www.ietf.org/proceedings/75/slides/autoconf-1.pdf Two main topics covered by DT draft: 1 - What is an IP Subnet in a MANET? 2 - IP address configuration - Link level connectivity not stable, subnet reduced to single interface and address. - Recommended solution configure /32 or /128. - Addresses unique in routing domain (required by some routing protocols), - Addresses may need to be globally unique. - Configured addresses unique within routing domain. - Open questions + Configuration of additional addresses. + What is the "MANET Link Model". + Can we use Link Local addresses. + Do the addresses have to be globally unique. Discussion Dave Thaler - Consistency with RFC 4291 (in particular section 2.5.1). - Do you believe you have 64-bit interface identifiers that are unique within the subnet prefix? (the 64-bit part being a requirement for all unicast addresses that do not begin with binary '000'). - If the answer to previous question is 'no', do you require prefixes to start with binary '000'? - If that is not the case either, shouldn't the document say that the addressing model will not be compliant with RFC4291? Emmanuel Baccelli - Document does not specify which address ranges to use. Thomas Narten (on Jabber) - There is no reason why Autoconf should not use EUI-64-based interface identifiers. Dave Thaler - If you believe that you ARE compliant with RFC4291, the way to phrase it is, that you have a /64 subnet prefix, but it is only assigned to a single host. Mark Townsley - Aim to be consistent with RFCs. - Beyond scope of document, may need to go that far. Ralph Droms - Document uses same wording for IPv4 and IPv6: "subnet prefix configured on interface"; this is really IPv4 terminology, in IPv6 you have a list of prefixes and an indication of whether those prefixes are on-link or off-link. - Careful wording, to the effect that no prefixes are on-link, can solve the IPv6 case. - For the purposes of this document, adopt similar wording for the IPv4 case, even though this kind of formalism is not commonly used for IPv4. - Distinguish subnet and prefix. Fred Templin - Do we need an address other than link local on an interface? Propose obtaining an address and putting it on a virtual interfaces and have only link-locals on the MANET interfaces. Then we have what RFC1122 refers to as link layer multiplexing. This works for single physical interface as well as multiple physical interfaces attached to to same MANET. For IPv4, you can use link-locals per RFC3927 on the physical interfaces. - Will write this up on the Autoconf ML. Emmanuel Baccelli - Have read Fred's VET document, but deep architectural considerations were not the goal of DT document. Rather, provide a simple model for address configuration. Fred Templin - If DT document says use /32's and /128's, I may not want to do that on my MANETs. Might not fit all cases. - Can you have multiple interfaces on a router attached to the same MANET? Thomas Narten (Jabber) - What Fred Templin describes is what I thought the Autoconf model was for normal addresses. They are either on a virtual interface or on a separate real interface, like an Ethernet. Addresses on the MANET interface are only for making the MANET work. Mark Townsley - Right now just talking about addresses that make the MANET work. Should say this more clearly in the document. Fred Templin - Agree multiplexing does not need to be in this document, since it is already in RFC1122. Mark Townsley - As a general principle: Because you can do something doesn't mean you have to do it. More choices fixed, the easier the job is for the solution that AUTOCONF is to deliver in the end. Fred Templin - As long as you don't stipulate that I have to put a /32 or /128 global address on the MANET interface. Multiple ways to run a MANET. Mark Townsley - But there should be only one for autoconfiguration, lest one would end up with a very chattery protocol in order to try to figure our (for a new router) "which of the multiple ways is deployed in this network now?". Fred Templin - If there is only to be one way, prefers his approach. - Proposed /32 on VET interface. Has it been discussed by DT? Teco Boot - First simple case, MANET router with single interface. With multiple interfaces more complicated. Optimizations later, maybe in a separate document. Fred Templin - Disagrees his approach is complex. Thomas Clausen - There are some characteristics needed to make routing protocols work. There are several ways to satisfy this. Identify what are the requirements. Document does this. Agree with Mark Townsley that need to decide what to do. Applications should see things as normal, i.e. only a/the routing protocols should be even aware of the existence of a MANET. Henning Rogge - Don't think it's good idea to put multiple interfaces on one side as solution for single interface may not work for multiple interfaces, which are common. Not clear that link local addresses for interfaces can solve all problems. Emmanuel Baccelli - Much discussion within the DT on the use of link locals. No conclusion reached yet. Thomas Narten (Jabber) - Keeping all issues open will mean that WG will get nowhere. Choosing a baseline does not exclude other possibilities. Jari Arkko (on Jabber) - Yes, need one model. Think of it as an example. We don't outlaw other ways, but cannot cover all possibilities with a single model. Ralph Droms - Problem with link-local addresses is, that they are *assumed* to be on-link. - What about ULA? Or a reserved centrally-assigned ULA prefix that can be uniformly not marked as "on-link". Erik Nordmark - Two things to decide up front: 1. IF link local addresses are used, what would their semantics be? To me it seems that they should only be sent on the actual link. MANET routers should not forward them. Other people might have different opinions. Thomas Clausen - Isn't it defined that you should never forward LL's? Erik Nordmark - Unless back onto the same link. You could try to finesse that in the MANET space, but let's not do that. - 2. What are the addresses that you actually auto-configure? I think those are essentially non-link-local addresses, whether ULAs for IPv6 or anything else. We still have the issue of physical versus virtual interfaces. It would be good if an autoconf protocol were designed to cater for both. Thomas Clausen - Doesn't that depend on your assumptions with respect to the virtual interface? What the virtual interface will be used for, e.g. to bind applications to it? Erik Nordmark - Two different cases. The first one is like a loopback interface on a router; it only needs a single address. The other one is the interface behind you which has a full subnet prefix. That's actually not a virtual interface, but the question is whether the autoconf protocol can also be used to configure the prefix on that interface or whether you need a different mechanism for that. Emmanuel Baccelli - Interesting question, but beyond the scope of the DT document, which concentrates on what's needed to make the routing protocols work. Erik Nordmark - Intended as directions for the WG. People do want to do things differently, but we don't want a separate protocol for each possibility. Ralph Droms - My earlier point on link-locals was, that if you want to use addresses from a prefix that is not marked as on-link, you cannot use them, because they are assumed to be on-link by default. That's why I suggested using a reserved ULA. Mark Townsley - Can we make a decision? Don't see much value in a link local address. Rather have a global address. Hate to see MANET deployed and unable to get to an interface from outside the MANET. Link local only if easier. Thomas Narten (Jabber) - Ralph: There is more to this. I think (wonder?) if folk are making an assumption that if they have a link-local prefix in their routing table, then normal packet sending (involving LL addresses) just works. By saying use a /128 for "on-link", they prevent LL addresses that are not actually neighbors (because they are MANET addresses) from being routing. [sic] Which is good. But this is too simplistic. You can't just put a LL prefix in your routing table and make things work. If you have multiple interfaces, you can't tell from just looking at a LL address which interface to send the packet out on. Fred Templin - Some applications may need a Link local just as state on the interface, even if never used as source address. Not talking about routing protocols. - VET interface as virtual interface can encapsulate or not as required. Take a look at the draft. Thomas Clausen - Requests link to document on ML. However, not all in scope for Autoconf. Is it being discussed in INT Area?. Fred Templin - Document in RFC editor queue as individual submission, but now created a bis version, that has specifically this proposal. Now aiming for an INT Area submission. Dave Thaler - On the question whether you can use link-locals, I agree with what Ralph said: No, you would want ULAs or similar. In order to specify that, you'd have to be tricky, though. RFC4861 (like RFC2461 before) contains a statement that all interfaces on routers MUST have a link-local address. To still be conformant, you'd have to say that you *have* a link-local address, but that's different from using it. That's why I say you have to be tricky with what you specify to avoid having to revise other RFCs. Emmanuel Baccelli - Seems like we have more or less covered the open issues from the DT document. Mark Townsley - Question for room, should we target autoconfiguration of global addresses for interfaces for operation of the MANET? Should these adresses be global, local, both? Should these addresses be reachable from the Internet? Emmanuel Baccelli - Document concentrates on first phase, getting addresses for making the MANET routing work. Connectivity to/from the outside world comes later. However, if you get global addresses right away, you solve two problems at once. Thomas Clausen - Routing protocols can handle addresses of any scope. Just happen to have considerable experience with using /32's and /128's. - Let's make a decision. Christopher Dearlove - Do want to address nodes in the MANET from outside. - Hope we make a decision, then even those whose first choice it wasn't will work with it. Jari Arkko (Jabber) - I'm in the focus-on-globals camp. (If you are taking hand counts...) Dave Thaler - Have argued against link-local, but as to global or ULA - don't overspecify. Not concerned about individual interfaces not being "pingable" from the outside world. We already have that today with ISATAP and nobody is screaming. Fred Templin - Can use link-local for physical interface, global for virtual (VET) interfaces. Thomas Clausen - Disagree. Some routing protocols need to know which physical interface a packet was sent on. Mark Townsley - Agree with Dave Thaler. Don't specify global or ULA now. Teco Boot - I partly agree on not overspecifying what's being used by specific protocols. There *are* protocols that require link-locals also for MANET. For example, an ND Router Advertisement, which may be used in a MANET, MUST use a link-local source address; OSPF MUST use link-locals. I suggest that we do not break these protocols by specifying ULAs or globals. I am not saying, that we don't need ULAs or globals. Nobody disagrees with this. But let's not specify that we don't use link-locals anymore. They are very practical for some protocols and they can be used without problem. Thomas Clausen - It's not a matter of forbidding something, it's a matter of specifying *a* practical addressing model, as per the charter. Mark Townsley - The more things you have to configure, the more options you have, the harder it will be. Take some things of the table. Teco Boot - Let's take of the table whether or not to use link-locals for routing protocols. When there are routing protocols in place that use them and they work well, let's not prohibit that. Let's go forward, let's work on globals or ULAs, but if link-locals are there and they're being used, that's OK. Erik Nordmark - Is the suggestion that link-locals be configured in the way they're being done today in an IPv6 host or router just based on the MAC address; that they can sit around there and maybe something will use them, like sending RAs? Or is the suggestion that the autoconf protocol will be used to actually configure the link-local addresses? Those are two very different things. In one case you just pick it off of your MAC address. It is locally unique on your link with whoever happen to be your neighbours at that millisecond. You could use it to send packets, which will not be forwarded by any routers. It's a very local thing, this link-local. Thomas Clausen - At a later point, as the network evolves, your link-local may no longer be unique unless you do some magic. Erik Nordmark - The other way people *could* think of link-locals is something that could be used for a multi-hop MANET routing protocol, where I could look at something that came from a link-local source and know that that's 3 hops away. That's a very different model. Thomas Clausen - Nobody should think of link-locals as being visible more than 1 hop away. Erik Nordmark - Another aspect is, what are the uniqueness criteria? Thomas Clausen - That depends. If I want to run my MANET routing protocol, using as the endpoint identifiers link-local addressses, then the requirement is for those addresses to be unique. I cannot accept duplicates. Erik Nordmark - That depends on the routing protocol. Thomas Clausen - The routing protocols that the IETF has standardized or is in the process of standardizing, for MANET. Erik Nordmark - Other protocols like OSPF have a Router ID, that you get from somewhere else. Thomas Clausen - The current crop of MANET protocols do not have that. For link detection, to detect bi-directionality, I need both ends of a packet transmission to be able to identify over which interface the packet was sent and received. Unless I have a way of uniquely identifying those interfaces, the routing protocols won't be operating correctly. If that identifier is a link-local address, then that address has to have the property of uniqueness at least within a two-hop scope. Other protocols may have other requirements. Erik Nordmark - It's one of those zero-one-infinity things. It's one thing saying this is unique when I run DAD, a millisecond later it might not be unique. Whether you say I want this to be unique as the MANET evolves and other nodes come into reach OR you say I want it to be two hops instead of one. That's a completely different ballgame. Thomas Clausen - It needs to be unique within two hops AND it needs to be unique over time as well. Whether link local or not, it must have those properties. Otherwise you are going to break the MANET routing protocols. Teco Boot - Property only of OLSR, NHDP, not of DYMO, OSPF. It's not defined how to autoconfigure a Router ID for OSPF. Thomas Clausen - It is required that you can uniquely identify each interface, communications endpoint. Teco Boot - Only for those protocols, not for a bunch of others. Thomas Clausen - Even in OSPF you are able to uniquely identify a given interface. But you use a router ID and interface number. Teco Boot - For OSPF, this has nothing to do with link-locals. The interface ID is just a number local to the router. Your statement is true for OLSR, for NHDP, but not true for other protocols. Let's be accurate. Mark Townsley - If we are to have *one* autoconf protocol, we need to choose the lowest common denominator. If one protocol needs something, then need to provide it. Erik Nordmark - There is another point we should capture. You might want to send a Router Advertisement for whatever reason. There is no reason to forbid having a link-local address, as long as you state what the semantics of that address are. It is only unique on the link the moment you tested it. It might be non-unique a millisecond later. It means nothing beyond the first hop, ever, and packets with those addresses don't get forwarded by any router. As long as you state all that, somebody designing a new routing protocol can decide whether to use those addresses or not. It seems many routing protocols need something better than that. Fred Templin - Agree. IPv6 interfaces can have multiple addresses. No guarantee that link-locals stay unique. They can be probabilistically unique, if we do e.g. a CGA assignment or a MAC EUI-64 assignment. Just putting a link-local there, doesn't mean we are going to use it for a purpose that requires uniqueness. - Can put MANET local addresses, as previously considered, on physical interfaces and global address on the virtual interface. Thomas Clausen - Agree with the latter. Mark Townsley - Can allow link local - but only if doesn't make the autoconf protocol more complicated. Erik Nordmark - That's why I want to make sure we write this down in the document, even if it is a duplication of what is already written elsewhere. Uniqueness properties, the fact that they are not forwardedi, etc. Thomas Clausen - (Persuades Erik to contribute strawman text for the above on the Autoconf ML). Fred Templin - Minor point: with IPv6 you can have LLs and globals on the same interface. With IPv4, you're supposed to remove link-local addresses when you have addresses of greater scope. Emmanuel Baccelli - Can reference other RFCs; anything to make the DT document shorter. Erik Nordmark - It's more subtle than that; we have the link model issue. Some people might think a MANET is a link and so link-locals should work. That's the reason we want to state clearly that LLs don't work the way you might think. - What about IPv4 link-locals? Emmanuel Baccelli - Thinks concensus was to skip those. Mark Townsley - Can we sum it up and have nods: Link locals may be configured, warning text from Erik N. on scope issues, not used for routing. Teco Boot - Some protocols MUST have link local addresses. There are three experimental MANET extensions for OSPF out there. Some important players are working on this. Cannot ignore this. - We should continue working on ULA and global addresses. Why this urge to prohibit link- locals? Suresh Krishnan - Agree with Erik Nordmark, looks like link local address, but isn't really. It's more like "interface-local". You cannot use it as a source address for an RS or an NS. You don't even know if it is unique. Teco Boot - Link local only for single hop information, like for example resolving Layer 2 addresses of nodes in range. All multi-hop stuff done with ULAs or globals. - How to do DAD is "solution space", however don't see much difference in uniqueness detection etc. between link-locals and globals. Either we find some mechanism or we accept that there will be a very small chance to have duplicate addresses. Thomas Clausen - Clarifying comments on OLSR etc. can handle link local addresses, as long as they are unique within two hops away. Ryuji Wakikawa - Maybe we should just ask the WG how many people think link-locals are useful and whether the WG should look at the use of link-locals in the DT document. Fred Templin - Observes that a use case analysis seems to be missing. We all seem to have this notion of what a MANET is and what we use it for. But have we ever looked at automobiles, planes, use inside a corporate enterprise network? We all may have very different notions of what it means to do MANET networking. Haven't seen this addressed in this group yet. In some use cases, there's legitimate use of link-locals. Thomas Narten (Jabber) - Arguing again on what a link local address is? Deja vu, 20 times over. Ralph Droms (Jabber) - Not on the audio. I thought we concluded that LL address is incompatible with no prefix-based direct packet delivery? Alex Petrescu (Jabber) - Agrees with that. Not sure DT agrees with that. Ryuji Wakikawa - Need to agree in which direction the WG should go. Need to formulate some questions. Thomas Clausen - The first question is what would be more appropriate to recommend w.r.t. the addresses needed for routing protocol operation: the use of link-locals versus globals or ULAs? Mark Townsley - Thought we had agreement half an hour ago that link locals wouldn't even exist. Then they came back, but with so much warning text around them, that nobody in their right mind would use them, Then someone said, he would use them for the routing protocol anyway. Thomas Clausen - Dave Thaler observed that there RFCs mandating the existence of link-local addresses. Erik Nordmark suggested to put so much warning text around their usage, that nobody would. Then, let us as a group decide that the addresses we care about and will configure are globals or ULAs. Mark Townsley - Proposal: link locals exist, warning text, autoconf will work on configuring ULA/global addresses. CHAIRS CALL FOR CONSENSUS IN THE ROOM: shall AUTOCONF: - accept that link local addresses exist, but not configure those, warn against their properties being unguaranteed and work on the configuration of ULAs or globals for use within the MANET Hum is in favour of this - needs to be validated on the mailing list. Teco Boot - Don't know what the question was. Do we simply forbid the use of Router Advertisements in MANET? - that's a clear question. RAs mandate the use of link-locals. Thomas Clausen - Think that is a different question than the one that was asked. Ryuji Wakikawa - If a MANET protcol needs Routing Advertisements, we can extend the existing router neighbour discovery protocol for that; but that's a solution space discussion. Henning Rogge - Maybe we can just agree that we need a way to determine a mesh net-unique address. Maybe we just need it for the virtual interfaces for some routing protocols; for other protocols we might need it for the interface IPs. But we need a stable way to get these addresses. Some protocols might even have contradictory requirements for the attributes of their interface addresses, but most want at least one net-wide or globally unique address. Maybe a unique address from some kind of pool. The routing protocols could specify whether they run this algorithm for every interface or use link-locals to talk to their neighbours, while using the algorithm to get virtual interface addresses or router IDs. We need a method to autoconfigure an address that is unique over more than one hop and we want to get this address automatically from some pool; that's something that all routing protocols will have in common. Thomas Clausen - Are you are arguing for or against the outcome of the 'hum' we just had? There seemed to a consensus. Are you contesting that? Henning Rogge - My problem with the proposal is that it combined several things. One of them is the autoconfiguration of MANET-unique (or globally unique) addresses. In the Internet-Draft, I would not like to combine this in all cases with interface configuration, because there seem to be some routing protocols that must use link-locals. Emmanuel Baccelli - Beg to differ. Don't know any that do, not even OSPF. It just says you *can* use link-locals. Teco Boot - Thinks it's MUST for OSPF. Thomas Clausen - The important thing is to scope the problem down so we can make progress. Ryuji Wakikawa - In the document we may say that link-locals exist, but with some warnings attached. If you can live with those, you can go ahead and use them. - This WG will not discuss link-locals for the purpose of autoconfiguration. Fred Templin - It's fine to have text that says "not recommended", "should not". Consenting users can go ahead and do it, if they know they won't get themselves into trouble. We are not forbidding anything. - This comes down to use cases again. Whether globals are needed depends on whether an application are going to be hosted on the MANET router or not. Some MANET routers might not host any applications. Do we have the same answer for those types of MANET routers as for MANET routers that host applications? Alex Petrescu (Jabber) - The /128 recommendation forbids link-local addresses. Ralph Droms (Jabber) - Thought we were dropping that /128 condition as conflicting with existing RFCs. Alex Petrescu (Jabber) - This should be made very clear. Christopher Dearlove - I thought we simply were saying, let's configure ULA/global addresses, link local addresses are orthogonal to that. Thomas Clausen - That's consistent, but with the addition that if link-locals are generated, the caveats hold that Erik N. will provide text for. - We have to write this down and confirm it on the mailing list. Thomas Narten (Jabber) - IMO, /128 does not conflict with existing specs. We are blurring and confusing various issues. You can have a /128 for on-link prefixes and still have a 64-bit Interface IDs. Next Steps: CHAIRS CALL FOR CONSENSUS IN THE ROOM: shall AUTOCONF: - accept the DT I-D (draft-baccelli-autoconf-adhoc-addr-model-01) as WG document? Hum inconclusive, did not support adopting draft-baccelli-autoconf-adhoc-addr-model-01 as WG document. Chairs request: - comments from those whose hum did not support the I-D, in order to be able to incorporate those in the I-D and make progress - the DT to issue a -02, adapted taking the comments from the meeting into account. Chairs will call for consensus on such an updated document on the list.