Network Working Group M. Bagnulo
Internet-Draft A. Garcia-Martinez
Expires: April 29, 2003 UC3M
October 29, 2002
Extension Header for Site-Multi-homing support
draft-bagnulo-multi6-mhexthdr-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This note describes an IPv6 multi-homing solution that achieves
equivalent fault tolerance benefits to those provided by current IPv4
multi-homing solution while preserving the route aggregation
capabilities of the Provider-based Aggregation scheme. The solution
lies on the inclusion, in every packet flowing to a multi-homed site,
of an extension header containing multiple alternative route
information to the destination, so that if the original destination
address becomes unreachable, alternative route is used for reaching
the destination.
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 1]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
1. Introduction
This note describes an IPv6 multi-homing solution that achieves
equivalent fault tolerance benefits to those provided by current IPv4
multi-homing solution while preserving the route aggregation
capabilities of the Provider-based Aggregation scheme. The solution
lies on the inclusion, in every packet flowing to a multi-homed site,
of an extension header containing multiple alternative route
information to the destination, so that if the original destination
address becomes unreachable, alternative route is used for reaching
the destination. Additionally, a Destination option is defined (the
Alternative Prefix Destination Option) to convey multiple alternative
prefix information from a multi-homed host to the other end of the
communication.
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 2]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
2. Solution components
2.1 Alternative Prefix Destination option
The following destination option is defined:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type |Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alternative Prefix #1 (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alternative Prefix #n (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type value is 000xxxxx (in bits): The two highest order bits
set to O, so that if the option is not recognized, the option is
ignored and the packet is processed [1]. This allows that hosts not
implementing this solution to be capable of communication with hosts
which do implement the solution. Note that multi-homing benefits are
lost in this particular communication. The third bit is set to 0,
since the option data does not change in the route [1]. Remaining
bits are set to xxxxx (TBD by IANA)
Option Data Length value is 4n+2, since the option contains n
Alternative Prefixes, and each one has 4 octets and 2 octets to
preserve alignment.
Alternative Prefix field contains alternative Prefixes assigned to
the source interface other than the one included in the Source
Address field of the IPv6 header [1].
The intended use of the above destination option is the communication
of multiple alternative routes to the multi-homed site, from a multi-
homed source node to a destination node.
2.2 Alternative Prefix Extension Header
A new Extension Header is defined with the following format:
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 3]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Pleft | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alternative Prefix #1 (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alternative Prefix #n (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next header value: 8-bit selector. Identifies the type of header
immediately following the Alternative Prefix Extension Header.
Hdr Ext Len: 8-bit unsigned integer. Length of the Alternative
Prefix Extension Header in 8-octet units, not including the first 8
octets.
Pleft: 8-bit unsigned integer. Number of Alternative Prefixes left,
i.e., number of Prefixes that have not been used for reaching the
final destination.
Alternative Prefix field contains alternative prefixes assigned to
the destination interface other than the one included in the
Destination Address field of the IPv6 header [1].
The Alternative Prefix Extension Header is identified by a Next
Header value of xx (TBD by IANA) in the immediately preceding header.
The position of the new extension header relative to the ones already
defined is after the routing header and before the fragment header,
since it is to be processed by intermediate routers when no route to
destination is found.
The intended usage of the above Extension header is the following:
when a router receives a packet and it has no route to the address
contained in the destination field, the router must look for an
Alternative Prefix Extension Header. If such header is included in
the packet, and the value of Pleft is different than zero, then the
router must swap the 64 most significant bits of the Destination
address with the ones located in the position number (Ext Hdr Len
minus Pleft) of the extension header. Then the router must update
the Pleft by Pleft minus one. Finally, the router must try to
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 4]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
forward the packet to the new destination address. If there is no
Alternative Prefix Extension Header or the Pleft value is zero, then
the packet must be discarded and an ICMP error must be sent to the
source.
If (No Route to Destination) AND (Exists Alternative Prefix Extension Header)
then
{
if Pleft = 0 {
Discard packet
}
else {
if Pleft is greater than Hdr Ext Len
{
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Pleft field, and discard the
packet
}
else {
decrement Pleft by 1;
compute i, the index of the next Prefix to be used by subtracting Pleft from Hdr Ext Len
and swap the prefix of the IPv6 Destination Address and the Alternative Prefix #i
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 5]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
3. Solution description
3.1 Scenario Description
+-----+
|Host1|
| |
+-----+
|
...
|
_______|_______________________________________
| |
| |
| |
| +------------+ +------------+ |
| | PA::/nA | | PB::/nB | |
| | ISPA | DFZ | ISPB | |
| +------------+ +------------+ |
| | | |
|_______|_____________________________|________|
| |
| | ^ | | ^
| | |PA:PC::/nC |link2|
0::/0| link1 | 0::/0| | |PB:PD::/nD
V | | V | |
+---------------+ +---------------+
| ISPC | | ISPD |
| PA:PC::/nC | | PB:PD::/nD |
+---------------+ +---------------+
| |
| |
| |
link3 link4
__|____________________________|___
| RA RB |
| |
| Multi-homed end-site |
|PA:PC:PS1::/n1 Host2 |
|PB:PD:PS2::/n2 |
|___________________________________|
The considered scenario is as follows:
A Multi-homed end-site obtains global connectivity through two ISPs
i.e. ISPC and ISPD. These ISPs do not belong to the Default free
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 6]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
zone and they buy transit from ISPA and ISPB respectively. ISPA and
ISPB do belong to the Default Free Zone i.e. at least one of their
routers have full routing information. In the figure above, some of
the routing information exchanged between peers is included. Since
the end-site is multi-homed, it has obtained two address ranges: one
delegated from ISPC address range i.e. PA:PC:PS1::/n1 and the other
one from ISPD address space i.e. PB:PD:PS2::/n2. ISPC and ISPD have
obtained a range of the address space from the address range assigned
to their respective providers, i.e. ISPA and ISPB. So ISPA has
delegated the range PA:PC::/nC to ISPC and ISPB has delegated the
range PB:PD::/nD to ISPD.
3.2 Normal operation.
Let´s now consider the possible communication between Host1 (a given
host in the Internet) and Host2 (a host belonging to the multi-homed
end-site considered)
Since Host2 belongs to the Site, it has at least two addresses i.e.
PA:PC:PS1:PL1:IIdHost2 and PB:PD:PS2:PL2:IIdHost2, which will be
included in the DNS (if we suppose that Host2 wants to be reached
through the two providers). It should be noted that the solution
requires that all addresses of the same interface used in the
solution share the Interface identifier part
Communication initiated by Host2.
Host2 sends a packet to Host1 address and it includes a Alternative
Prefix Destination option with all the different prefixes it is
willing to use to receive replies to this packet. When Host1
replies, it addresses the packet to the source address included in
the first packet and it also includes in the reply packet an
Alternative Prefix Extension Header with the prefixes included in the
Alternative Prefix Destination option of the initial packet. When
Host2 receives the reply, it verifies that the destination address
and all the prefixes included in the Alternative Prefix Extension
Header are assigned to its interfaces. If at least one of the
derived addresses is not assigned to any of the interfaces, the
packet is discarded (See Security Considerations Section). Even if
different packets of a given communication may have different
destination addresses, Host2 must present them to its upper layer as
if they had the same destination address. This can be done since it
is possible to identify the original destination address used by
Host1 in the following way: If the Ext Hdr Len value in the
Alternative Prefix Extension Header is equal to the value of the
Pleft field, then the original Destination address is the one
included in the Destination Address field of the IPv6 header. If the
Ext Hdr Len value in the Alternative Prefix Extension Header is
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 7]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
greater than the value of the Pleft field, then the original
Destination address can be reconstructed by replacing the prefix of
the address included in the destination address field of the IPv6
header by the first prefix included in the Extension header. Then
the packet exchange will continue as above.
Communication initiated by Host1:
Host1 performs an A-type query to the DNS and it obtains two
addresses i.e. PA:PC:PS1:PL1:IIdHost2 and PB:PD:PS2:PL2:IIdHost2.
At this point Host1 can make two different uses of the obtained
information:
First option: Host1 uses one of the obtained addresses as the
destination address and it includes the other address in an
Alternative Prefix Extension Header. This option would provide the
same treatment for all the packets sent by Host1 and in particular it
would provide fault tolerance for this packet. However, this option
would imply some changes in the way applications manage multiple
addresses obtained from a DNS query.
Second option: The first packet is sent using available fault
tolerance capabilities when multiple addresses are available i.e.
Host1 sends a first packet with one of the obtained addresses and if
no reply is obtained it retries with an alternative address. When
finally a reply is received, an Alternative Prefix Destination Option
is included in it, so that alternative addresses are learned, as in
the previous case.
Eventually, in either case, packets flowing from Host1 to Host2 will
carry the Alternative Prefix Extension Header, and communication will
continue as detailed above.
3.3 Fault Tolerance Support
We will next study fault tolerance performance of the solution.
Let´s suppose that Host1 is sending packets to Host2 address
PA:PC:PS1:PL1:IIdHost2 and Link1 fails. In this case, when next
packets arrive to ISPA, there will be no route to the destination, so
the ISPA router with no route to destination in its routing tables
will look for an Alternative Prefix Extension Header in the packet.
If this header is found, it will be processed and the prefix of the
destination address will be replaced with the one found in the
extension header, and the packet will follow the alternative route
towards its destination. Some may argue that Alternative Prefix
Extension Header processing imposes an unacceptable load in routers,
specially in Core Routers. Another issue that could be raised, is
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 8]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
the need for upgrading all the routers of the ISP in order to be able
to process the newly defined Extension Header. A workaround for this
issues can be found by noting that the extension header processing
can be performed by specific upgraded routers connected to the ISP
network which would work in the following way: These upgraded routers
announce a default route (in our example, the upgraded router is
connected to the ISPA network and it announces the a route to 0/0).
Then if link1 is working properly, longest prefix match rule will
make packets flow through link1. If link1 is down, packets will be
forwarded to the upgraded router, that will process the Alternative
Prefix Extension Header, swapping prefix information. Once this is
done, it will forward the packet to the ISPA network, and then to the
alternative route. A slightly different approach is needed to
provide a sink route for packets with unreachable destination address
when link3 fails. Since ISPC obtains a default route from its
provider ISPA, it is not possible to announce a default route to sink
packets with unreachable destination, as in the previous case where
the ISP (ISPA) belongs to the default free zone. In this case, the
upgraded routers announce a route to the address range allocated to
the ISP (in our example, the upgraded router is connected to the ISPC
network and it announces the a route to PA:PC::/nC). Then if link3
is working properly, the longest prefix match rule will make packets
flow through link3. If link3 is down, packets will be forwarded to
the upgraded router, who will process the Alternative Prefix
Extension Header, swapping prefix information. Once this is done, it
will forward the packet to the ISPC network, and then to the
alternative route.
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 9]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
4. Security Considerations.
The extension header and the destination option defined above may
seem to introduce new security risks, since they seem to enable the
inclusion of spoofed alternative address. This would allow different
type of attacks such as communication hijacking. However, this
situation can detected by the host belonging to the multi-homed site,
since if any of the addresses included in the Alternative Prefix
Extension Header does not correspond to a configured one, the packet
will be discarded. This makes us to conclude that packets carrying
the newly defined option or header are not more susceptible to
attacks than regular unicast packets. It must be noted that both
types of packets are susceptible to man in the middle attacks, but
the goal of this solution is not improving security features but
avoiding the introduction of new security risks.
IPSec support: Alternative Prefix Destination option does not change
in route so interaction with IPSec is straightforward. Alternative
Prefix Extension Header can be modified en-route, as well as the
destination address of the IPv6 header during extension header
processing. However, original IPv6 header and extension header can
be reconstructed at the destination with the information included in
the packet, so this solution is compatible with IPSec.
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 10]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
5. Acknowledgements
We would like to thank Ignacio Soto, Juan Francisco Rodriguez
Hervella, Iljitsch van Beijnum and Michael Py for their reviews and
comments.
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 11]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
References
[1] Hinden, R. and S. Deering, "Internet Protocol, Version 6 (IPv6)
Specification", December 1998.
[2] Hinden, R. and S. Deering, "IP version 6 Addressing
Architecture", July 1998.
Authors' Addresses
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Alberto Garcia-Martinez
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/alberto
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 12]
Internet-Draft Extension Header for Site-Multi-homing support October 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bagnulo & Garcia-Martinez Expires April 29, 2003 [Page 13]