2.4.8 Site Multihoming in IPv6 (multi6)

Last Modified: 2003-06-04

Sean Doran <smd@ab.use.net>
Kurt Lindqvist <kurtis@kurtis.pp.se>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
Mailing Lists:
General Discussion: multi6@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe multi6
Archive: http://ops.ietf.org/lists/multi6
Description of Working Group:
A multihomed site is a site that has more than one connection to the
public internet with those connections through either the same or
different ISPs. Sites choose to multihome for several reasons,
especially to improve fault tolerence, perform load balancing, etc.

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

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).
Goals and Milestones:
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.
No Current Internet-Drafts
Request For Comments:
Cryptographic Message Syntax (CMS)

Current Meeting Report

Multi 6 Monday 1300 - 1500

Agenda - overview of submitted drafts

Agenda bashing: none

- - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min

        For background:

  Host Identity Protocol (HIP) has been around for some time. New 
namespace protocol with a history of around 4 years. Today sockets are 
bound to IP addresses, forcing the IP address into a dual role of 
endpoint identifiers and forwarding identifiers. HIP introduces a new 
namespace between the network and transport layers. The sockets are bound to 
host identifiers that are dynamically bound to IP addresses. Hosts are 
identified with public keys, not IP addresses, and apps see only the HIP 
identifiers. The apps need not change is the assertion. Hosts can easily 
have both IPv4 and IPv6 addresses, and the assertion is that end-host 
multi-homing and mobility is trivial. HIP Proxies are described as a kind of a 
hack. HIP may be a part of the multi-homing architecture. 4 
Interoperating implementations, intend to send the drafts to the IESG, and 
more work is needed on mobility and multi-homings with NAT traversal. HIP is 
not a working group but is progressing in the background. HIP is a 
multi-address solution with end-to-end. It solves only one aspect of 
multi6, and has no specific solns for address selection or TE

Matsataka Ohta: You said "HIP Proxy" - do you support 
multi-proxies for backup
Pekka Nikkander: There is no easy way to have multi HIP proxies in some 
situations, and it does represent a single point of failure

- - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min

  SCTP approach - endpoints have multiple addresses, where each IP 
address represents a path to a particular endpoint. SCTP is not aware of the 
level of path distinguishing - it would be good if they were, but this is 
not a known property. SCTP can detect path up/down. (Example of 
host-to-host with 2 addrs on each host). Multi-homing open up new 
horizons for SCTP: add and remove ip addresses dynamically to the 
endpoint, that can support mobility. Functionality at the endpoint is 
asserted to be superior to network functions in this regards. It does 
imply that the host requires a routing table - not a big deal for a host is 
the claim. But a big table is required for a system with a large 
connection load. How to maintain the routing table is claimed to be 
implementation dependant (pre-configured or caching the INIT). NATs are in 
the draft because they wanted to warn everyone how bad NATs really are! NAT 
cases for SCTP generates problems that do no appear to have 
straightforward solutions. From the transport level SCTP is claimed to be a 
'should work' solution.

Lixia Zhang: How about UDP?
Lode Coene: its the same problem, with the application having to 
undertake the selection.
Erik Nordmark: what algorithms have been used in SCTP work to select 
source and destinations? Any write ups of this work?
Lode Coene: none known to me.

- - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min

  Proposes to use MIPv6 to the multi-homing (mh) problem. Example in 
presentation of recovery from current to backup path (Using alternate 
addresses) Both paths have to be bound and identified _before_ an outage 
using binding update messages. The alternate binding will use the Home 
Address Option. Since MIP already needs the exchange of messages along each 
path, this exchange can be used as a path keepalive. The lifetime of the 
binding is limited to 7 minutes, and this is considered to be very short. 
Possible solutions are proposed

Matsataka Ohta: IPv6 has large timeouts for various purposes. If your 
proposal to have the same property so that the new address can be used 
Marcelo Bagnulo: this issue is to build a path outage detection, and we are 
proposed to use the packet exchange for this purpose. The idea is to use the 
same packet format, but change the timing.

- - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min

  General introduction on IP and IPv6. References 8+8 Locator and 
endpoint I-D. The proposal is to let end systems have multiple 
addresses. Let the other end select the 'best' address. (The host 
addresses are part of multiple upstream aggregates). The general 
architecture proposed is to let the network inform the host about state to 
allow the hosts to undertake address selection. When should a host 
attempt alternate addresses? Proposed in response to ICMP, routing 
change, timeouts (TCP only). Proposed that applications have an IP (and 
UDP)-defined packet timeout to trigger alternate address use. For very 
short timeouts it is proposed to send multi-copies of the packet with 
multiple addresses. e-2-e mh and IP mobility are similar, although there is 
mobility timing at the IP layer. e2emh has been implemented and running on 
NetBSD with LIN6, with modifications to the stack as described in the 
presentation. The design framework proposed is to make everything 
optional. Exercising no options is single-homed. Use 8+8 Locator/Id 
separation, with packet reception and connection identification 
determined by the ID. Application to mobility is also described. 
Multiple addresses are supplied to the peer by reverse query of DNS using an 
ID query key followed by a forward query, or carry in the TCP header or a 
new DNS query type. e2e approach is proposed as scaleable 
architecture. MH and mobility are related, and the approach uses 8+8 

Pekka Nikkander: You did not mention security issues in your 
presentation - is this to be addressed later on, or do you have 
comments now?
Matasaka Ohta: The current Internet is weakly secure. Cookie-based 
security for locator change give only the same level of security.

Peter Werny: What is required in the DNS for this to work?
Matasaka Ohta:  this is different from current V6, as it only uses the 
identifier 8 bytes. In DNS we look up locators of location agents using ID of 
Peter Werny: Every host has to have a DNS entry?
Matasaka Ohta:If there is no DNS and not TCP then you are 
single-homed, and you cannot use this mechanisms.
PW: Your draft has no mention of DNS update
Matasaka Ohta: Location is not in the DNS - just the location agent.
Erik Nordmark: Are you assuming a structure for the identifiers?
Matasaka Ohta: It should be reverse lookup-able. Its better to have 
hierarchy in the identifier space, but you can do without hierarchy if you 
use TCP instead of the DNS to pass the multiple addresses

- - 
draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min

  Each end application can determine a route to use. Applications select a 
route using a selection of a specific source and destination address pair. An 
end application can select a path without full route information is the 
claim. The attributes are claimed to include redundancy and load 
balancing. Modifications to hosts, routers and routing protocols is 
needed. Site exit router selection using source address routing enables 
redundancy, load sharing with multiple paths. Some mechanisms is needed for 
'proper' source address selection. Transport layer survivability could be an 
SCTP mechanism or other.

- - 
draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min

  Socket API extensions. Propose to use application layer, rather than the 
network. Uses 8+8 model. The API is for manipulation of multiple 
addresses in the application. LIN6 is based on the 8+8 model. LIN6 does 
address acquisition, notification, registration in a secure manner. Hosts 
identify their peer and themselves using only the identifier part. e2e-mh is 
seen to be an application of the LIN6 model. The trigger to switch 
locators is seen to be ICMP-based using host unreachable. APIs need to 
manipulate locators, to make a multi-locator-ready socket, allow API to 
change locators on the fly, and acquire remote locators. The details of API 
changes described, in socket(), getaddrinfo() and 
getsockopt()/setsocketopt(). APIs are intended for active mh 
applications. UDP requires application support. Future work is to put 
support in to the TCP level, so that no changes are required for API for 

- - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min

  All hosts should have full default-free routing table. This allows 
selector in host to make optimal locator choice, and know when locator is 
unreachable. source address selection for ingress filtering only. The peer 
will not use the source address - it will make its own selection of a 
locator for the peer. Extended example of policy control and 

