Individual Submission K. Loch
Internet-Draft HotNIC LLC
Expires: May 20, 2005 November 19, 2004
IPv6 Multihoming with Alternate Path Encoding
draft-loch-multi6-alternate-path-encoding-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 May 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo provides a method for multihoming IPv6 networks. A
multihomed site assigns IPv6 interface addresses using some of the
network bits from one or more alternate networks. IPv6 routers may
use this encoded path information when making routing decisions. If
a sufficient number of IPv6 routers use this method then benefits of
multihoming can be realized by any multihomed IPv6 site. This
method may also be used for separate site load distribution as a
limited form of anycasting.
Loch Expires May 20, 2005 [Page 1]
Internet-Draft IPv6 Alternate Path Encoding November 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problems Addressed . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . 4
4. Alternate Path Encoding . . . . . . . . . . . . . . . . . . . 4
4.1 Host and Site-local Subnet Bits . . . . . . . . . . . . . 4
4.1.1 Subnet Unique Host Identifier Requirements . . . . . . 5
4.2 Alternate Path Information . . . . . . . . . . . . . . . . 5
4.2.1 Single Alternate Path Requirements . . . . . . . . . . 5
4.2.2 Dual Alternate Path Requirements . . . . . . . . . . . 5
4.3 Path Preference Bits . . . . . . . . . . . . . . . . . . . 6
4.3.1 Path Preference Bits Requirement . . . . . . . . . . . 6
4.4 Alternate Path Encoding Indicator . . . . . . . . . . . . 6
4.4.1 Alternate Path Encoding Indicator Requirement . . . . 6
4.5 Single Alternate Path Example . . . . . . . . . . . . . . 8
4.6 Dual Alternate Path Example . . . . . . . . . . . . . . . 9
5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 General Routing Requirements . . . . . . . . . . . . . . . 10
5.2 Single Alternate Path Mode . . . . . . . . . . . . . . . . 11
5.3 Dual Alternate Path Modes . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Loch Expires May 20, 2005 [Page 2]
Internet-Draft IPv6 Alternate Path Encoding November 2004
1. Introduction
Alternate Path Encoding allows an IPv6 interface to simultaneously
utilize address space from two or three IPv6 networks while using
only one globally unique unicast address. This is accomplished by
assigning some unique network bits from the alternate network(s) to
some of the Interface ID and SLA bits on the interface IPv6 address.
IPv6 routers will then be able to use this alternate path information
along with the rest of the network bits to help make routing
decisions. A feature is provided to encode preference between the
primary and alternate path(s).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Terminology
Address - An IPv6 address.
Interface - An IPv6 capable logical network interface.
Router - An IPv6 router.
Bit - A higher index number refers to a more significant bit.
3. Problems Addressed
In order to minimize the number of routes in the global IPv6 routing
table, it is desirable to allocate blocks of globally unique
addresses in a hierarchical manner and limit route table entries to
the highest hierarchical levels. This makes traditional IPv4 style
multihoming impractical for most networks. Alternate Path Encoding
provides some of the benefits of traditional IPv4 multihoming and
anycast without any protocol changes or extra routing table entries.
3.1 Benefits
There are two key benefits Alternate Path Encoding (APE) has in
common with traditional IPv4 multihoming:
o Alternate routing path(s) if link to one network is disrupted, or
one network has routing problems.
o Some ability to direct inbound traffic between multiple providers
(load balancing, traffic shaping, cost management)
In addition,
Loch Expires May 20, 2005 [Page 3]
Internet-Draft IPv6 Alternate Path Encoding November 2004
o No additional routes are required in global routing tables.
o A globally unique Autonomous System number is not required
o Traffic can be directed between multiple separate sites if
desired, similar to anycasting.
o APE requires only minimal changes to routing algorithms and
voluntary configuration of interface addresses by the
administrator of the multihomed site or "anycasted" sites.
o No new protocols, protocol changes or extension headers are
required.
o Applications need not be aware of Alternate Path Encoding.
o Implementation is voluntary with minimal chance of side-effects
for non-participants.
o Routers that do not detect and/or use the alternate path
information will still route traffic to the primary network.
3.2 Limitations
There are some limitations to APE:
o A maximum of two alternate networks (for a total of three
networks) can be encoded on a single unicast address.
o Renumbering when changing networks is not eliminated and is
actually made worse because changing any of the networks requires
renumbering. Worse yet, even changing the routing preference
between the the networks requires renumbering.
o It is possible (though unlikely) that an IP address will be
misidentified as having Alternate Path information (due to having
the Alternate Path Indicator bits being set). In extremely rare
cases this could result in packets being misrouted. The most
likely scenario however is that these misidentified packets will
be routed properly due to the decoded Alternate Path(s) not being
in the routing table. Site administrators have complete control
over the bits used for the Alternate Path Indicator, so avoiding
or correcting these situations is possible. This problem could be
eliminated by requiring all global unicast addresses to have
correct Alternate Path Indicator bits.
4. Alternate Path Encoding
4.1 Host and Site-local Subnet Bits
While 64 bit interface ID's are useful for generating unique
link-local addresses, they are not necessary for practical globally
unique unicast addresses. In addition, a generous 16 bits of site
subnet information are used by current allocation guidelines. By
using fewer bits for subnet and interface identifiers, we can use the
remaining bits for encoding alternate path information.
Loch Expires May 20, 2005 [Page 4]
Internet-Draft IPv6 Alternate Path Encoding November 2004
For interfaces using Single Alternate Path Encoding, we allocate 12
bits for site subnet information, and 12 bits for a subnet-unique
interface identifier, leaving 56 bits for encodinalternate path
information.
For interfaces using Dual Alternate Path Encoding, we allocate 4 bits
for site subnet information and 4 bits for a subnet-unique interface
identifier, leaving 72 bits to encode the alternate path information.
Because we are assigning path information to address bits 57 and 56,
those bits loose their meaning as universal/local and
individual/group as specified in [RFC2373].
4.1.1 Subnet Unique Host Identifier Requirements
For interfaces using Single Alternate Path Encoding, a 12 bit
subnet-unique interface identifier MUST be assigned to bits 11
through 0 of the interface address.
For interfaces using Dual Alternate Path Encoding, a 4 bit
subnet-unique interface identifier MUST be assigned to bits 3 through
0 of the interface address.
4.2 Alternate Path Information
For Single Alternate Path Encoding, we use the 48 most significant
bits of the alternate network's addresses to indicate the alternate
path.
For Dual Alternate Path Encoding, we specify the 16 most significant
bits (using the table in section 4.4.1 and use only bits 111 through
80 of each alternate network's addresses to indicate the alternate
paths.
Different interfaces and/or interface addresses on this network MAY
utilize different primary and/or alternate networks.
4.2.1 Single Alternate Path Requirements
For interface addresses using Single Alternate Path Encoding, bits
127 through 80 of the alternate network's addresses MUST be assigned
to bits 63 through 16 of the interface address.
4.2.2 Dual Alternate Path Requirements
For interface addresses using Dual Alternate Path Encoding, bits 111
through 80 of the first alternate network's addresses MUST be
assigned to bits 71 through 40 of the interface address.
Loch Expires May 20, 2005 [Page 5]
Internet-Draft IPv6 Alternate Path Encoding November 2004
AND
bits 111 through 80 of the second alternate network's addresses MUST
be assigned to bits 39 through 8 of the interface address.
4.3 Path Preference Bits
To indicate preference for the primary path, alternate path(s) or
neither, four bits are set in the interface address to indicate
preference. The values were specifically chosen to minimize routing
problems when non-APE addresses pass through APE enabled routers.
4.3.1 Path Preference Bits Requirement
For interface addresses using Single Alternate Path Encoding,
interface address bits 15 through 12 MUST be set according to the
table below.
For interface addresses using Dual Alternate path encoding, address
bits 7 through 4 MUST be set according to the following table:
Hex Value Path Preference
0xf Must not use any alternate paths
0xe No path preference
0xd through 0x7 Reserved
0x6 Must not use second alternate path
0x5 Must not use first alternate path
0x4 Must not use primary path if a usable alternate
path is available.
0x3 Prefer second alternate path
0x2 Prefer first alternate path
0x1 Prefer primary path
0x0 Must not use any alternate paths
4.4 Alternate Path Encoding Indicator
To enable routers to detect packets with alternate path information,
a special value is assigned to interface address bits 79 through 76.
The values were specifically chosen to minimize routing problems when
non-APE packets pass through APE enabled routers.
4.4.1 Alternate Path Encoding Indicator Requirement
For interface addresses using Alternate Path Encoding, interface
address bits 79 through 76 MUST be set according to the following
table:
Loch Expires May 20, 2005 [Page 6]
Internet-Draft IPv6 Alternate Path Encoding November 2004
Alternate Path Indicator
Hex Value Alternate Path Mode
0xf No alternate path encoding
0xe Single alternate path mode
0xd Dual alternate path mode using TLA 2001::/16
0xc through 0x1 Reserved
0x0 No alternate path encoding
For interface addresses not using Alternate Path Encoding, it is
strongly RECOMMENDED that address bits 79 through 76 be set to 0x0 or
0xf.
Loch Expires May 20, 2005 [Page 7]
Internet-Draft IPv6 Alternate Path Encoding November 2004
4.5 Single Alternate Path Example
An interface is on a local network connected to:
2001:0db8:5100::/48 (primary)
and
2001:0db8:5200::/48 (alternate)
Without Alternate Path Encoding it was assigned
a global unicast address of:
2001:0db8:5100:0001:0000:0000:0000:0001
That same interface with Single Alternate Path Encoding,
and no path preference would be set to:
2001:0db8:5100:e001:2001:0db8:5200:e001
|__| |_______| ||_| |____________| ||_|
| | | | | | |
FP/TLA-+ | | | | | |
| | | | | |
SubTLA/NLA----+ | | | | |
| | | | |
Alternate Path------+ | | | |
Indicator | | | |
| | | |
SLA-------------------+ | | |
| | |
Alternate Path Information------+ | |
| |
Path Preference-------------------------+ |
|
Subnet-unique Interface ID----------------+
Alternatively, if path preference were changed to prefer
the alternate path, the interface would be set to:
2001:0db8:5100:e001:2001:0db8:5200:2001
|
Path Preference was changed-------------+
to prefer the alternate path
Loch Expires May 20, 2005 [Page 8]
Internet-Draft IPv6 Alternate Path Encoding November 2004
4.6 Dual Alternate Path Example
An interface on a local network connected to:
2001:0db8:5100::/48 (primary)
2001:0db8:5200::/48 (alternate #1)
2001:0db8:5300::/48 (alternate #2)
Without Alternate Path Encoding it was assigned
a global unicast address of:
2001:0db8:5100:0100:0000:0000:0000:0001
That same interface with Dual Alternate Path Encoding,
and no path preference would be set to:
2001:0db8:5100:d10d:b852:000d:b853:00e1
|__| |_______| |||________||________|||
| | || | | ||
FP/TLA-+ | || | | ||
| || | | ||
SubTLA/NLA----+ || | | ||
|| | | ||
Dual Alternate------+| | | ||
Path Indicator | | | ||
(TLA=2001::/16) | | | ||
| | | ||
SLA------------------+ | | ||
| | ||
First Alternate Path------+ | ||
Information | ||
| ||
Second Alternate Path Information----+ ||
||
Path Preference---------------------------+|
|
Subnet-unique Interface ID-----------------+
5. Routing
To make use of Alternate Path Encoding, routers will make routing
decisions based upon decoded Alternate Path information. The more
routers that are configured to do this the more effective APE will
be. APE routing requirements are designed with the following goals:
o Protect non-APE packets from misrouting.
Loch Expires May 20, 2005 [Page 9]
Internet-Draft IPv6 Alternate Path Encoding November 2004
o To prevent routing loops
o Allow router administrators control over which APE paths are used
(if any).
o To allow sites control of their path preference once the above
conditions are met.
Because implementation and use of APE is optional, different routers
may route an APE packet twards different destinations. In some cases
this would result in a routing loop. Two safety provisions are
provided to account for this:
o If a router already has a sufficiently specific route for the
actual destination address, it will route the packet tward the
actual destination address. The bit match requirement is set to
allow for networks to multihome to 2nd tier ISP's (or multiple
POP's of a single ISP) that have been allocated addresses in
blocks of /40 prefixes. This also eliminates the need for a 1st
tier ISP to have routes more specific than /40 in every router to
support APE.
o If a packet's hop limit value is below a certain threshold, it is
routed using the actual destination address with the suspicion
that it has been in a routing loop. A hop limit value is
suggested to make it likely that the packet can still arrive at
the actual destination address.
5.1 General Routing Requirements
If either of the following two conditions are met, a packet MUST NOT
be routed using an Alternate Path Mode:
o If a router has a valid and useable route table entry matching 40
or more most significant bits of a packet's actual destination
address.
o If a packet has a hop limit value lower than the value configured
in the router for this purpose. A default value of 31 is
Recommended.
Otherwise,
A router MAY use bits 79 through 76 of a packet's destination address
to determine according to the table in section 4.4.1 if a packet has
Alternate Path Encoding information. It MAY then use the appropriate
Alternate Path Mode from the table in section 4.4.1 in it's routing
decisions for that packet.
An router MAY use the Alternate Path Preference bits from the actual
destination address when making Alternate Path routing decisions.
Path preference SHALL be interpreted according to the table in
Loch Expires May 20, 2005 [Page 10]
Internet-Draft IPv6 Alternate Path Encoding November 2004
section 4.3.1.
A packet MUST NOT be discarded solely on the basis of an invalid or
unusable route to an alternate destination address, regardless of any
path preference.
5.2 Single Alternate Path Mode
When routing an packet in Single Alternate Path Mode, a router will
create an alternate destination address using the following
procedure:
Bits 127 through 80 of the alternate destination address are set to
bits 79 through 16 of the actual destination address.
Bits 79 through 0 of the alternate destination address are set to
bits 79 through 0 of the actual destination address.
A router MAY then choose the next hop for the packet using either the
actual or alternate destination address as the intended destination.
the packet's destination address MUST NOT be changed as a result of
this procedure. The alternate address is constructed only for making
routing decisions.
5.3 Dual Alternate Path Modes
When routing an packet in a Dual Alternate Path Mode, a router will
create two alternate destination addresses using the following
procedure:
For each alternate address, bits 127 through 112 are set to the TLA
indicated in the table in section 4.4.1 for the appropriate Dual
Alternate Path Mode.
Bits 111 through 80 of the first alternate destination are set to
bits 71 through 40 of the actual destination address.
Bits 111 through 80 of the second alternate destination are set to
bits 39 through 8 of the actual destination address.
For each alternate address, bits 79 through 0 are set to bits 79
through 0 of the actual destination address.
A router MAY then choose the next hop for the packet using any of the
actual or alternate destination addresses as the indended
destination.
Loch Expires May 20, 2005 [Page 11]
Internet-Draft IPv6 Alternate Path Encoding November 2004
the packet's destination address MUST NOT be changed as a result of
this procedure. The alternate addresses are constructed only for
making routing decisions.
6. Security Considerations
A misconfigured Alternate Path Encoded address may cause packets to
be delivered to a hostile network where they could be easially
intercepted or used in a man-in-the-middle attack.
7 References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
Author's Address
Kevin M. Loch
HotNIC LLC
EMail: kloch@hotnic.net
Loch Expires May 20, 2005 [Page 12]
Internet-Draft IPv6 Alternate Path Encoding November 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Loch Expires May 20, 2005 [Page 13]