Individual Submission K. Loch Internet-Draft HotNIC LLC Expires: May 22, 2005 November 21, 2004 IPv6 Multihoming with Alternate Path Encoding draft-loch-multi6-alternate-path-encoding-02.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 22, 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 22, 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 . . . . 7 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 22, 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. 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, o No additional routes are required in global routing tables. Loch Expires May 22, 2005 [Page 3] Internet-Draft IPv6 Alternate Path Encoding November 2004 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 of APE: o A maximum of two alternate networks (for a total of three networks) can be encoded on a single unicast address. Note that this is a per address limitation not a per site limitation. 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. o Dual Alternate Path Mode leaves few bits for site subnet and subnet unique interface identifiers. Allocation sizes may have to be expanded for sites that use this mode. This should not be an issue for Single Alternate Path Mode. 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 Loch Expires May 22, 2005 [Page 4] Internet-Draft IPv6 Alternate Path Encoding November 2004 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. 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 encoding alternate 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 70 and 71, 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 116 through 127 of the interface address. For interfaces using Dual Alternate Path Encoding, a 4 bit subnet-unique interface identifier MUST be assigned to bits 124 through 127 of the interface address. 4.2 Alternate Path Information For Single Alternate Path Encoding, we use the first 48 bits of the alternate network's addresses to indicate the alternate path. For Dual Alternate Path Encoding, we specify the first 16 bits (using the table in section 4.4.1) and use only bits 16 through 47 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 0 through 47 of the alternate network's addresses MUST be assigned to bits 64 through 111 of the interface address. 4.2.2 Dual Alternate Path Requirements For interface addresses using Dual Alternate Path Encoding, bits 16 Loch Expires May 22, 2005 [Page 5] Internet-Draft IPv6 Alternate Path Encoding November 2004 through 47 of the first alternate network's addresses MUST be assigned to bits 56 through 87 of the interface address. AND bits 16 through 47 of the second alternate network's addresses MUST be assigned to bits 88 through 119 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 112 through 115 MUST be set according to the table below. For interface addresses using Dual Alternate path encoding, address bits 120 through 123 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 48 through 51. The values were specifically chosen to minimize routing problems when non-APE packets pass through APE enabled routers. Loch Expires May 22, 2005 [Page 6] Internet-Draft IPv6 Alternate Path Encoding November 2004 4.4.1 Alternate Path Encoding Indicator Requirement For interface addresses using Alternate Path Encoding, interface address bits 48 through 51 MUST be set according to the following table: 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 48 through 51 be set to 0x0 or 0xf. Loch Expires May 22, 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 22, 2005 [Page 8] Internet-Draft IPv6 Alternate Path Encoding November 2004 4.6 Dual Alternate Path Example An interface is 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 22, 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. It is possible that different routers will route an APE packet to 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 primary destination address, it will use that route. 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 or assigned 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 primary 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 primary 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 the first 40 or more bits of a packet's 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 48 through 51 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. A router SHOULD use the Alternate Path Preference bits from the packet's destination address when making Alternate Path routing decisions. Path preference SHALL be interpreted according to the table in section 4.3.1. A packet MUST NOT be discarded solely on the basis of an invalid or Loch Expires May 22, 2005 [Page 10] Internet-Draft IPv6 Alternate Path Encoding November 2004 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 0 through 47 of the alternate destination address are set to bits 48 through 111 of the packet's destination address. Bits 48 through 127 of the alternate destination address are set to bits 48 through 127 of the packet's destination address. A router MAY then choose the next hop for the packet using either the primary 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 used 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 0 through 15 are set to the TLA indicated in the table in section 4.4.1 for the appropriate Dual Alternate Path Mode. Bits 16 through 47 of the first alternate destination are set to bits 56 through 87 of the packet's destination address. Bits 16 through 47 of the second alternate destination are set to bits 88 through 119 of the packet's destination address. For each alternate address, bits 48 through 127 are set to bits 48 through 127 of the packet's destination address. A router MAY then choose the next hop for the packet using any of the primary or alternate destination addresses as the intended destination. the packet's destination address MUST NOT be changed as a result of this procedure. The alternate addresses are used only for making routing decisions. Loch Expires May 22, 2005 [Page 11] Internet-Draft IPv6 Alternate Path Encoding November 2004 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 22, 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 22, 2005 [Page 13]