Pekka Savola: Both of these drafts have been obsoleted
Matasaka Ohta: not a problem!
? (MCI): IF an NLA gets address space from 2 TLAs which does it use?
MO: If gets 2 addresses, as does its customers. The number of prefixes 
cascades down.
? MCI): Scaleaility?
MO: yes, and NLA should be no more than triply homed.
Iljitsch van Beijnum: Why is the information in the routing table 
superior to information you can obtain from the other end?
MO: This does not have scaleability problems if you limit 
connectivity. This is a connectionless system where a host has no 
information about the other end, and the routing table is local 
information you can use.
Iljitsch van Beijnum: ok, but I disagree with this

- - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min

  Solution for traffic engineering for mh need sites in a 
multi-address environment. Each host has 1 address per upstream 
provider. Noted that choosing a source address implies choosing a 
provider (assuming providers perform source address filtering). Which 
source? A host has no information about which provider to use to reach a 
destination. Propose to use a dedicated agent (server). A host will query 
the server with a destination address, and the server responds with the 
source to use. The burden of selecting the source address is 
aggregated to a dedicated server. Note it gives only a hint to the host 
about what address to use. NAROS is not intended to preserve flows across 
address changes. SCTP or HIP could be used to preserve flows. The server 
could be anycast, or undertaken without provider interaction. The host / 
server protocol is a query response packet exchange. Where multiple 
choices exist, multiple parameters can be used to make the selection.

Pekka Nikkander: is this a new protocol, or, perhaps, ICMP
Cedric de Launois: No particular protocol - it could be ICMP
PN: There are security issues here, like secure neighbor discovery
Michael Richardson: Takes the example and adds further connections, and 
then adds a policy question about 'acceptable traffic' policies. Can NAROS 
deal with this>
CdL: A lot of requirements could be placed in the NAROS server and it 
could be aware of those kind of requirements.
Matsataka Ohta: Anycast does not include increased robustness for server 
failure. A NAROS server crash will not bring down a anycast route. Also 300 
seconds is too large a value.

- - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David 
Kessens, 20 min

  Simple multihoming experiment. A problem statement in a bounded 
example environment. A simple network is a single link where multiple 
hosts see multiple boundary routers where each router is connected to 
distinct upstreams. Addresses from providers are mapped to all the hosts. 
Asserted that this is not uncommon in V4 and that the common solution is to 
NAT the local net and allow the NAT to 'rehome' to each outbound. The 
consequence is flow breakage across the rehoming of the NAT. The bounds are 
that the ISPS do not exchange information, there are provider 
addresses with an assigned prefix per provider. Hosts configure an 
address with each prefix. Need to resolve host choice of egress router 
selection (as a function of the source address)

Erik Nordmark:  There are people talking about movement detection, and this 
gets all routers to advertise all prefixes
Christian Huitema: Thats not incompatible - several routers can 
advertise the same information, provided that the information is 
equivalent, and the routers can handle all such packets.
Pekka Savola: please clarify the applicability. This is only the case 
where hosts are directly connected to all egress routers.
Christian: this is a common case.
MO: You don't need tunnels in a single link network. In a multi-link 
network you need tunnels.
CH: This does nothing for MTU discovery. For single link there is a very 
simple solution and this can be extended for multi-links
MO: Ands I'm saying its impossible
CH: fine!

  No need for tunnels in a single link network, and the routers can pass off 
