Last Modified: 2004-06-18
Multihoming today is done largely by having a site obtain a dedicated block of address space and then advertising a route for its prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time. This WG will seek alternative approaches with better scaling properties. Specifically, the WG will prefer multihoming solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ). Just as sites have multiple reasons to choose multihoming, they may have multiple reasons to want to provide these benefits more directly to hosts within their sites, for instance, because some of those hosts may have network stacks capable of detecting and surviving a provider/prefix change. Phasing in hosts with capabilities of multihoming might be part of the Multi6 solution space. In the course of this work, the WG may also study the deeper underlying questions of identity and location of services, hosts and sites as they directly affect multihoming.However, the working group is not chartered to make significant changes to the nature of IP addresses or to inter-domain routing.
This WG will consider the problem of how to multihome sites in IPv6. The multihoming approaches currently used in IPv4 can of course be used in IPv6, but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. For example, IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4). Also, IPv6 deployment is at an early stage, so modest enhancements to IPv6 could still be proposed.
The WG has already produced a document, RFC 3582, on goals for IPv6 site multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented there.
The WG will take on the following tasks: ========================================
Produce a document describing how multihoming is done today in IPv4, including an explanation of both the advantages and limitations of the approaches.
Produce a document outlining practical questions to be considered when evaluating proposals meeting the RFC 3582 goals, including questions concerning upper layer protocols.
Produce a document describing the security threats to be addressed by multihoming solutions.
Solicit and evaluate specific proposals to multihoming in IPv6 (both existing and new), extract and analyse common architectural features, and select one or a small number of proposals for further development. The architectural analysis will include applications layer considerations and transport layer considerations, as well as lower layer issues.
Development of specific solutions will require chartering of work in the appropriate Area or Areas.
|Done||Goals for a multihoming solution as RFC|
|Done||Final solicitation of proposals|
|Done||Begin architectural evaluation of proposals|
|Apr 04||Submit informational I-D to IESG on how multihoming is done today|
|Done||First draft of architectural evaluation|
|May 04||Submit informational I-D to IESG on practical questions|
|May 04||Submit informational I-D to IESG on security threats|
|Aug 04||Submit informational I-D to IESG on architectural evaluation|
|Sep 04||Identify proposal(s) for further development, recharter|
|RFC3582||I||Goals for IPv6 Site-Multihoming Architectures|
Multi6 WG meeting minutes
(Tim Chown, 2nd August 2004, edited by co-chairs)
Both co-chairs present:
Meeting opened 9:05 am, 2nd August
Brian reminded attendees of the terms and conditions of IETF meetings and contributions as stated on the yellow sheet given to delegates in the IETF registration pack.
There are three parts for this meeting on the agenda. First, there are four drafts to finalise, so we can WGLC and not have them in the next meeting:
Then a scenarios document:
And finally a further discussion of next steps, including the Wedgelayer 3.5 / Fat IP approaches and required components.
The three-part agenda was accepted, with no changes suggested.
** draft-ietf-multi6-v4-multihoming-01 (Kurtis Lindqvist)
Kurtis stated that the list comments were all taken on board. Only major discussion was Chapter 3 on motivations for multihoming, so it had been suggested by Brian Carpenter and Kurtis, on the mailinglist, to take this out and leave it for Jordi's document. Only Pekka have objected to this at this time.
Pekka: Mechanisms are different in v4 and v6, so we should remember the scenarios we need to fix in this document. It is not a trivial rewording. Issues such as traffic engineering should be expanded. Maybe half a page is needed.
Kurtis: I have no strong view.
Pekka: Not all v4 motivations may be supported by a v6 solution.
Eric Fleischman: RFC3582 in sec 3.1 has a list of these goals, and the draft list is just a subset. There are 7 reasons in the RFC and 4 in the draft.
Kurtis: Maybe we should just refer back.
Geoff Huston: There is also the analysis at the end of the architecture draft that could be merged in.
Brian: I don't think that's probably the right thing to do.
Kurtis: The documents should be consistent.
Brian: If things are missing, send text (aimed at Pekka). To avoid endless debate, Kurtis should try to refer draft text back to the RFC, and make the motivation section leaner and more precise.
The room agreed that the changes to the document were representative of the list comments.
** draft-ietf-multi6-things-to-think-about-00 (Eliot Lear)
Some text based on Geoff's texts, the goal in the new version was to make the questions a bit clearer, and to add applications considerations, e.g. for backwards compatibility, e.g. what happens to hostbyname. There is a danger of misinterpretation if these functions are overloaded, e.g. if log analyser converting IP addresses back to names. Happy to get the document to an Informational RFC, but main goal is to list the problems people should think about.
Brian: chairs not sure whether to keep as living document or publish it sooner.
Eliot: don't waste time making this perfect, just use it for solutions documents.
Tim Chown: these issues should be preserved for future reference
Brian: question is just when.
** draft-ietf-multi6-multihoming-threats-00 (Eric Nordmark)
Most changes in this version are editorial edits. The biggest addition was discussing the state of privacy in the Internet today, so we can talk about "do no harm" additions in the context of multihoming. Also some more background info for multihoming newcomers. The appendix has been left in place because there is nowhere else to put it. Christian Huitema made specific privacy comments; multihomed hosts have different IP addresses per ISP (making correlation harder), also that v4 middleboxes/NATs today make correlation for snoopers harder. These comments are added now.
Christian: We should not just say "do no harm", i.e. not just say "be no worse", rather we should actively try to do better. For example any use of unique identifiers have a privacy risk. Goal is we should do better.
Eliot: I disagree. Principal goal is scalable multihoming solution - adding privacy concerns degrades the situation.
Brian: I detect Christian is saying "raise the bar". That change is one we should be clear about if we want to do that.
Christian: My company is often criticised. There are solutions for multihoming that can make security or privacy harder. We have to be clear about the tradeoff between functionality and privacy. As with the MAC address, our industry has not been cautious.
Geoff: Bits of my identity need to be available to do multihoming. If we go locator independent, you are exposing info about bindings that was not previously exposed. The fundamental question is whether we're doing a locator-identifier split. Is there a persistent long-term identify, published, or a per-session method? These have different issues. We already had the debate in the bottom 64 bits for IPv6.
Erik: You don't have to expose the same identity to everyone, the single identity is the more dangerous.
Geoff: You can't always bind by context, so it becomes longer term.
Erik: You still need to make referrals work.
Geoff: Not sure.
Christian: Making a session live over a change of IP address has less implications. You can engineer your solution to make your identifier visible to your session peer and/or third parties. We should be more explicit.
Erik: We should note the peer and 3rd party text in the document. We should make stronger statements about unique identifiers and their concerns.
Eric Fleishman?: We should have a solution that hits many layers. Christian's idea of embedding MAC addresses is bad only in some people's eyes. We can't say what is good or bad clearly, because it may depend on the solution.
Christian: I would like the considerations there because they are taken as input for the solution designers, hence privacy is important in this document, even if that means the solution is harder to build.
Erik: I'll add those comments in the next update
Brian: We need WGLC on this very soon.
** draft-ietf-multi6-architecture-00 (Geoff Huston)
Has been revised by WG list comments and from the interim meeting, and is now a WG document. Geoff thinks it needs more review and revision, so we can go to Informational RFC. The changelog shows the WG input, e.g. session initialisation when the state is not as you might expect, and to consider traffic engineering across multiple paths. Also some text on endpoint identifier structure - at what point to do know you're dealing with a locator, or an indentity without a locator context. Also disambiguating in the case of load-sharing (i.e. the machine may not be multihomed, the service may be multi-hosted). New text is added on triggering locator change, via ICMP triggers. Also notes on whether identity is per session, or per endpoint independent of session. A new section on functional decomposition of multihoming approaches has been added, due to WG chair input.
There is an open issue for which help is needed, wrt MIPv6. There was a comment that there is a "back to base" problem. In multihoming, a fixed, home locator may not be there. So there needs to be text as to why MIPv6 is special in the multihoming space.
The appendix on "various approaches" should be split out, to get the main document through quicker.
We should document the architecture issues of identifier-locator split, and on the capability negotiation initial handshake, and on describing the various identify types and their potential for coexistence. For example, the application may use identifiers or locators; the capability and semantics need to be clearly understood.
Brian: We should look at each of these issues. We need text from someone, e.g. for multihoming and MIPv6 for the first issue.
Eliot: In order to initiate contact you need to be able to start by going via the home address.
Geoff: That, and also there are timers when you go into care-ofs that you check back with the home address. This may be inappropriate to multihoming. We need text on this.
Eliot: Question is why are those timers there and whether or not if we did something else for multi6 we'd end up in the same position.
Marcelo volunteered to provide text.
Brian: The appendix early analysis text (by Margaret Wasserman) could be split out - it's not architecture per se.
Margaret: I am happy to split it out. Is that valuable?
Brian: We did some analysis in the interim meeting. This might make you rethink the way the analysis is organised.
Margaret: We should structure based on the interim meeting discussion. It needs a lot of updating if it should be kept. Originally it was a text to get people up to speed. maybe it's served its purpose.
Brian: We'd need a co-author...
Margaret: No, we need an author!
Brian: OK, we'll spin this appendix off. It needs an author though.
Christian: I volunteer.
The WG hum passed the proposal clearly. David Kessens (AD) agreed.
Brian (chair hat off): The broader implications debate is endless, so we should not have it in this document, else we may not get closure.
Tom Henderson: Since last meeting there has been a new IRTF WG on this topic for locators and identifiers. Looking at HIp on a wide scale, and the impact.
Brian: Good luck!
Geoff: Persistent unique identities that are validatable and operate with integrity have a heavyweight distribution mechanism, so think about that in the context of DNS, or distributing locators. There will be a comparable infrastructure, so there are far-reaching implications. There thus has to be a real value beyond multihoming for identities agile beyond locators.
Christian: Could be bad for privacy
Geoff: If limited to multihoming, as cost-benefit, then session based resiliency can be done without those long lived properties. There are big architectural implications. We must choose with our eyes open. This must be documented, and this draft is one such place to do it.
Erik: What are you suggesting putting in? Without saying all the tradeoffs and how to weigh them.
Geoff: I think we should state dimensions and arguments, maybe 2 pages of careful writing. It's not easy, but I think it's necessary.
Erik: We might not get closure though.
Geoff: I'd like to document that choice space.
Brian: No binding vote now as Geoff may find it's too hard to write. Are people generally feeling this is good to document.
Majority agreed to documenting it.
Brian: This must not become a war on this topic. Just describe the dragon.
Brian: The issue of initial handshake on capability seems less contentious.
Geoff: We need text on signalling, negotiation, etc.
Brian: And whether per-session.
Brian: The final issue also seems clear, so should go in.
Brian: Are there any other issues we missed?
No input from audience, so no issues raised.
Brian: I urge people to have a final think for anything missing, so Geoff can
focus on editorial issues. Glance over Eliot's draft for anything architectural
rather than just things to think about.
Eliot: I'll provide some text.
Geoff: Deadline is 2 weeks for text. I'll edit in 3 weeks.
** draft-palet-multi6-scenarios-00 (Jordi Palet)
This document was written in response to a comment from Brian that such text isn't written yet.
There are many scenarios: e.g. ISP, IX, enterprise, university, security, defence, emergency, SOHO, 3GPP, ad-hoc, mesh. Applications like VoIP in emergency situations is one example. There are special services and applications, e.g. GRIDs, mobility, special devices (WLAN and 3G interfaces), renumbering, real time traffic, special protocols (CDN, IDC, DNS, DHCP, etc).
It would be nice to get the work adopted as a WG item, maybe to integrate it with Kurt's document. We need expertise in some areas.
Kurt (chair hat off); Happy to work with this as appropriate.
Brian: This document should not become like other scenarios documents that may take years to complete and become blocking factors.
Brian: Is this a good idea? Is it bad?
Silence from room.
Brian: OK, let's continue with this.
Jordi: We need 3GPP input.
Terry Ernst: We could merge this document with our work on a mobility approach, we have the same motivation for fixed and mobile nodes.
Brian: Jordi needs help, else the document will not improve. This should remain a personal item until at least the next revision.
** Open session on next steps:
Brian: We have just over an hour left. Interim attendees should know what this is about. The interim meeting sorted 30 or so proposals into groups, and the top group turned out to be wedgelayer or Fat IP, as a shim layer. So the next step is to consolidate the work in that area. We have a proposal for progress; there are 7 drafts in this space, our goal is to get the common view of the "functions" and components.
A design team of Erik Nordmark, Jari Arkko, Marcelo Bagnulo Braun, Iljitsch van Beijnum, Geoff Huston and Yukka Ylitalo has been formed and all have all agreed to serve.
The goal is to get to a smaller set of proposals, without going into detailed protocol specifics. A single document should be produced for discussion at IETF61.
Christian: I see three separate areas that can be studied in the wedge space; how to exchange an identifier, then the issue of ingress filtering, and how that is handled, and also the issue of by which method you choose which locators to use. These three things are essentially independent. So is one document best?
Brian: You're not wrong.
Christian: We could redo IP, which is the identifier space, and we use that. Or we could look at the minimal set of functions to adapt what we have today.
Brian: Let's keep this on hold for the next few slides today.
Brian: There are 7 drafts in this space:
We also looked at the mailing list for functional decompostion:
Establish mh session state
Locator selection for initial contact (both source and destination)
There are two items here:
- Path availability. i.e. if packets with a given pair of source and destination address reach the other endpoint
- Policy: about locator selection
Path failure detection mechanism / Trigger rehoming
Locator selection after a failure has been detected / Choose new address pair
Delete mh session state
Identifier discovery mechanism
Locator discovery mechanism
- for initial contact
- once that the communication is established
Identifier validation mechanism
Locator validation mechanism
- at the initial contact
- once that the communication is established
We won't discuss this point by point today as we don't have time. We missed out ingress filtering but will add it. There is a scope of around a dozen or so areas to consider, based on the observations.
Kurt: We need to get a document from this decomposition as a discussion focus.
Christian: Also the interoperability with existing IPv6 hosts needs to be considered.
Brian: Of course.
Erik: The focus needs to be to bring together the different identifier aspects, to see if we can build a method that will cover what is needed. The ingress filtering can be treated separately.
Brian: This list of components shows its not an easy problem. You need to think about all the goals, all the things to think about, to get a complete problem statement.
Christian: Also hardware acceleration, and load balancing, needs to be considered.
Jim Bound: I'd like to see SCTP as part of the analysis.
Brian: SCTP tackles some of these issues, it may not be built into the wedge layer.
Jim: It may reduce the wedge. Is it part? Or are we just reinventing a 3.5 layer?
Brian: we didn't list it as SCTP is Layer 4. Components are relevant though.
Jim: Some of us believe we're making this too complex. I'm working also on hardware acceleration- it should be transparent to us. Vendors who ship "funny link layer interfaces" - that's their problem. We don't want to take on too much.
Brian: yes, but there are tough problems with assumptions that offload devices make.
Erik: We should not force all existing hardware and apps to keep working.
Tony Li: This is the IETF, so we work on running code. We need to think about hardware, not ignore it.
Jim: That's not what I'm saying.
Christian: The wedge layer only comes into action for session survivability, but if you do not care about that, the picture is different. We should acknowledge that. Tying the 3.5 layer to session survivability has implications.
Brian: I suspect that's correct. Geoff is this in the archictecture document? Do you only need wedge layer if you care about session survivability?
Geoff: Yes, I thought about it as Layer 3.4 or 3.6, depending on whether you look up or down. You could swing it either way a bit, depending on whether you want to share state across sessions, with longer running glue, or have session survivability. Being agnostic leads to complexiities, there's a different functionality depending on whether a previous session exists. l lean towards 3.6.
Brian: Are there common features that we don't need to discuss, or differentiating features that we do need discuss, e.g. HIP vs NOID, or are there still things missing in the "things to think about" draft?
Brian: Erik, anything to say about the design team process?
Erik: We're trying to organise a get-together this week, no slot yet. That's about it at the moment. We need to carve out more than we discussed today, in terms of what to cover or not cover. I'm concerned about the 7 drafts, but also continue to get input from the WG.
Brian: we can identify what can be worked on independently, not everything is in the scope of the wedge layer. We could get other authors or another design team in place for that.
Tim: What was the withdrawn draft of the 7 drafts? ie. draft-nordmark-multi6-sim-01.
Erik: That was down to HIP, it felt redundant.
Brian: The revised wimp draft is quite different now, btw.
Marcelo: How will we move forward on the components part? I agree with Christian's comments here.
Brian: We don't have a plan yet but need one. We need to find the gaps in our plans.
Brian: We can close now if there is nothing else to raise now. Anything to add, David, as Area Director?
David: Nothing to say or add.
Close of meeting at 10:40am.