3- IPv6 site multi-homing solutions taxonomy.

	In this section we will present three different approaches to the multi-homing issue: 
topological constraints, address engineering and end-to-end. Additionally, several solutions 
that have been proposed based on the different approaches, will be referenced.

3.1- Topological constraints.
 
	The approach presented in this section is based on the application of topological 
constraints to the network connectivity. This is based on the observation that the multi-homed 
sites contribution to core-network route table growth is due to the fact that the different 
paths to the multi-homed site can only be aggregated into one route in the DFZ. So, the basic 
idea of this approach is to impose aggregation points somewhere below in the network hierarchy 
where the different paths (routes) to a multi-homed site converge. There are two possible types 
of constraints that will be presented in the following order: constraints to the attachment point 
of the multi-homed site and global network topology constraints. 

3.1.1- Multi-homed site network attachment point constraints.
The most restrictive option would be to limit multi-homing to only one provider. In this case, 
as the site can only have several connections to the Internet through one ISP, only one route 
to that site is propagated beyond this particular ISP, keeping all the multi-homing issues internal 
to that ISP. There are several obvious unacceptable drawbacks in this solution, among which we can 
highlight the extremely limited fault tolerance and insufficient policing features. 
In order to improve this proposal, the aggregation point can be placed higher in the network hierarchy. 
An attempt to achieve this is the Exchange based aggregation. In this case, an address range is assigned 
to an exchange point and the sites attached to the providers with presence in that exchange may obtain their
addresses from that range. This enable site multi-homing with different ISPs of the exchange without leaking 
routes outside the given exchange. It also enables the change of ISP without renumbering as long as the new 
ISP is connected to the same exchange. Even though this proposal is more robust than the previous one, it 
still has a single point of failure in the exchange point. Whether this is acceptable or not, it depends on 
the specific needs of the particular site. It should also be observed that this solution has a limited 
geographical scope, meaning that, since all the ISPs that a site multi-homes to must be attached to the same 
exchange point, this solution will be hardly compatible with the needs of a world-wide extended site. 

3.1.2- Network topology constraints.
If we try to place the aggregation point higher in the hierarchy once more, in order to overcome the weaknesses 
of the previous proposals, we have to impose more general restrictions that apply to the whole network and not 
only to the multi-homed sites. An attempt to do this are the geographical aggregation schemes, such as the 
Provider Independent addressing[3]. These addressing schemes provide aggregation based on geographical proximity, 
and in order to achieve it, they impose that all the different providers of a particular area meet in an 
aggregation point of that area, just like the telephone system. It should be noted the major architectural 
impact of these “centralised” aggregation points, in contrast with the traditional peer to peer design of 
the Internet. However, it is also important to notice that an geographical aggregation, as it is stressed 
in [3], can coexist  with other aggregation mechanisms such as the Provider aggregation used in the Internet today.

3.2- Address engineering.

Internet addresses identify not only an end point attached to the network but also the route to reach it. 
This means that an address contains both identification information and routing information. In the IPv4 
world, the fact that usually only one address is assigned to each interface, has soften the problem presented 
by this linkage of information. However, in the IPv6 world, where an interface usually has several addresses, 
and where provider based aggregation imposes a different route for prefixes delegated by different ISPs, this 
rigid identification-routing information association precludes the possibility to use alternative available 
routes to a given destination. Address engineering approaches are a workaround to this problem; essentially 
destination addresses of the packets are changed for another address with equivalent identification information 
but with  different routing information in order to change the path followed by the packet. Obviously, the 
initial address must be restored in order to provide transparency to end nodes. 
The simplest mechanism for address engineering is tunneling. The basic idea behind this approach is that 
the endpoints of the tunnel are aware that two different addresses share the same identification information 
but with different routing information. Then, the endpoints of the tunnel can reach a destination through two 
different paths, either by sending the packet directly into the net or by encapsulating it into the alternative 
destination address. The proposed application of the former mechanism to a multi-homed site[4], allows the 
packets to be forwarded through the alternative ISP, using the tunnel mechanisms, when the usual  path is not 
available. The main drawback of this particular approach is its limited fault tolerance, since the fault domain 
is limited to the direct service providers. In case of a failure somewhere higher in the hierarchy, connectivity 
is lost.
In order to improve the fault tolerance capability of the solution, state information, meaning the mapping 
between different addresses containing equivalent identification information but different routing information, 
can be stored in other fashions. One possibility is to use a database to store this information. It has been 
proposed the usage of the DNS. However, this solution must be thoroughly studied because of the dependencies 
already existing between the DNS and the routing system i.e. the DNS needs routing for proper functioning. 
Another possibility is build an new database that contains such information, as it is proposed in [5]. This 
approach presents at least complexity as a major drawback and it also has an important architectural impact 
on the network, since it may introduce a server role in the current peer to peer routing system. Another 
possibility is to store the state information directly in the IP layer of end hosts as it is proposed in [6]. 
The main problem with this proposal is the difficulty to access reachability information since this one is 
available only to the routing system  Finally, it could be conceived a distributed peer to peer location of 
this information, according to the architectural principles of the Internet routing system. 

3.3- End to End.

Another option is to state that multiple addresses due to multi-homing is an issue that it will not be solved 
by the network and that end hosts will have to cope with, just like reliable delivery. In this case, and 
end-to-end solution is needed. So end hosts will have to manage the different addresses and they will need 
to know when to use which one. They should also be able correctly retrieve the information flow from a 
sequence of packets with different destination addresses. At the end host, these tasks can be performed 
at two different levels: TCP level or application level. A transport level solution is  application 
transparent, but a specific solution need to be developed for each transport layer used. The particular 
case of TCP is addressed in [7], but solution for connectionless protocols such as UDP are less clear. 
The application layer can take care of the problem as it is presented in [8], which obviously imposes 
that each application develops a module to cope with multiple addresses in the case that the hosts that 
are running the application were placed in a multi-homed site. 
The main obstacle  that this approach is coming up against is the lack of network status information at 
the end nodes. A possible solution to this problem could be just to guess, i.e. if an address fails, just 
try with another one. Clearly, this solution is much less than optimal and expected latency is high. Another 
solution could be to obtain the needed information from some network element such as the routing system. 
There are some open issues in this option, like end host-routing system interaction or how far the needed 
information resides.