to each other in the event of dynamic failure. The assertion is that in a 
single link network this requirement can be easily met. Dead exist 
routers or dead ISP require some consideration. If the exit router knows 
that the path is dead it can send a poison advertisement of the prefix. The 
real issue with this form of mh is a very soft definition of 'broken' 
where the link may be up, but the path to the remote end point may be 
unuseable. This kind of problem is an e2e detection issue. Hosts may need to 
keep track of connections and track quality. If you know an ingress path is 
dead do you need to update the DNS to remove the dead prefix from your host 
entry? Of course you may not know and in this case your peer will need to 
work out what address to use. Maintenance of TCP connections is an issue. 
MIP6 may be an answer, or SCTP for 'new hosts'. For 'old' hosts, he 
connection will fail, and needs to be reestablished. Exit / entrance 
selection is also an issue. One approach is to only advertise the 
preferred address in the DNS if you have a primary / backup scenario. And in a 
1 + 1 scenario, then advertise both. On the outgoing the solution may be a 
local server to assist, or to document preferences in the routers. We 
appear to be able to design solutions that require changes to the IPv6 
standards, do no require address rewriting at exit points, but it could 

Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you need to 
change both ends?
CH: The support for the connected node in MIPv6 is supposed to be 
implemented everywhere.
PN: You need to change the address in both ends.
CH: The time appears to be around 5 or 6 minutes.
PN: If you are going to change the code at both ends then you should try HIP 
in your experiments as well.
CH: You are free to experiment with HIP
Fujikawa: It seems like an application cannot select different path from 
other applications in a host?
CH: No, not so. The host has several IPv6 addresses. An application that 
want to do path selection can bind to a source address and connect to a 
destination and select a path.
Matasaka Ohta: It is stupid to keep using a complication MIPv6
CH: Complexity is management of the Home agent and security functions to 
certain classes of attacks and you will need  to have some form of 
security in any case.
Matasaka Ohta: This only works in a single link case.

  In a larger site the problem is ingress filtering, because its harder to do 
source-based routing. The simple solution is to work with the ISP to lift 
source filters. Even larger sites have their own PI space and AS#.

IvB: Disable ingress filtering can be down for the local upstream, but the 
chain may extend upward
CH: ingress filtering in the middle of the Internet is a bad idea
MO: what will you do with a large site?
CH: lets call them medium
Bob Hinden: ISPs would be more amenable to break ingress filtering than 
route specifics.
?: Ingress filtering should not be an issues.
Mat Ford: Define a large site?
CH: establish a registry relationship!

- - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min

  Claimed that this is not the best solution in all cases, but better than 
some others. Need to avoid the routing mess of advertising more 
specific and need solutions soon. Approach to use the AS number to create PI 
space for larger enterprises. e.g. 2000:<ASN>::/32. Issues about 16 / 32 bit 
AS numbers, and a claim that 32 bit AS numbers would indicate a RIR 
policy failure.

Moshens VC(?): How do you get uniqueness of the prefix
PS: This is 2000 - it won't collide!
MO: There are already too many ASes deployed
Geoff Huston: You are assuming AS remain at 16bits. What happens when AS 
drain in 2011. and we move to 32 bit AS numbers? This is a relatively 
short term solution with a visible drop dead point - right?
PV: yes.
?: This is good solution
PV: an appendix shows how to deal with 32 bit AS numbers, but I don't 
lkike this solution.
Tim Chen: This cuts out the smaller sites that do not have ASs.
Randy Bush: Why reluctant to give out ASes to routing domains who's 
policy domains are different from their neighbors?

- - 
draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum, 15 min

  Geographical aggregation. Admitted that topology is not correlated to 
geography, and even if the geo part doesn't work there are still some 

MH: This gives little actual aggregation
?: Asymmetrical routes break in your model
IvB: Routing is asymmetrical in multi-homing in any case.
Tony Hain: Aggregatibility is the question. The concept appears fine, but 
you are making assumptions about aggregation boundaries 


Multihoming with HIP
Multihoming: the SCTP perspective
Application of the MIPv6 protocol to the multi-homing problem
Multihomed ISPs and Policy Control
IPv6 Address Assignment and Route Selection for End-to-End Multihoming
Basic Socket API Extensions for LIN6 End-to-End Multi-home
Introduction on the Architecture of End to End Multihoming
NAROS : Host-Centric IPv6 Multihoming with Traffic Engineering
Simple Multihoming Experiment
Multihoming Using IPv6 Addressing Derived from AS Numbers
Provider-Internal Aggregation based on Geography to Support Multihoming in IPv6
IPv6 Site Multihoming: Now What? (A view on what we should be doing now)
multi6 design team results and open issues