Individual Submission K. Loch Internet-Draft HotNIC LLC Expires: May 19, 2005 November 18, 2004 IPv6 Multihoming with Alternate Path Encoding draft-loch-multi6-alternate-path-encoding-00.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 19, 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 anycast. Loch Expires May 19, 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . 7 4.6 Dual Alternate Path Example . . . . . . . . . . . . . . . 7 5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 General Routing Requirements . . . . . . . . . . . . . . . 9 5.2 Single Alternate Path Mode . . . . . . . . . . . . . . . . 9 5.3 Dual Alternate Path Modes . . . . . . . . . . . . . . . . 10 6. Requirements Notation . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Loch Expires May 19, 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 "host" 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). 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 Traffic can be directed between multiple separate sites if desired, similar to anycast. 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. Loch Expires May 19, 2005 [Page 3] Internet-Draft IPv6 Alternate Path Encoding November 2004 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 reult 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 host-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 host 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 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 Loch Expires May 19, 2005 [Page 4] Internet-Draft IPv6 Alternate Path Encoding November 2004 identifier, leaving 72 bits to encode the alternate path information. 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. 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 Loch Expires May 19, 2005 [Page 5] Internet-Draft IPv6 Alternate Path Encoding November 2004 problems when non-APE addresses pass through non-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 non-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: 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 Loch Expires May 19, 2005 [Page 6] Internet-Draft IPv6 Alternate Path Encoding November 2004 For interface addresses not using Alternate Path Encoding, it is strongly RECOMMENDED that address bits 79 through 76 be set to 0x0. 4.5 Single Alternate Path Example An interface is on a local network connected to: 2001:0db8:5001::/48 (primary) and 2001:0db8:5002::/48 (alternate) Without Alternate Path Encoding it was assigned a global unicast address of: 2001:0db8:5001:0001:0000:0000:0000:0001 That same interface with Single Alternate Path Encoding, and no path preference would be set to: 2001:0db8:5001:e001:2001:0db8:5002:e001 |__| |_______| ||_| |____________| ||_| | | | | | | | FP/TLA-+ | | | | | | | | | | | | SubTLA/NLA----+ | | | | | | | | | | Alternate Path------+ | | | | Indicator | | | | | | | | SLA-------------------+ | | | | | | Alternate Path Information------+ | | | | Path Preference-------------------------+ | | Subnet-unique host ID---------------------+ Alternatively, if path preference were changed to prefer the alternate path, the interface would be set to: 2001:0db8:5001:e001:2001:0db8:5002:2001 | Path Preference was changed-------------+ to prefer the alternate path 4.6 Dual Alternate Path Example Loch Expires May 19, 2005 [Page 7] Internet-Draft IPv6 Alternate Path Encoding November 2004 An interface on a local network connected to: 2001:0db8:5001::/48 (primary) 2001:0db8:5002::/48 (alternate #1) 2001:0db8:5003::/48 (alternate #2) Without Alternate Path Encoding it was assigned a global unicast address of: 2001:0db8:5001:0100:0000:0000:0000:0001 That same interface with Dual Alternate Path Encoding, and no path preference would be set to: 2001:0db8:5001:d10d:b850:020d:b850:03e1 |__| |_______| |||________||________||| | | || | | || FP/TLA-+ | || | | || | || | | || SubTLA/NLA----+ || | | || || | | || Dual Alternate------+| | | || Path Indicator | | | || (TLA=2001::/16) | | | || | | | || SLA------------------+ | | || | | || First Alternate Path------+ | || Information | || | || Second Alternate Path Information----+ || || Path Preference---------------------------+| | Subnet-unique host 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. o To prevent routing loops o Allow router administrators control over which APE paths are used (if any). Loch Expires May 19, 2005 [Page 8] Internet-Draft IPv6 Alternate Path Encoding November 2004 o To allow sites control of their path preference once the above conditions are met. 5.1 General Routing Requirements If a router has a valid and useable route table entry matching 48 or more most significant bits of a packet's destination address, it MUST NOT use any Alternate Path Mode for routing decisions. This is essential to prevent unnecessary routing loops. OTHERWISE An 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 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 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. Loch Expires May 19, 2005 [Page 9] Internet-Draft IPv6 Alternate Path Encoding November 2004 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 destination. 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. Requirements Notation 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]. 7. 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. 8 References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Loch Expires May 19, 2005 [Page 10] Internet-Draft IPv6 Alternate Path Encoding November 2004 Author's Address Kevin M. Loch HotNIC LLC EMail: kloch@hotnic.net Loch Expires May 19, 2005 [Page 11] 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 19, 2005 [Page 12]