Last Modified: 2004-02-12
Multihoming today is done largely by having a site obtain a block of address space and then advertising a route for that 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 explore alternative approaches with better scaling properties. Specifically, the WG will prefer multi-homing 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).
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).
The WG will take on the following initial tasks:
Produce a document defining what site multihoming is, the requirements for a multihoming solution (from both the end site and ISP perspective). This document will also include a taxonomy of different ways that multihoming might be achieved.
Produce a document describing how multihoming is done today, including an explanation of both the advantages and limitations of the approaches.
The WG will also consider specific proposals to multihoming in IPv6 (both existing and new) and select a small number of them to work on as formal WG items. Development of specific solutions will require approval of the IESG (e.g., a recharter).
|Apr 01||Submit initial I-D on requirements, terminology, etc.|
|Apr 01||Submit I-D on how multihoming is done today|
|Apr 01||Begin consideration of approaches and proposals that could be pursued.|
|Aug 01||Evaluate approaches and select those to be worked on.|
|Sep 01||Submit requirements ID to IESG for publication as Informational RFC.|
|Sep 01||Evaluate progress, recharter or shutdown|
|Sep 01||Submit 'how multihoming is done today' ID to IESG for publication as Informational RFC.|
|RFC3582||I||Goals for IPv6 Site-Multihoming Architectures|
-Minutes : Multi6 working group ==================== Wednesday 3 March Agenda: 1. Agenda bashing and Administrativia, chair 2. Charter review, chair 3. Short intros to NEW drafts draft-ohta-multi6-threats-00.txt, Masataka Ohta draft-ohta-multi6-8plus8-00.txt , Masataka Ohta draft-ohira-multi6-multilink-auto-prefix-assign-00.txt, Kenji Ohira draft-arifumi-multi6-tlc-fm-00.txt, Arifumi Matsumoto draft-ylitalo-multi6-wimp-00.txt, Vessa Torvinen draft-nikander-multi6-hip-00.txt, Pekka Nikander draft-coene-multi6-sctp-00.txt, Lode Coene draft-crocker-celp-00.txt, Avri Doria draft-toyama-multi6-operational-site-multihoming-00, K. Toyama 4. draft-lear-multi6-things-to-think-about-00.txt, Eliot Lear 5. Architectural analysis, Geoff Huston 6. Other issues 1. Agenda bashing and Administrativia ===================================== Brian Carpenter is not here today, so only Kurt Erik Lindqvist will chair the session. Session is broadcasted. Comments on the updated charter by Kurt Erik Lindqvist. Some modifications have been proposed to the charter. The updated charter has been sent to the IESG. The IESG then made some comments and those are being solved. There are new milestones, including: - Architectural evaluation for Feb. 04, which is expected to be based in the work done by Geoff Huston. April timeframe was considered. This draft will be used then to classify and evaluate proposals. - Informational draft about current multihoming practices in IPv4, as confirmed in the Vienna meeting. A draft exist covering this issue, but is to be updated. No much feedback about the draft yet. The chairs may need to find an editor for this. - Operational draft containing practical questions. The proposal is to base it on draft-lear-multi6-things-to-think-about-00.txt by Elliot Lear. The proposal is to obtain more discussion on this and then send it to last call. - Threats draft. The proposal is to base it on draft-nordmark-multi6-threats-00.txt. Questions: Pekka Savola: I am concerned about ID about current IPv4 multihoming today, there are still big issues with it. Is it already submitted? Kurt Erik Lindqvist: It has not been submitted yet, the chairs need to decide how to move forward with this. Decisions/Outcomes ================== 1. Adopted draft-lear-multi6-things-to-think-about-00.txt as a working group item. 2. Geoff Huston will produce a draft containing the architectural analysis. 3. Erik Nordmark will update the security threats draft 4. Possible interim meeting to be defined. 00 Draft Presentations ====================== Threats Relating to Transport Layer Protocols Handling Multiple Addresses ---------------------------------------- -------------------------------- - Masataka Ohta Multiple addresses assigned to homes in multihomed sites are needed in order to preserve global BGP routing table small. A session is something that needs state, so it is not at the IP layer, since no per connection state exists in IP. The connection state resides at the transport layer. So, this draft analyses the threats in transport layers managing multiple addresses. Threats: - Connection hijacking: it is not a new threat, since MITM in DNS queries/replies or rewriting an URL in HTTP can cause similar effects. The solution for this is to protect with cookies and this solution is already considered. - DDOS: The problem is amplification, This is not new threat, since it is similar to, for instance, what happens in the DNS, where the reply is longer than query. A multihoming solution should not generate answers that are longer than requests. However, new DOS opportunity can be caused by the usage of public key crypto in multihoming solutions, because public key crypto is costly. Cookie based solutions are not so expensive. - Privacy in the identification: A multihoming solution should allow to hide the identity information, so it should be allowed identifiers to be temporal. 8+8 Addressing for IPv6 End to End Multihoming ---------------------------------------------- Masataka Ohta 8+8 addresses is an old concept, and it is based are composed by 8 bytes locators (used for routing) and 8 bytes identifiers (used for identification). For multihoming support with multiple addresses, the support cannot be provided by the IP layer, because IP is stateless. This proposal does not change IP. 8+8 addresses the issue of interoperability with legacy hosts. For this it is necessary to discover when to use 8+8 capabilities i.e. whether the other end of the communication supports 8+8. The proposed solution is to use the group bit in the identifier to signal if the the node supports 8+8 mode. Question: ??: Are you proposing to use the group bit for this? Masataka Ohta: this bit it is not used today. Continue with presentation: A problem is how to distribute identifiers, in this case identifiers can be assigned like DNS names, since you can base the identifiers in the locators. Locator selection is not a problem because the global routing table is used for that. Source locator is not an issue, since source address is ignored. In the case that some issues related with ingress filtering compatibility appear, they can be solved through a modification in the IGP (such as OSPF modification). There are no problems with Mobility. The solutions proposes to modify TCP, but in a fashion that it is compatible with old TCP. The solutions presents all the desirable properties presented in RFC 3582. Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model... ---------------------------------------- -------------------------------- K. Ohira Multiaddresses is proposed in several solutions This solution proposes an address assignment protocol to assign multiple addresses to host in multi-link multihomed sites. It is assumed that source address based routing will be used to select the exit. Transport survival is out of scope. The protocol proposed to assign addresses is the following: - Assign subnet identities to each link, by dividing the subnet field in the IP address - The top level router i.e. the one connection to the ISP, obtains a /48, and splits it downwards. RFC 3582 assessment slide TLC-FM : Transport Layer Common Framework for Multihoming --------------------------------------------------------- Arifumi Matsumoto Fate sharing based classification of different type of solution: - SCTP, TCP-MH and DCCP: each layer has its own multihoming information which is not shared with other transport layers. - Wedge solutions: the multihoming information affects all the sessions in the host. The problem with this approach is that each application cannot choose its own paths TLC-FM proposes to use an intermediate level of fate sharing (information shared). Each transport shares the information with other transport layers. However, each transport chooses the path for its packets, and it also is responsible to detect outages in the currently used path. The information that is shared is the path information, where a path is defined as a destination address, a source address and a next hop. Next hop information is especially relevant for multilink hosts. The information about the quality of the path should also be shared because it is useful when selecting a path to avoid network failures. Failure detection is performed by each transport using different mechanisms: - TCP: data retransmission - UDP: received ICMP messages (Destination unreachable, Time exceeded) and it can also use some help from applications (requiring a new API to notify outages) TLC-FM needs a control channel to inform about the addresses available. Questions: Pekka Nikander: It is an interesting proposal. Isn't similar to CELP? Perhaps it should be joined with CELP? Arifumi Matsumoto: It is similar to CELP. The difference is the policy since each transport can have a different path. Erik Nordmark: How do you apply this to SCTP considering that SCTP test its own path? You probably want to share the path test information too for performance benefits. Arifumi Matsumoto: The problem is that such feature is not available in other protocols. Weak Identifier Multihoming Protocol (WIMP) ------------------------------------------- V. Torvinen The basic assumption is that there are lighter operations than public key crypto. The basic operations are much faster. WIMP has two main components: a context establishment phase and a readdressing protocol. WIMP uses non routable endpoint identifiers. Identifiers are hashes of strings (fqdn,and ephemeral identifiers). The reason for that is not to allow the attacker to steal the identifier. Basic cryptographic concepts used: - Hash chains: recursive calculation of hash starting from a random number and then feeding the next hash with the output of the previous hash. The main characteristic of this chain of values is that it is impossible to know the next value from the previous one, but you can verify the previous value. - Secret splitting: it is used to send parts of the spit secret through multiple paths, assuming that no one attacker can intercept all the paths during a readdressing operation. Basic operation: 4 way handshake is used to establish context. The anchor values of the initiator and responder hash chains are exchanged during this handshake. It is vulnerable to MITM attacks at the initial exchange. Major comments received are about endpoint identifiers and flow identifiers. Questions: Elliot Lear: This looks similar to Purpose Build Keys? Is it similar? Pekka Nikander: The goal is the same, but WIMP uses hash operations instead of public key crypto, which provides same functionality with better performance Masataka Ohta: Sequence numbers can also be hashed with a key and it is just as good, and why do you split keys? V. Torvinen: We split the secret to make return routability to the new addresses. Masataka Ohta: This can be easily snooped. Erik Nordmark: Return Routability test is used to verify that the end is at the address that it is claiming. Margaret Wasserman: Good draft, but about secret splitting usage, it seems that you have to reach the host at the previous address, what happens when the host is no longer available at the previous address? V. Torvinen: We haven't considered mobility. In the considered case, the initiator informs about the locators he wants to use. Pekka Nikander: Just to clarify about this, there are two options here. One is to run the address exchange protocol before loosing the path, so when the path is gone there are no problems. The other option is to split the secret in such a way that it is good enough to obtain only some of the parts of the secret. Margaret Wasserman: How fragmentation and PMTU discovery are handled? More comments on the list. Lightweight hip with delayed setup ---------------------------------- Pekka Nikander The biggest criticism received when trying to apply HIP to multihoming is that hip is too heavy. HIP in opportunistic mode provides protection against everything but initial MITM attack. The proposal is to preserve current level of security with less cost, by combining WIMP and HIP. The idea is to combine initial 4-way exchange of HIP and WIMP, so that initial messages carry both HITs and MAC of the anchors. The receiver then can choose to use HIP or WIMP. So the communicating nodes can continue to use WIMP as long as they want, but they feel that they are facing an attack you, then they can run full HIP to protect themselves. Still more in depth analysis of the potential introduced vulnerabilities is required. Questions: Richard Graveman: IKEv2 provides same features and also protects from initial MITM Pekka Nikander: You need PKI to protect initial MITM, since in opportunistic mode you can't protect initial MITM attack. ??: do you use IPSec in light mode? Pekka Nikander: no. Multihoming: the SCTP solution ------------------------------ L. Coene This draft essentially asses the SCTP multihoming solution with draft-lear-multi6-things-to-think-about-00.txt - No rendez vous for mobility are considered, since SCTP only performs the handover. - No additional latency, because data and control traffic are transmitted together. - No problems with DNS since it is only used to get an initial address. - For authentication: the proposal is to use PBK, and it seems that it will work. - How does the host knows its own ids? SCTP tries a subset of the IP addresses assigned to the host. - No extra load for DNS. - No extra upstream ISP support required. - The solution impact on the different sizes of sites from SCTP perspective is none since, SCTP doesn't care about the amount of addresses being handled. - About referrals: Question: Elliot Lear: the referral point is related to applications like FTP. Margaret Wasserman: Referral is not only about A telling B how to contact C, but also about A telling B how to contact A two hours later. L. Coene: I will review the referral aspects. Continue with the presentation: - No application changes are required - IP issues are solved in Christian's draft Questions: Margaret Wasserman: how does the draft addresses the point included in the goals draft? L. Coene: I forgot to include these points. MW: the goals draft require TCP and UDP support, how do you deal with that? LC: It is not supported Kurt Erik Lindqvist: RFC 3582 is a goals document, not a requirement document. Continue with presentation: Conclusions: - Some applications may be migrated to SCTP. - Reports about ADDIP messages in next meetings. - Deploy SCTP in carrier networks with multihoming support. - There is some work going on about multipath. Questions: Erik Nordmark: Is there some experience about selecting locator and paths available? LC: We are trying to collect the information. If IP is not working properly, there are problems. We are trying to collect more information about this. Framework for Common Endpoint Locator Pools ------------------------------------------- Avri Doria There are multiple multiaddressing schemes, so we are looking for commonalities between them, so that they can share the work done by the other mechanisms available in a host, sort of an opportunistic use of other's information. The goal is to reduce transaction cost. There are two types of schemes identified : transport approaches and wedge approaches. Each approach has its benefits, but not all them solve all the problems. The proposed approach is to create common locator pools, so that both transport and wedge solutions can contribute to it. Different granularities are proposed for the stored information: host, flows, protocols, ToS The next step is to look at each multiaddress solution to see what they can provide. Each solution can insert information into the pool, and also benefit from the information available in it. There are several issues but the idea is to start with a simplified mechanisms and then go to more complex solutions. There are also some security issue related with how do manage when multiple solutions with different levels of security insert information into the pool. Other issues related to names used to identify locators pools. The next steps are: resolve the security and naming issues above. Go through other proposals, as stated earlier. Identify near term issues and longer term issues. All proposals have value and probably many of them will de accepted. Questions: M. Ohta: Different protocols have different ideas about the availability of paths, retransmission times and so on. Since this information is protocol independent, so you cannot share the information. AD: Different attributes for different pools can characterize that, and the administration of the pool is complex, so that for each protocol you need specific information. M.O.: But if you make it protocol wise, you don't have shared information then. Kurt Erik Lindqvist: Take it to the list. Operational Approach to achieve IPv6 multihomed network ------------------------------------------------------- K. Toyama In IPv6, it is assumed that only aggregated routes will be advertised globally. This is a routing based solution, wihtout affecting the global routing table. It is proposed that a /32 and an AS number is assigned to the multihomed costumers of a group of ISPs, and that a /48 of this /32 assigned to each multihomed site. Peering relationships are established between the involved ISPs that serve the multihomed clients, so that each ISP injects the complete aggregate to the Internet. So the ISPs cooperate. The request is to allow the allocation of the resources required by the solution. Questions: Erik Nordmark: what happens if one of the ISPs goes down completely? K.T.: The other one provides backup. Elliot Lear: this solution can be implemented wihtout changes, but have you talked to ISPs about how do they feel about implementing this? K.T.: Not all pair of ISPs will want to cooperate. Francis Dupont: I have published something similar a long time ago. Peter Lothberg: There is not a single cloud which is the global Internet. End of 00 presentations ----------------------- Presentations about specific charter items ========================================== Things MULTI6 Developers should think about ------------------------------------------- Elliot Lear This is not a requirements document. It contains things beyond multi6 scope. It is not an architectural draft, it is about operational issues. It is not a position paper. It is a collection of operational questions, several of them are interrelated. For instance performance and security issues are considered in all the document. Key issues considered in the document: - Protocol on the wire: packet format changes introduced? and in which layer? Why that layer was selected? Impact on transport layer (pseudo header)?. Required changes on fragmentation? Additional latency? Are the changes required by all hosts or only multihomed hosts? - Security: How do you secure the binding between different names involved? Are there any new DOS opportunities created? Do you rely on other security infrastructure? - name/binding issues: Which is the lifetime of the binding? How is the binding updated? Do you introduce a new namespace? if yes, then, how does it looks like and how is it managed? Which is the relation with DNS?Is there any upstream ISP support required? Are there any dependencies on middle boxes? if yes, then what if they fail? - If the DNS is used: are there any circular dependencies between DNS and the routing system. Are there any new RRs? Is the FQDN goes in every packet? How is two faced DNS supported? Question: Pekka Savola: circular dependencies are more general than only to the DNS. E.L.: Yes. Continue with presentation: How does a host knows its own identifiers? Does the solution place an additional load in the DNS? Is DNSSec performance an issue? - Application implications: is it a new interface required? How do you support referrals like ftp, sip? - Backward compatibility: How the solution works with old IPv6? Can old IPv6 devices benefit from the solution? Do non-multihomed sites have to make changes? Changes are required on hosts, routers, both? Are there any changes in the management model? Two tests are suggested: how do you implement your solution in an IETF conference network? Have you tried in a lab? - Legal stuff: Do you create a new mnemonic namespace? How do you manage it? The goal of the draft is to compare results between proposals, creating a matrix to compare results. Perhaps even to merge similar solutions. Question to the Working Group: How many people have read the draft? Many hands. Do you think it needs more detail? M. Wasserman: It should be a living document, since changes will be introduced in the future. One thing I like to see added, about have delayed setup. When I start talking, do I need to know if the other end supports the multihoming solution? Another issue is, do we know which are the right answers? E. Lear: We should determine the set of important questions. Kurt Erik Lindqvist: Application people input is required. Security issues are listed, so the idea is to list the goals for security in each proposal. We don't want the document to contain the answers of the questions, we leave this for later. Pekka Savola: Some issues should be expanded, like what are the critical things. Some of the answers for this questions provided by the solutions are missing the point, so perhaps we should clarify. M. Ohta: The draft is very good, the checksumming issue should be included. K. Lindqvist: This is one of the new charter items, so Question to the Working Group: Who wants this as a working group item? Many hand for yes and no hand for no. An Architectural View of Multi6 proposals ----------------------------------------- Geoff Huston Clarification: specific proposals are used just as examples. There is a very large amount of proposals and some look similar. The goal is to try to make a taxonomy based on the architectural goals of the proposals. Problem space is a multihomed site. Note that there may be more that two ISPs, and that communications don't only involve 2 parties always. Exit routers and hosts appear because they are included in several proposals. Presentations of the goals presented in RFC 3582 and some of the questions of Elliot's draft. There are three mayor approaches: - Wedge a new layer in the stack: Based on Soch's work (who, where and how) while in IP only the IP address is used for all of them. These proposals are trying to disambiguate the who from where and how. - Modify the stack, whether transport or IP - Modify the local interaction: Destination based forwarding algorithm is modified to select the right exit. Wedge solutions. Can be placed above IP or above the transport layers. Most proposal are below transport. ULP deal with an identity token and IP deals with locators. The hosts control the locators set but the ULP are not aware of the changes. There is an identity peering between the communicating hosts. There are many ways to do this: - Conventional: add a new OSI layer -> new header trailer, communication in band. - New control channel (out of band): can communicate even without data. It has its own triggers. - Refer to a third party, like the DNS. While architecturally all are the same, there are changes in the implementation. Modification to existent layers. - Fatter transport: SCTP example where pools of locators managed by transport. A new transport is needed. - Modified IP: One IP address is an alias for identity and the other IP address is an alias for location. Modified host/router interaction - Doesn't fit the layer model nicely. - The problem solved is that when a source address is selected and the wrong ISP is used, the packet is discarded - This means that when selection the source address implies a topological decision. IPv4 multihoming style: not an option? Common issues identified: - Required locator selection mechanisms by the host. - One's source locator is the other's destination, so this selection imposes the reverse path. - How is the selection among different destination locators? - How do you change locators once that the selection is made? when a change is needed? how are network failure detected? Some examples of analysis for proposals: - HIP: Shim layer between transport and IP. A stable identifier is presented to transport layer. Multiple locators are bound to a fixed identifier. So, locators can change in a session. - SIM, NOID and CB64: Shim layer approaches. NOID is referential, SIM uses protocol exchanges and CB64 is hybrid. Additional elements since exit router rewrite packets About namespace structure: - Hierarchical -Identifiers are part of the IP address space. - FQDN are used. Problems with the interaction between DNS and routing. The DNS may not be good enough for this mapping - New token: why is it needed? what feature is not available in existent namespaces? - Opportunistic: no need to manage the name space. How referrals are handled?, How searches are performed? SCTP: Heartbeat required to trigger locator change MIPv6: Only one locator valid in a give moment, encapsulation carrying the locator in the outer header and identifier in the inner header Modified host/site-exit interaction: Site forwarding paradigm is changed. Multiple options, like anycast address, source address based forwarding, source address rewriting. Other option is to provide a solution for the initial problem which is ingress filtering, so just release ingress filtering. Common issues: - How do you select best source locator? - How do you select the best destination locator? Detecting network failure - Heartbeats - Transport - ICMP from router - Note that failure between startup and once the session is established Security is not in the scope of this work, worthy of a separate analysis Questions: Erik Nordmark: The approaches that change the host/router relation, make the edge more explicit? G.H.: Yes, perhaps reality is not like this. E.N.: Are there any other architectural implications with making this border explicit? G.H.: If this model is mapped to reality, do you have a clean idea of what the exit is? M. Wasserman: what is the process in order to move more into details from here? Kurt Erik Lindqvist: Doing a document about proposals doing an evaluation referred to this taxonomy, and classify the proposals according to this. Besides with Elliot's draft we could have a benchmarking of the proposals. M.W.: I am worried that the architectural analysis is based on proposals, and that what is not covered by proposals is not included in the analysis. K.E.L.: Many proposals overlap, so we need to group them together Dave Crocker: Multihoming and mobility can be covered with similar mechanisms G.H.: I think the assumptions made by the solutions in both cases is that the identifier can be used as a glue between locators. D.C.: It may be complex if we try to solve all the problems in one and it may take forever. OTOH, separate solution may make things even more complex. Pekka Savola: A general comment: To progress we have to figure out deployment scenarios, and not only one solution will fit all the scenarios. K.E.L: Yes, that is why the document describing current IPv4 multihoming solutions is needed. James Kempf: Define deployment scenarios and simulations to see how this work K.E.L.: last comments on how do we proceed. The assumption was that Geoff would write a document with the architectural analysis. Additionally, we have to move forward the threats draft. Perhaps an interim meeting is needed.