|
Minutes of meeting from Multi6 interim meeting
============================================== Date: 2004-06-14 Place: Santa Monica, Loews Hotel Agenda: 1. IPR reminder, logistics, agenda bashing (co-chairs, 10 min.) 2. Charter review (co-chairs, 5 min.) http://www.ietf.org/html.charters/multi6-charter.html 3. Review "Things to think about" draft (Eliot Lear, 45 min.) http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-about-03.txt 4. Review threats draft (Erik Nordmark, 45 min.) http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.txt 5. Review + discuss future Architecture draft (Geoff Huston by phone, co-chairs, 2 hours) http://www.ietf.org/internet-drafts/draft-huston-multi6-architectures-00.txt 6. Open discussion on the impact of various categories of solutions (co-chairs, 1 hour) 7. Conclusions of meeting and where to move from here. Minutes of meeting: Jens Kristian Kjaergaard with support from John Loughney, Kurt Erik Lindqvist, Brian Carpenter and the Jabber scribes in the form of Iljitsch van Beijnum, Bill Fenner and Joe Touch. Minutes edited by Kurt Erik Lindqvist and Brian Carpenter. Slides used as input can be found at http://ops.ietf.org/multi6 Jabber log at http://www.xmpp.org/ietf-logs/multi6@ietf.xmpp.org/2004-06-14.html Audio/video archive at http://www.muada.com/multi6streaming2.php For A/V streaming see http://ops.ietf.org/lists/multi6/multi6.2004/msg00902.html Attendees : Kurtis Lindqvist, kurtis@kurtis.pp.se Jens Kjaergaard, jens.k.kjaargaard@ericsson.com John Loughney, john.loughney@nokia.com Thomas Narten, narten@us.ibm.com Michael O'Neil, mjo@arin.net Erik Nordmark, nordmark@sun.com Dave Crocker, crocker@brandenburg.com Roy Brabson, rbrabson@us.ibm.com Eliot Lear, lear@cisco.com Joe Touch, touch@isi.edu Mikael Lind, mikael.lind@teliasonera.com Josh Chao, hcc@mail.ndhu.edu.tw Qing Li, qing.li@bluecont.com Jean-Francois Tremblay, tremblay@hexago.com Tomohiro Fujisaki, fujisaki.tomohiro@lab.ntt.co.jp Jim Bound, jim.bound@hp.com Yanick Pouffary, yanick.pouffary@hp.com Jordi Palet, jordi.palet@consultintel.es Brian Carpenter, brc@zurich.ibm.com David Kessens, david.kessens@nokia.com Iljitsch van Beijnum, iljitsch@muada.com Marcelo Bagnulo, marcelo@ing.uc3m.es Jukka Ylitalo, jukka@nomadiclab.com Aaron Falk, falk@isi.edu Bill Fenner, fenner@research.att.com Joe Touch, touch@isi.edu Jeff Barrows, jeff@barrows.net Chris Christou, christou-chris@bah.com Ali Karimi, aki.karimi@ieee.org 1. IPR reminder, logistics, agenda bashing (co-chairs, 10 min.) =============================================================== Brian Carpenter commented on the intention of the meeting agenda and briefly addressed the alternative schedule put forward by Iljitsch van Beijnum on the multi6 mailinglist. A set of questions were prepared by Kurt Erik Lindqvist (Kurtis) and Brian Carpenter for agenda item 6. Brian Carpenter gave a reminder of the IETF IPR rules as updated by RFC3667 and RFC3668 and encouraged people to follow IETF etiquette by: - reading the drafts before commenting - taking turns at the microphone - signing the blue (white) sheet - noting that meeting minutes will be public Iljitsch van Beijnum encouraged us to complete one issue before going to the next during the discussion. 2. Charter review (co-chairs, 5 min.) ===================================== Brian Carpenter (BC) reviewed the current working group charter defined in http://www.ietf.org/html.charters/multi6-charter.html. Brian Carpenter noted that the WG has only produced RFC3582, that has (possibly conflicting) goals that aren't strict requirements. The "Multihoming in IPv4" draft has expired and kurtis intends to issue a revised version before the IETF San Diego meeting. Aaron Falk(AF): We have received some other documents, but not evaluating, and not all drafts seem to be listed. BC: There are to many to list them all Kurtis: There is a list of all multi6 related drafts at http://ops.ietf.org/multi6 - if there are errors, tell kurtis. Someone: The working group webpage should be updated with a link to this page. BC: Yes, we will ask the secretariat to update the page [Note added after the meeting: this has been done.] AF: There is some important charter stuff that is not in the new charter BC: We are not chartered to actually work on solutions, and when a WG later is, it might not be this one or even in management/ops Area. 3. Review "Things to think about" draft (Eliot Lear, 45 min.) ============================================================= This agenda item was a review of: http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-about-03.txt Elliot Lear (EL) presented the changes and open issues. Slides at ???????????????????????????? EL: Not very many updates since last meeting, should not take full 45 minutes. Thanks to Marcelo and Pekka. EL: First change, if using shim layer aproach. Is fragmentation done above or below shim layer? And can you piggyback on existing fragmentation? If you can establish a context while doing communicaiton this could reduce latency, and this would be very valuable. Saving roundtrips is good, especially on "call" setup. IF you are doing the shim on top of fragmentation that can be troublesome, especially with UDP. Joe Touch(JT): "Call" setup? I am at the IETF. Is roundtrip saving a specific issue for multi6? Seems to be specifically tailored to a telephony type of environment. Why save roundtrips if noone else in the stack is doing it? EL: A phone regulatory limitation JT: That is the point, IP is best effort. This is a red herring. EL: This is not a requirements draft. If you address this it is a nice thing, but doesn't disqualify solutions that don't meet this. BC: <chair hat off> Hard to dismiss phone requirements. Disagrees with Joe, the world is changing whether we like it or not. Dave Crocker(DC): Sometimes we can replace bad requirement with a good one. You don't delta one view of the world to another, replace yes but not delta. Latency and roundtrip counts not just for call setup in a telephony environment. EL: No phone vs internet debate, latency counts. Better not to use these examples. Margaret Wasserman (throught Jabber, MW): Are the presenations on-line? BC: No [Note added after the meeting: Bill Fenner contrived to upload most of the slides to a temporary site via GPRS!] It was agreed to avoid the phone terminology and move on. EL: I added the MPLS-TE part on the request of Pekka Savola. Iljitsch van Beijnum (IvB): Why layer2 stuff? We are working on layer three here. EL: Right, but there may be some subtle interactions. Not sure. Traffic Engineering implications of multi6 cannot be ruled out, which makes it a valid item in a things-to-consider draft. Few of the new requirements were my idea. The list on the screen are changes made in this version and has come as feedback from others. Someone: How does your solution interact with DNS caching semantics? EL: Randy in the meeting in Minneapolis pushed for operational concerns document. KL: General comment. With DNSSEC there seems to be circular dependencies that we might be careful of as well. But others here know more about this than I do. EL: Yes, that is Margaret's pet-peeve, circular dependencies were already in the first draft. Example was what if the DNS server is multihomed? It would be could if DNS servers could avail themselves of multi6. EL: Another new issue, impact on in/egress filtering. EL: A word about applications. Eihter the solution odes not require any changes, in which case the application only deals with IP addresses, or things that look like IP addresses. Or the changes are hopefully clearly documented and relatively simple code fragment diffs might be nice. HIP makes IP addresses opaque as it fits in 128 bits but it doesn't really look like a regular one, may be ok for some apps not for others. EL: Logging issues aren't really mentioned. EL: If you make addresses opaque to applicaitons, how do applications keep track of who they're talking to? We may need to theorize but not actually create an API. AF: Random thoguht. If you are debugging, I can ping an IP address, may want to ping an identity? EL: Yes, interesting. Two pices of information. Ping-like, traceroute-like. I.e see which addresses are involved in reaching a certain identity. DC: Important, I was considerably dismayed as an apps guy. I would like to see code diffs for apache to implement locator/identifier split. BC: <as co-chair> maybe push to area-directors? <co-chair hat off> Maybe imposing that *nothing* changes is hard, but should be careful with requiring to change applications. There was much pain in apps land when the basic IPv6 changes where made to the stack. [Editing note: did I say stack? Surely I meant socket. - BC] TN: Be careful about ruling out of scope. Useful to list stuff, but in the end make tradeoffs. This implies API must use addresses. BC: We clearly have an action item to get handle on boundary conditions. KL: Do we want it in this document? BC: Probably not. We should talk to application ADs. And we hope our AD is listening... John Loughney (JL): I support Brian. Not talk aout specific applications, but about things like callbacks ans so on. Solutions should consider this. Someone: We need several lists. We need to know wheter identifiers change or not, whole bunch of stuff. We need to collect it, but not neccessarily right now. EL: Note that this talk is a diff. There are other referral issues in the draft already. EL: Moving on, security. Does your solution introduce time-based attacks that were not previously possible? Add referrence to threats draft. We'd like to follow hippocratic oath: first do no harm. I have just asked questions, but now rather spend time on solutions. IvB: I am concerned that solutions may create strong dependency of the Internet on DNS. Application stuff was fun, but what about DNS? Today I can do stuff without DNS. May not be able to in the future, regardless of the circular stuff? EL: Please provide text. EL: And I am done. BC: Do people in this room want to adopt this document as a WG document? We can decide if we want to publish it as an RFC in the future. The meeting unanimously raised its hands to adopt the document as a WG document. BC: This has to be verified on the list, and we will later decide if we will freeze the draft. 4. Review threats draft (Erik Nordmark, 45 min.) ================================== This agenda item was a review of: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.txt Erik Nordmark presented the draft according to input in presentation: http://ops.ietf.org/multi6/interim-04/multi6-interim-threats.pdf JL: One concern about new identifier space. What's the role of authentication and authorization for that space? Do we need to AAA that ID and how does that relate to the IP address? Does this bring up any new security threats? EN: We are assuming that an ID at some level, be it an identifier or locator can speak for itself at some point. The basic concern is proving ownership of the id. Inherently you're authorized to speak for yourself, you can go further with authorization, especially authorization to send a locator to avoid DoS. I don't know wheter it's "ownership" notion or "authorization" - "ownership" is simpler. JL: Authorization can live higher. We need to be careful with implying too much about identifier layer. Final note, what about binding between ID/Loc? Would it be possible that you're authorized on one IP address but if you change to a different connection how do you get your identifier still valid for that new connection? EN: It might make sense to come up with more context - there may be some intro material for the draft. TN: Using authorization words helps clarify who is being authorized, clarify e.g. address authorization/ownership. TN: When to publish vs. when to sit on doc. If the WG thinks they're done, it might be useful to push it through IESG to get the IESG review - not a crime to publish an RFC and then update it a year later. DC: I suggest we distinguish between IPv4/TCP today (i.e., threats that we tolerate) vs. ones we are creating with multi6 vs. something that's an opportunity to "improve" the current infrastructure since we're changing things already. Some of what I've heard today sound a whole like trying to "fix the Internet" EN: I'm just trying to make sure we understand where we are today with the IPv4 Internet. DC: Yes, just distinguish between what threats are new and what are part of the existing world. BC: <chair-hat on> It's ok to say "this is a threat and we're not going to fix it". JL: Make sure we put the limits as to what we're going to authorize/authenticate. The use of address as authorization has happened; how do we identify but not solve fixes to this? EN: pointed out that although the concepts of on-path and off-path attackers are well understood potential dynamic or pass-by on-path attackers needs further considerations. EN: Appendix B contains input to the security analysis of some of the proposals. Is this the appropriate place? BC: Suggest to leave "as is" and review in 6 months. Elliot Lear mentioned that mobility related threats are new compared to existing treat scenarios. BC: Do we think the WG should accept Erik's draft as a WG draft? The draft was accepted as a working group draft with most of the room for, some abstains, and no against. To be confirmed by the WG on the list. 5. Review + discuss future Architecture draft (Geoff Huston by phone, co-chairs, 2 hours) ================================================================ This agenda item was a review of: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-architectures-00.txt Geoff Huston presented "Architectural approaches to Multi-Homing for IPv6" remotely on phone from Australia. Slides at http://ops.ietf.org/multi6/interim-04/2004-06-10-multi6-arch.ppt Geoff Huston (GH): This is an idividual submission I hope will be accepted by the working group. GH: If you can get PI space from your RIR you can have multihoming, but this isn't easy especially if you're small. So then use a more specific of PA space. This is often a backup solution, no good load balancing. GH: The issue is that if you want a solution that can work for decades you can't assume the number of mulithomers is going to be small, there may be millions of other assumption we have to make: we don't know the scaling issues with current routing, both protocols and routers we have now. We can use routing approach for multihoming but it may not scale adequately. The question is if there is an alternative approach. GH: Take 2 address blocks, one from each provider. Communication depends on reachability and policy. Can I do load balancing OR primary/backup configuration? Generic problem: local host in multihomed site, ISPs a and b, internet cloud, remote host. GH: There are a number of things to be aware of. GH: 1. Two means more than one, can be several but two is the minimum. GH: 2. First hop must be different for first hop, don't know about the rest and trying to know this isn't a goal. Second thing to know: this isn't mobility, homeless or otherwise. I.e there always is a starting position of assured connectivity. Additional connectivity may be established dynamically. So if you bring up isp c when a session is already running over a and or b, adding c to the session should be ok. GH: Functional goals, RFC3582 enumerates them. They are not requirements, but goals. You can't meet all objectives all the time, also from the other drafts discussed earlier. RFC3582 gives you a list of 10 items: redundancy load sharing, traffic engineering, policy, simplicity, etc. When grouping points some are about routing, some are not. Last but not least, names/endpoints, stuff in the dns issue, bootstrapping problem re. legacy compatibility, you must be reachable through a FQDN. EL: One quick point: the questions addressed are all appropriate but the organization of the document could be better. GH: Four generic approaches: 1. Route each M-H site IPv4 approach 2. Introduce ?Identity? into the protocol exchange 2.1 Insert a new element in the protocol stack New synchronization element to exchange id/locator binding 2.2 Modify the Transport or IP layer of the protocol stack Perform id/locator mapping within an existing protocol element 2.3 Modify the behaviour of the host/site exit router interaction Modified forwarding architecture coupled with distributed state of identity / locator binding JL: Other WG is working on path signaling. Alison Mankin (Through Jabber, AM): My point is that multihoming can't include all this functionality per se within it. IvB: Traffic engineering is an actual requirement. People aren't going to pay for bandwidth that they will use 1 per cent of the time. GH: Slide 7. I call myself by my identifier, you call me by my locator. Have identity stuff as discrete element or do it in an existing protocol element and sync up at the same time as this element. GH: Final option (of the 4): can modify behaviour of the host site exit router interaction: site exit router changes your stuff with or without host's knowledge. GH: Slide 8. Multihoming via routing. Ultimately, routing each site removes structural hierarchy from interdomain system. 10^7 is taken as a meassurement of the number of sites required to be supported. We don't think this scales. GH: Slide 9. If you can't do it in routing you have to do the split; there is no other way. The network needs to route the packet based on "where". GH: Slide 10. New protocol element, that have to map somewhere in the stack. We can do this in two places: between ip and transport or between transport and ulp (although nobody proposed this). IvB: I think doing it between transport and ulp is a red herring - how can you do it without reimplementing much of TCP? DC: Geoff I appreciated your point that this is a theoretical point. One of the functional requirements when doing it at session layer, is to maintain what applications thinks is transport context over multiple transport connections. BC: There is at least one proprietary solution that doesn't care about TCP survivability. DC: Transport survivability is an issue if doing it at the session layer. GH: I agree. I will put in more text for completeness. GH: Slide 11. Other way to do it: change protocol element so it's done as part as normal operation of that element (transport or ip). Can have set of locators that work as identifier, or alter the ip protocol to support ip-in-ip structures that distinguish between current-locator-address and persistent-locator-address , ie. mipv6. GH: Slide 12. Modified host / router interaction. May need to do source based routing because isp may do unicast reverse path filtering; a very heavy weight solution compared to the alternative of adding morelocators. BC: Do you disagree with the analysis in the Huitema draft? GH: No. But it's very heavy weight to have to modify all internal-site routers if the behavior of a router depends on location in site, hard to operate/debug. BC: Don't disagree, but Huitema draft says you MUST solve ingress filtering problem. GH: Different solutions here. JT: We do something like this where each host has an internal router, everybody is an exit router. GH: Write it up, as I am not sure I completely understand it. GH: Slide 13. Number of ways to solve site exit problem. First, if you only want the ser (site exit router) to route and nothing else, (which is probably a good thing to do) then have dmz/anycast group and tunnel to appropriate ser/isp other approach: all internal routers do source address based routing. Third, dangerous, make sers rewrite source addresses. Fourth, modify uRPF so any isp accepts any source locator move on to identifier/locator binding. GH: Slide 14. You want to allow a single session to work over multiple paths over time. One approach: transport protocol establishes session on identity, then *SOMEWHERE* map to locator that's used on the wire. GH: Slide 16. Where do you put the new identity protocol element? Most proposals put this above ip and below fragmentation and ipsec. This makes sense if you want things to happen correctly. BC: Ohta-san made a strong case on the mailing list that this is completely wrong and it must be in transport. Counter-argument? GH: Haven't directly addressed this claim, but I disagree. If you want IP-Sec and fragmentation to work, you need to do dynamic rewriting AFTERwards and map back at receiving side. GH walks through ulp->transport->identity->ip and back at receiver interactions. Identity is explicity there because you need to synchronize both ends. GH: Slide 18. How can you do this? Conventional: each protocol takes a PDU from the previous one, so simply expand packet at each layer. GH: Slide 19. Some approaches have explicitly gone out of band, and there is some benefit here, topology changes don't always happen nicely. This can use timing of topology change rather than application timing. The other way is three way conversation with reference point so two parties sync with a third one. This is a generalization of using dns. GH: Slide 20. "referential". Use a reference to a third party point a a means of peering (e.g. dns identifier rs). GH: Slide 21. Use identity token from protocol address space, or FQDN as identity token. Structured token vs unstructured token. If we use ip address little changes necessary. Use identity tokens lifted from a protocol address space DNS, applications, transport manipulate an address. IP functions on locators. Stack Protocol element performs mapping of FQDN as the identity token. Is this creating a circular dependency? Does this impose unreasonable demands on the properties of the DNS? Structured token. What would be the unique attribute of a novel token space that distinguishes it from the above? Unstructured token. Allows for self-allocation of identity tokens (opportunistic tokens). How to map from identity tokens to locators using a lookup service? Adding straws to back of DNS camel may be dangerous. GH: If you're going to create a new namespace it's either going to look a lot like a dns name or a lot like an address. DC: Keep same namespace as DNS but distinct lookup servie. TN: Running dns on a new port requires serious thought. Is this a place we want to go? DC: I'm not saying we do, just have it on record. GH: Alternatively, take token with no structure at all. It's just a token, not even complete guarantee of uniqueness. This works well, except for mapping. IvB: Is this token per site, or per host? GH: Or per session, per site means some structure. GH: Next slide. Common issues: Picking the "best" source locator. Try them all. Or identity peering protocol to allow the remote end ... GH: Slide 23. Other part is picking best destination locator. Longest match / use each in turn. Iljitsch made point in march: may need to look at pairs of locators. GH: Slide 24. How do you know when to change address? Timeout may take too long. Proposals for heartbeat. Modified transport trigger. Host/router interaction trigger. Application timeframe vs network timeframe. Failure during session startup and failure following session establishement. GH: Slide 25. How do you know a session is completed? What do you need to do to bootstrap? Are there "distinguished locators" that you always need? GH: Next slide. Session persistence. Use home locator. Use locator set. Use new peering based on identity protocol elemenet and allow locators to be associated with the session identity. GH: Slide 27. Identity/locator binding domain. In very restrictive HIP there is a new identity per session. Allowed to bind bindings across sessions? Binding management issues. GH: Slide 28. Bilateral peer applications vs multi-party applications. Applicaton hand-over and referral in session-based identities referral is impossible or rather: extremely challinging. GH: Next slide. Security consideriations. Point to Erik's draft real soon. EN: Back to common issues. Session establishement is common, but termination also. There are two pieces to the security stuff: Keep architectural issues from actual threats. Where we need to do something like your draft for security too. GH: Generic architecture for security hard to do. Vulneratbilities are clear from actual implementations, hard to do based on generic stuff so you'd have to analyse each proposal separately. BC: We decided to keep Erik's security draft and park analysis there until we find another place for it. BC: Do security analysis when number of proposals gets below 30. GH: My suggestions for moving forward: 1 complete proposal survey (appendix). 2. analyse identity properties in further detail. 3. Examine some futher open issues (next slides). 4. Make some tentative conclusions regarding the properties of a robust multihoming approach and a strawman propsal). 5. Submit to WG for adoption as a WG document. BC: Do you want to do one more iteration of the draft as individual before making it a WG document? GH: Yes. Now the open issues: GH: How serious is routing problem re multihoming anyway? Can routing scope be a better solution that complete protocol reengineering? Are there other approaches here to managing the inflation rate? Betting on routing isn't necessarily bad, it just has risks. Open questions: "Are you doing all of these changes JUST for multihomming"? The issue is that it's a big fundamental problem, more general than multihoming perception could be that this is solution overkill. We have to distribute identity prefixes also structured space management has serious overhead. You can't just select your own identity, so can we use something that already exists? DC: May want to mention origin of first two points: "strategic marketing": not getting much for what you're doing. Second we should worry about operational impact. GH: Second one is very important. KL: Yes, there will be overhead but we have that today too. GH: Yes, someone said for domain names this is terrible. BC: Ergo: do not involve ICANN. EN: Why need structured space? To make lookup scale, and to guarantee uniqueness. We can probably make top not administrative. So structured space != someone owns the root. GH: Slide 33. Applications and id/loc is a self reference within an application the identity value? If so, then can opportunistic id values be used in this context? JT: Questions about what you can and can't do with identifiers GH: Slide 34. Structured space heavy weight solution. Unstructured space has referral issues, potential vulnerability to attack if using ip addresses in referrals, still the existing overloading... GH: Next slide. Proposed next steps. I intend to have a new version within a few weeks, before the cutoff for San Diego. Want to do more work on survey, more notes on routing, steps 1, 2 and 3, but not 4 (see earlier). KL: What if we limit the number of solutions later today? GH: I wanted to capture survey in longer-lived document. The architecture draft is kept as an individual submission by Geoff until point 1. + 2. + 3. in the next step list is done. Hopefully this could be settled within the next couple of weeks. 6. Open discussion on the impact of various categories of solutions (co-chairs, 1 hour) =============================================================== The objective of this agenda item was to structure the more than 30 proposals addressing IPv6 multihoming. For this Brian Carpenter used his slides at http://ops.ietf.org/multi6/interim-04/interim-agenda.ppt (start at slide 8). BC: Does Geoff's draft cover the right stuff? EL: It might cover too much. I don't know if it is ready for RFC publication, but it would be ready for WG document status. It doesn't appear to miss anything substantial. IvB: I sent in a list of comments when he first published it, didn't check if they were addressed in the -01; One thing that was missing in the previous version is the issue of initiating new sessions when there has been an outage - the -00 talked mostly about keeping existing sessions running. Should be explicit that this is important. GH <via Jabber>: There is no -01 yet - these comments will be integrated. JL: Geoff's draft seems quite complete; I'd like to see reducing some of the scope; It especially struck me that some of the common things for multihoming are common in general. So not specific to multihimoning. We should start scoping out what's more explicitly multi6. BC: Geoff's draft or another draft? JL: I'd like to see Geoff's start to scope things at least say that things are not just a multihoming issue. GH <via Jabber>: Common in general for id/ocator split or common in general in some other way? I'm still unsure - IF you head down the id/locator split then there are a set of issues. JL: I think his draft captures commonality in ID/Locator split, that's reasonable; some are more general in the general sense -- like detecting loss of connectivity, detecting presence of connectivity BC: One of the drafts that v6ops is not currently considering pertains to how you find v6 connectivity when randomly attaching to the network; there's some commonality there to finding some connectivity in multihoming. BC: Conclusion: not much missing; scoping issue: make it explicit what things are intrinsically part of multihoming and what is more general. BC: Slide: "Some questions (2)" Is modifying all transport layers to deal with multihoming realistic? Are all transport layers equal for mh? Will applications in general deal with mh issues? Do we believe that any applications will deal with mh issues? TN: that means modifying every single UDP-using application. EL: With TCP and SCTP, you know the start and end; state is well-defined and maintained below application. Now with UDP you need to not only maintain that below state but also names/id/loc/etc JT: I would phrase 1st Q. differently: I don't think it makes sense for a transp layer to know what multihoming means - but it makes sense for them to know an identifier is. I may want to rewrite transport layers once to abstract ID, but not deal with multiple IDs. IvB: The socket layer might know when communications stop and start. Don't create an artificial dichotomy between modifying all transports and not modifying any transports; Could modify some. BC: "Satirically", "tell everyone to use SCTP and you're done". IvB: Transport based on UDP are done in applications; changing applications takes forever; most applications use TCP; you could implement a change in TCP and just do something to UDP that keeps them running but doesn't necessarily give all the gains. EN: What's the need for modifying things at the transport layer? Transport do everything wrt multihoming? Transport is aware that there are multiple paths to relearn e.g. congestion but not perform any multihoming decisions itself. Can you give *some* benefit to unmodified transports, then can you put something into the transport to make them work better? BC: E.g. ECN if the path changes EN: Could say that we're only going to worry about TCP, but even saying therefore a session from multihoming perspective is only TCP, that might not scale well for short sessions. BC: Or media streaming. EN: So part of what we're asking about is connection-oriented vs. UDP BC: and DCCP GH <via Jabber> : Media streaming === DCCP is the direction - yes - so we may be talking TCP and DCCP here. EL: We're hearing about what you can and can't touch - I don't think we should hold the application layer to be sacrosanct. Misuse of IP address in applications? Suggest 3 levels: modify IP layer; connection-oriented; application layer? Say to application providers "If you want to take advantage of this, you need to add a call or two or understand ID/Locator". BC: I'm hearing people say that the big bullets are "no" and small are "yes". <refer to "Some questions (2)" slide> EL: Perhaps some apps don't care to use the new API; could have shim library. BC: Implying new socket calls as a result. EL: Potentially. TN: 1st bullet is wrong question to ask: it's not a yes/no question, since it depends on what the change is. KL: Can a non-modified application or transport layer take any advantage of the improved underlying network? BC: That's never been a requirement. KL: We're close to going down that rathole. Someone: What about ipsec tunnels? BC: That was covered in Geoff's presentation - location of shim decides whether fragmentation or ipsec works. BC: Whole solution in transport isn't very popular with those in this room; part of the solution could go in the transport. IvB: There are 2 different ways unmodified apps could take advantage of multihoming: 1. If full ID/Locator split, apps see IDs, big problem is mapping service. 2. If something like NOID, there are IP addresses that must be reachable in the app that filter through the API; the lower layers probably can't change e.g. a nonworking dest addr for a new session attempt to a working dest addr since they don't know the working addresses, can change source address because apps usually don't specify source, can do tricks when failure in the middle of a session. BC: Line closed for this slide. JT: Re IP-Sec: Worth categorizing, e.g. IKE looks like an application. Protocol caring about address used for routing, it cares in the way that a transport protocol would, so think of it in the same way. Conclusion on this slide: questions aren't quite properly phrased. Probably will be some implications to transport layers even though we don't put the solution in the transport layer. Same is probably true of [sophisticated] applications. BC: Now on slide 10 - "Some questions (3)" Is it reasonable to assume that socket state can include mh state? Or does the necessary state have to be dissociated from sockets? Can the IP layer accurately decide when to forget mh state? Does it matter if mh state stays too long? JT: I don't think it's appropriate to say "Socket" here. As far as portocols are concerned that's an application layer. I'm not saying we shouldn't talk about sockets; last slide talked about application layer, sockets aren't magically different. Sockets are a particular implementation of an application layer. BC: Socket state is implementation-specific state that contains all the magic protocol state; why is that application layer? GH <via Jabber>: The second bullet makes sense to me as a question. TN: Maybe another not well-formed question - more like "Will applications have or need access to the multihoming state"? GH <via Jabber>: And the answer appears to me to be 'no' - it would be preferable for transport to signal session state to the id/loc mapping. JT: Socket layer *is* the application. KL: There has been this discussion & we have the general question - upper-layer hints? -> clearly modification of the socket interface, if applications help manage the state. TN: Maybe real issue again is what info needs to go up, how high up, what needs to go down, how far down? BC: And what needs to be stored? Take noid - somewhere you have to keep a list of locators that go with the locator you're using for the ID. Is that kept once per socket, once per host, ...? EN: This is about sharing or reusing data across multiple connections or over time. EN: So that degree of sharing is different than the question that Thomas is asking. IvB: Discussions about a database for id/locator mapping. Aren't we getting ahead of ourselves, how about fundamental stuff like functional decomposition? Then these questions are much easier to answer. JT: Relates to idea of whether IDs have meaning across different hosts or different applications on the same host. If ID has meaning for different apps/sockets on the same host, you might choose to implement it by caching at the application layer. Some of the socket info is application layer, some of it is transport layer. That's part of why socket isn't a good term, be more specific. Qing LI (QL): Socket/application layer info is quite important for proxy appliances - if ID is used for authorization it's important to look it up. EN: On the 2nd bullet: It might depend on other assumptions; if you have a solution that has a seperate new ID space where you might not be able to discover locators from an ID, making sure you don't throw away the state too early might be critical - youc ould have a transport connection to a HIP and you threw away the locators. EN: On the other hand, if you can discover it again e.g. in the noid case, you may discard the state early since you can recreate it. The other question is, does allowing the two ends to forget state independently introduce security implications, if one forgets and the other doesn't? A has forgotten, so I can pretend to be A. DC: We used to have access to one locator. Now we have a pool that go to the "same place". The pool is the state. That's not even a new idea at the IP layer. Routing tables are maintaining this kind of state. I've always been thinking of this as transport question - you're doing routing and state maintenance in multi6; we call it state when it's only on the endpoints but it's not 'state' when it's routing. BC: Page 11: "Some Questions (4)". My questions about routing are much like Geoff's; probably no need to spend much time on this slide. GH <via Jabber>: Yep - I had put forward the view that site exit router selection and a reliable mechanism for unicast reverse path filtering were 2 aspects of the same outcome and the second was going to be easier than the first. TN: Another question of level: small change, perhaps. EN: Definitely cannot depend on a change. What about asking the routing protocol for "this path might be flaky"? KL: Do we believe in Moore's law more than we believe in protocols? Do we think it will be enough? BC: And we're clearly not expecting someone to implement BGP 5.5. IvB: it's too bad Geoff isn't here because he would have lots to say on how BGP scales EN: I wasn't trying to propose that routing solve the whole problem, just communicate some bad news. IvB: BGP *does* communicate the bad news. BC: Page 12: Some questions (5): Can we make a functional decomposition, e.g. Component to establish mh session state Component to trigger rehoming Component to choose new address pair Component to execute rehoming Component to delete mh session state BC: This is by no means a proposal, just an example of what we might want to aim at. EN: I think 2 and 3 are easier to seperate out than the others. To what extent is management of session state tied in with informing the other end? It can get hints from various places that can trigger this. JL: Is the point here to ask "should we do a functional decomposition?" BC: "will we have enough info to do functional decomposition?" "should we do so?" "where should we do so?" JL: We have enough to start making the decomposition. if we try to get it complete we may never finish it. Take our best shot and live with it. DC: And now we have 35 proposals and have to combine/transform them into one result. Something like this is fundamental for a space like this. We need a series of narrow-scope evaluations that we can then combine. It leads to some decisions about what might be near-term vs what might be long-term. It's not clear that near-term we can get by with something utterly trivial and do the full thing long-term. BC: I suggest we say "this is a question for the WG in general: whether this approach is fruitful, when we should tackle it". IvB: hard to answer this without some idea of what we're going to select out of the 35 proposals. BC: matrix problem, so I want to get on to Kurt's presentation. IvB: Want to see how many of the 35 we can make disappear before we do this. BC: may find things that have already been proposed, clearly relates to one of these components but not to the others. GH <via Jabber>: Working on it. BC: Last slide - "Some questions (6). Can we group proposals into 3 or 4 classes and analyze them against Goals Things to think about Threats Architectural decomposition? First cut at categorization of drafts: Kurtis Lindqvist used his slides at http://ops.ietf.org/multi6/multi6-interim-draft-list.ppt. The adjusted list is at the end of this section. KL: This list of drafts is not random: it is an attempt to categorize them. And not everybody might agree with categorization; I might not even agree with them. I spent the morning in Starbucks drinking way too much coffee; short recap of each draft on this. All on the first page are based around structured addresses, structured address allocation or such. EN: Are you saying 1st list is things that say a single locator/address?. KL: Not necessarily; this is just a list of drafts. KL: 2nd slide: various mobileip-based, rewrite, external rewrite, tunnelling drafts. KL: 3rd slide: transport-layer like sctp, also approaches like 8+8, mast. DC: You're trying to find categories to aggregate these into? I'd think that Geoff's paper describes categories you could use, there should be correlations between this exercise and Geoff's categories. KL: I tried to use Geoff's appendix as a basis. But we are getting to those slides. GH <via Jabber> : I think these could be meshed to a single form of categorization KL: Going through slides, listing each type. EN: Trying to understand what "tunnels" mean, since all have some notion of seperate IDs and locators. EN: Packet format on the wire is different, hack that NOID does to not have any extra data could be extended to others; tunnelling could be somewhat eliminated in the same way. Could say we have locators of different flavors: home locator and temporary locators, somewhat like mobileip. To me "tunnel" is not the most important characteristic. GH <via Jabber> : Tunnelling for me is where the association is carried in the packet, rather than in held endpoint state. I.e. where you hold the association is a form of categorization IvB: The reason I called my proposal tunnelling was because if you see info that is aggregated away when packets were on the wire and you add it back to the packet it looks like an ordinary tunnel. BC: At one level, there's a functional equivalence between tunelling and implied/shared state, but I think there's a real difference since there's the problem of state synchronization; if the state is in the packets then the problem is not necessarily there. EN: One locator could be an alias for another locator. KL: This is the first category. Does anyone think any of these proposals are going to help us get any further? <silence>. BC: We got two questions: do we agree on the categories, and second, can we wipe out a few? JL: Even if we kick out categories we should document them, people tend to come back to the same ideas. KL: It will be in the minutes. TN: Agree with John. Marcelo Bagnulo (MB): I don't understand this category. Singe address solutions in there, multi address solutions, partial solutions... KL: I've already taken out drafts that weren't proposals by themselves. But, yes I agree this is the hard to categorize stuff. TN: It would be good if the authors agree with the categorization. BC: Name should capture common feature. JL: We may want to reuse pieces from these drafts, but not spend too much time. KL: These are the drafts with the least support. TN: But then that is the common feature. Say what part of the draft doomed it. BC: Too much work. EL<?>: Merge everything into one proposal, have groups convince us that their proposal is good. KL: If we take things off this list it doesn't mean they disappear. MB: If you want a category, there are two types, non-pa-compatible (using one address), other category is Ohta-san and his friends. EN: To what degree are those drafts on the list still alive? IvB: Two of those drafts are mine. One is old, forget about it, the other has no support so if you want to drop it for that reason that's ok, but don't tell me it is no good because i still believe in it... David Kessens (DK): Approach authors. We basically have two classes: drafts that are for discussion, these can be quickly killed by talking to the author. Other type is where author strongly believes, this will be more difficult. If people want to keep their stuff we should encourage them to work together with others. Jens Kristian Kjaergaard (JKK): Isn't it more important to agree on the categories? BC: I like the notion of challinging the authors within clases to come up with a unified approach but deadline isn't San Diego. JL: Drop proposals by default rather than keep them around by default. TN: We want to encourage work in promising areas, discourage un-promising. No sense in asking people to come up with a unified proposal for categories we think are no good anyway. "Rough categories and running code". JT: Avoid kicking documents by category, people will want to move KL: categories: - "intermediate systems". MB: Can go, Michel is no longer active. KL: host based, "host signaled". IvB: Naros is valuable and only does one small thing, keep it and not in this category. EN: Naros not on the critical path. KL: Create something for stuff like this - components rather than solutions. EN: Huitema draft is also a component draft. It says the main issue is source address stuff and this is how to solve it. If we can put drafts in multiple categories that would be be appropriate. KL: Don't think I want that. MB: Most proposals deal with a specific issue, we're going to take away parts from more than one to build a solutions. KL: Category "Aliasing" (instead of tunneling) MB: Mobility draft explains why mip can't be used for multihoming, not a solution. AF: I've always thought of hip as a wedge solution, surprised to see it listed as tunnel. JT: I've always seen it as a tunnel KL: Agree. Let's move it to "Fat IP / Wedgelayer 3.5". KL: Category transport solutions. KL: Category wedge layer 3.5 IvB: Geoff made distinction between wedge layer and modifying the network layer but no such distinction here. KL: We're going to have a component category. These aren't things that we either want to kill off or work on, just stuff we want to look at again later. We're down 3 proposals so we're making progress. Do we split the 3.5 category into wedge layer and modifying ip? GH <via Jabber>: The distinction was subtle - its was a case of seperate syncronization wit the remote end vs coupled synchronization of state with the transport session. BC: The OSI reference model forgot to be recursive. Implementation as a shim or modify ip comes up later. BC: Margaret Wasserman is supposed to call in, but apparently not right now. KL: I was expecting more discussion. BC: John <JL> said that : NSIS people thought NSIS was a solution? JL: NSIS is looking at on-path signalling. NSIS people want to have something to handle multiple paths. BC: NSIS is stil looking at the world as a soft state universe, right? JL: Yes. BC: Unless there is a draft, we have nothing to discuss here. KL: Wedge layer class is now "FAT IP / Wedge layer 3.5". KL: So can we kick out more drafts? Aliasing / tunneling category is going away, remaining draft was ODT, now going to wedge. BC: I suggest that most of the de-aggregated proposals are not to be pursued further. BC: Only a few of these have been presented at the IETF. We still need to take this to the mailing list. BC: <have a large sheet of paper (not viewgraph) to discuss. evolved during coffee break>. BC: The next steps are obvious and not... BC: The obvious part is we can see a path on how to make progress on 4 drafts which are deliverables. The 4 drafts - threats (Nordmark) ready for San Diego. Things to think about - kept alive somewhat longer. <alive = in progress; threats ready for last-call after san diego>. BC: How multihoming works in IPv4 - much needed; hopefully version ready to discuss in SD. GH <via Jabber>: I'll have architecture -01 raady in 1 -2 weeks from now. KL & BC: Will post about categories to mailing list; goal to crystallize discussion and/or omit some. BC: Needs to designate an editor in each area. Margaret Wasserman <via telephone> (MW): Has it been determined which drafts are still alive and which are to be dropped? BC: Sort of; based on the categories. ??: Does this mean a editor for each category or multiples? BC: Single editor per se is premature. KL: Authors should agree to work as a group; can appoint someone from that group. BC: Need point-person ('stuckee') to ensure it all happens. ??: Multiple drafts = multiple 'stuckees'. BC: Chairs won't micromanage. May appoint micromanagers. MW: If we assign editors - one of the authors or neutral? BC: It depends; some may agree, some may not. MW: May go with design team approach. BC: May formalize as design team in the process, but teams aren't agreed as a good process method. IvB: Merge parts of the docs? BC: Hesitatingly agrees, but diplomatically suggests caution. IvB: WG already behind on milestones BC: Those milestones are gone. IvB: We haven't done much technical progress today. Mostly procedural. EL: Takes exception. There weren't 30 proposals 6 mos ago; lots of good recent work, esp. due to chairs. Problem is complex. How do we move forward? Brian and Kurt's proposals are constructive. If authors are really interested in solving problem, they can do 1) work with others, or 2) copy from others. Let's wait for running code; it's the code that matters. BC: Part of the challenge - show us running code. So far, except for SCTP and HIP (only part of soln), no code yet. JL: Creating categories is useful. Also ... if categories are described well, still useful to have outside editor help synthesize. Having Eric do that with noid, etc. was good in this regard. BC: Can this be integrated w/Geoff's doc, esp. w/Margaret's appendix? JL: More concerned with content than process. GH <via Jabber>: Yes - that was my understanding. BC: Volunteers to help writing are welcome. BC: What next? DC: Let's spend some time defining layer 3.5 and picking the number. that'll consume time. BC: Thanks to Kurtis for the coffee BC: Thanks Iljitsch for networking, et al. - very IETF style GH <via Jabber>: And thank you jabber scribes. KL: Thanks scribes! KL: We're not chartered to come up with a full-fledged protocol; important point to keep in mind. BC: If this weren't hard, it wouldn't take 3 years to get to a solution. That sounds horrible if you're "young and impatient". Problem has been lurking since beginning of IPv6. Jordi Palet: One thing I'm missing is still 'set of use' cases; one discussion on mailing list w/fortune 500 companies. Is Multi6 for residential? Small businesses? It would be useful to consider. BC: I wish those use cases would just appear. We had the same problem with scenarios in NGTRANS before V6OPS. Their scenarios work started a long time ago and has taken approximately forever. These are hard to come up with. We know there are multiple categories. fortune 1000, drive-by's, etc. - there are a bunch. I'm scared of v6ops analogy to launch an effort. It's too hard to get to a conclusion. KL: Difference between multihoming and transition. Load sharing, etc. They're the same for everyone. Transition has more cases. BC: Don't want to commission "use cases doc" BC: Are we done? <room - yes> The outcome of the discussion was a suggestion to split the proposals in the following categories: A. Addressing based * draft-kurtis-multihoming-longprefix-00.txt draft-savola-multi6-asn-pi-01.txt draft-ohta-multihomed-isps-00.txt draft-toyama-multi6-operational-site-multihoming-00.txt draft-ohira-assign-select-e2e-multihome-01.txt draft-van-beijnum-multi6-isp-int-aggr-01.txt * draft-van-beijnum-multi6-2pi1a-00.txt draft-ohira-multi6-multilink-auto-prefix-assign-00.txt draft-teraoka-multi6-lin6-00.txt B. "Intermediate systems" * draft-bagnulo-multi6-mhexthdr-00.txt draft-py-multi6-mhtp-01.txt C. Hostbased draft-huitema-multi6-experiment-00.txt draft-huitema-multi6-hosts-03.txt D. Tunnels E. Transport draft-coene-sctp-multihome-04.txt draft-coene-multi6-sctp-00.txt draft-arifumi-multi6-tlc-fm-00.txt draft-ohta-e2e-multihoming-05.txt draft-ohta-multi6-8plus8-00.txt F. Wedgelayer 3.5 / Fat IP <KL to supply 2-3 sentence description> draft-nordmark-multi6-cb64-00.txt draft-nordmark-multi6-noid-01.txt * draft-nordmark-multi6-sim-01.txt draft-ylitalo-multi6-wimp-00.txt draft-crocker-mast-proposal-01.txt draft-nikander-multi6-hip-00.txt draft-van-beijnum-multi6-odt-00.txt G. Components draft-de-launois-multi6-naros-00.txt draft-crocker-celp-00.txt The "Components" class are proposals which contains functional elements, which can be incorporated in the above categories. Way forward: ============ Find and define the categories and group the proposals accordingly. Try to merge the proposals from each category. The initial categorization of the current proposals is above Kurtis and Brian formulates separate mail going to the multi6 mailinglist describing the categories and the split of the current drafts into these categories. After consolidating the list of drafts in each category the next step is to workout a unified proposal for each category, and use this to provide a set of alternative solutions. 7. Conclusions of meeting and where to move from here. ====================================================== 1. Progress on drafts: The "IPv4 multi..." and the "threats draft" should be revised to be ready for working group last call after IETF meeting in San Diego. The "things to think..." draft and the architecture draft need to stay in sync with work on solutions and could be targeting working group last call after the IETF meeting in Washington scheduled for November 2004. 2. Solutions - Issue mail defining the categories (Kurtis + Brian) - Challenge authors (in some cases) - Suggest withdrawal - Designate editor for each category. Editor could be one of the document authors or some moderator. Design team(s) could be used later in the process. The synthesis from each of the categories could eventually go into Geoffs document. It could be good to document the multi6 use cases, but experience from v6ops is not very good. Acknowledgements from the meeting ================================= To Autonomica AB for sponsoring refreshments, meeting room equipment and connectivity. To IPv6 Forum/US IPv6 Task Force for providing meeting room. To Iljitsch van Beijnum for providing network connectivity during the meeting and streaming and recording the meeting. Appendix - additional notes on discussion ========================================= The following is a list of comments and statements issued during the process leading to the above categories. Brian Carpenter's questions at page 8 on in his presentation formed the basis for the discussion. Elliot: Geoff architecture should be sufficient background to continue evaluation. Iljish: Initiating new session after an outage need further work. John Loughney: Functional decomposition should be added to Geoff draft. Otherwise not much missing. Some comments slide 9 Transport needs to know of ID not multi homing. Some modifications are needed for transport layers and applications. Some comments slide 10 The question: "Is it reasonable that socket state can include MH state?" Cannot be answered currently. Some questions slide 11 Brian - most were already addressed by Geoff Thomas - most of the questions depend upon the results - depending upon the bang for your buck. Erik - Maybe should ask what changes are dependent upon, but you may not be able to depend upon the changes to be made. Bill - Supports Thomas' view. Illitsch - Wants to know why we are talking about BGP Brian - this was just an example, not a proposal. Kurtis - do we think it can scale? We are here because it doesn't scale. - small side discussion on BCP scalability ... Some questions slide 12 can we make a functional decomposition? Erik - points 2&3 may be easy. John - are you proposing that we start a decomposition Brian - Two questions - do we have enough info to make it & should we make it? Dave - I think we need to do this. We need to break it into pieces. Brian - question to the WG - is function decomposition a good direction & when to start the activity? Illitsch - should we start this if we haven't started making a choice on the solution. We should make some of the proposals disappear. Brian - we may find out that some of the proposals relate to one of the pieces. Illitsch - we know some things that we want, but don't agree on all of them. Narrowing down the choices will help. Some questions 13 Can we group proposals into 3 of 4 classes and analyze them? Kurtis has tried to order them according to Geoff's list. list of drafts various solutions based around the structure of the address; various solutions based around mobility, routing, tunneling various solutions based around transport layer solutions Dave - are you trying to find categories to group them. I think Geoff's draft has a grouping, and if the draft is wrong, then it should be updated. Comments on tunnels: Is there a conceptual difference between tunnels and other multi6 solutions? Is tunneling a category on its own? Suggestion for renaming tunnel category to aliasing, representing the cases where on locator may be aliasing another locator. (end of minutes) |