Individual Submission K. Loch Internet-Draft HotNIC LLC Expires: July 31, 2005 January 27, 2005 IPv6 Multihoming with Alternate Path Encoding draft-loch-multi6-alternate-path-encoding-03.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 July 31, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 Loch Expires July 31, 2005 [Page 1] Internet-Draft IPv6 Alternate Path Encoding January 2005 limited form of anycasting. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problems Addressed . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 4. Alternate Path Encoding . . . . . . . . . . . . . . . . . . . 5 4.1 Alternate Path Encoding Indicator . . . . . . . . . . . . 6 4.1.1 Alternate Path Encoding Indicator Requirement . . . . 6 4.2 Alternate Path Information . . . . . . . . . . . . . . . . 7 4.2.1 Single Alternate Path Requirements . . . . . . . . . . 7 4.2.2 Dual Alternate Path Requirements . . . . . . . . . . . 7 4.3 Path Availablilty Bits . . . . . . . . . . . . . . . . . . 7 4.3.1 Path Availability Bits Requirement . . . . . . . . . . 8 4.4 Interface ID and Site Subnet ID Bits . . . . . . . . . . . 8 4.4.1 Subnet Unique Host Identifier Requirements . . . . . . 9 4.5 Single Alternate Path Example . . . . . . . . . . . . . . 10 4.6 Dual Alternate Path Example . . . . . . . . . . . . . . . 11 5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 General Routing Requirements . . . . . . . . . . . . . . . 12 5.2 Single Alternate Path Mode . . . . . . . . . . . . . . . . 13 5.3 Dual Alternate Path Modes . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Loch Expires July 31, 2005 [Page 2] Internet-Draft IPv6 Alternate Path Encoding January 2005 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. Some address bits are used to record unavailable paths when discovered. While many IPv6 multihoming methods require changes to host software, this method only requires changes to routers. This will make widespread implementation far more practical and likely in the near term than methods that require upgrading host software (provided that router vendors support this feature). Alternate Path encoding affects inbound traffic. It is assumed that outbound trafafic would be directed by a conventional default route and/or a full routing table in a site gateway router. This is possible because only a single global unicast address per interface is requiredu using this method. If the outbound destination address is also APE encoded, this information may also be used by site routers to make outbound routing decisions. 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 enables small and medium sized networks to multihome without adding any routes to the global routing table. Loch Expires July 31, 2005 [Page 3] Internet-Draft IPv6 Alternate Path Encoding January 2005 3.1 Benefits The benefits of Alternate Path Encoding include: o Alternate routing path(s) if link to one network is disrupted, or one network has routing problems. o because only a single global unicast address is needed per interface, traditional site gateway methods (full table feed) may be used to direct outbound traffic. o No additional routes are required in global routing tables. o A globally unique Autonomous System number is not required. A private ASN may be used for bgp sessions used to receive routes for outbound routing decisions. 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 Alternate Path Encoding: 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. 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). This may cause packets to be misrouted or dropped. 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. Loch Expires July 31, 2005 [Page 4] Internet-Draft IPv6 Alternate Path Encoding January 2005 4. Alternate Path Encoding Alternate Path information is encoded in the interface address two different ways depending on wether Single or Dual Alternate Path mode is used. For Single Alternate Path Mode: xxxx:xxxx:xxxx:esss:yyyy:yyyy:yyyy:3hhh |____________| ||_| |____________| ||_| | | | | | | | | | | | | | | | | | | Primary Path--+ | | | | | | | | | | Single Alternate----+ | | | | Path Indicator | | | | | | | | Site Subnet ID--------+ | | | | | | Alternate Path Information------+ | | | | Path Availablity------------------------+ | | Subnet-unique Interface ID----------------+ Note: this assignment method does not affect the prefix length used on this network segment. Loch Expires July 31, 2005 [Page 5] Internet-Draft IPv6 Alternate Path Encoding January 2005 For Dual Alternate Path Mode: xxxx:xxxx:xxxx:dsyy:yyyy:yyzz:zzzz:zz7h |____________| |||________||________||| | || | | || Primary Path--+ || | | || || | | || Dual Alternate------+| | | || Path Indicator | | | || (TLA=2001::/16) | | | || | | | || Site Subnet ID-------+ | | || | | || First Alternate Path------+ | || Information | || | || Second Alternate Path Information----+ || || Path Availabiliy--------------------------+| | Subnet-unique Interface ID-----------------+ Note: this assignment method does not affect the prefix length used on this network segment. 4.1 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. 4.1.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: Loch Expires July 31, 2005 [Page 6] Internet-Draft IPv6 Alternate Path Encoding January 2005 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. 4.2 Alternate Path Information For Single Alternate Path Encoding, we use the first 48 bits of the alternate network's address 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 address 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 address 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 through 47 of the first alternate network's address MUST be assigned to bits 56 through 87 of the interface address. AND bits 16 through 47 of the second alternate network's address MUST be assigned to bits 88 through 119 of the interface address. 4.3 Path Availablilty Bits To indicate which paths are usable, four bits are used in the interface address. The values were specifically chosen to minimize routing problems when non-APE addresses pass through APE enabled Loch Expires July 31, 2005 [Page 7] Internet-Draft IPv6 Alternate Path Encoding January 2005 routers. 4.3.1 Path Availability Bits Requirement For interface addresses using Single Alternate Path Encoding, interface address bits 112 through 115 MUST be set to 0x3. For interface addresses using Dual Alternate path encoding, address bits 120 through 123 MUST be set to 0x7 Other values for Path Availability bits are set only by routers according to the table below: Hex Value Path Availability 0xf - 0x8 Must not use any alternate path 0x7 Primary, first and second alternate paths are available (default for Dual Alternate Path Mode) 0x6 Only first and second alternate paths are available 0x5 Only primary and second alternate paths are available 0x4 Only second alternate path is available 0x3 Primary and first alternate paths are available (default for Single Alternate Path Mode) 0x2 Only first alternate path is available 0x1 Only primary path is available 0x0 Must not use any alternate path 4.4 Interface ID and Site Subnet ID 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. This has no effect on the actual prefix length used for the interface. We are only specifying values are assigned to certain bit positions, regardless of wether they are considered part of the network or interface part of the address. Any prefix length longer than /40 is supported by this method, including the standard prefix length of /64. Loch Expires July 31, 2005 [Page 8] Internet-Draft IPv6 Alternate Path Encoding January 2005 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.4.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. Loch Expires July 31, 2005 [Page 9] Internet-Draft IPv6 Alternate Path Encoding January 2005 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 would be set to: 2001:0db8:5100:e001:2001:0db8:5200:3001 |____________| ||_| |____________| ||_| | | | | | | Primary Path--+ | | | | | | | | | | Alternate Path------+ | | | | Indicator | | | | | | | | Site-unique Subnet ID-+ | | | | | | Alternate Path Information------+ | | | | Path Availablity------------------------+ | | Subnet-unique Interface ID----------------+ Loch Expires July 31, 2005 [Page 10] Internet-Draft IPv6 Alternate Path Encoding January 2005 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 would be set to: 2001:0db8:5100:d10d:b852:000d:b853:0071 |____________| |||________||________||| | || | | || Primary Path--+ || | | || || | | || Dual Alternate------+| | | || Path Indicator | | | || (TLA=2001::/16) | | | || | | | || Site Subnet ID-------+ | | || | | || First Alternate Path------+ | || Information | || | || Second Alternate Path Information----+ || || Path Availabiliy--------------------------+| | Subnet-unique Interface ID-----------------+ Loch Expires July 31, 2005 [Page 11] Internet-Draft IPv6 Alternate Path Encoding January 2005 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 Deliver traffic optimally using all available paths. o Protect non-APE packets from misrouting o To prevent routing loops It is possible that different routers will route an APE packet to different destinations. In some cases this would result in a routing loop. Three 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. This may also lead to better route filtering because ISP's would need to filter /40 and longer announcements to optimize for Alternate Path Encoding. 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. o If a router determines that an alternate path is unavailable, it must mark that path as unavailable by setting the appropriate value for the Path Availability bits in the destination address. The values of the Path Availability bits must be reset to default values when a router has a sufficiently specific route. 5.1 General Routing Requirements A router MAY use bits 48 through 51 of a packet's destination address to determine according to the table in section 4.1.1 if a packet has Alternate Path Encoding information. It MAY then use the appropriate Alternate Path Mode from the table in section 4.1.1 in it's routing decisions for that packet. If either of the following two conditions are met, a packet MUST NOT be routed using an alternate path: Loch Expires July 31, 2005 [Page 12] Internet-Draft IPv6 Alternate Path Encoding January 2005 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. In this case the router also MUST reset the Path Availability bits to the appropriate default value from table in section 4.3.1 but only if the router determines that the packet is using Alternate Path Encoding AND the Alternate Path bits do not indicate "Must not use any alternate path" 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 MUST use the Path Availability 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 unusable route to an alternate destination address. If the Path availability bits indicate "Must not use an alternate path" then the packet MUST be routed using the primary path AND changes MUST NOT be made to the Path Availability bits. A router MUST NOT change the Path Availability bits to indicate that a path is available when they already indicate it is not, regardless of actual path availability. 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, subject to the Path Availability status. If the router does not have a route to the primary and/or alternate destination addresses AND the alternate address is in 2000::/3, it MUST set bits 112 through 115 of the packets destination address to Loch Expires July 31, 2005 [Page 13] Internet-Draft IPv6 Alternate Path Encoding January 2005 indicate the unavailable path(s) according to the table in section 4.3.1. Except for the Path Availability bits, 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, subject to the Path Availability status. If the router does not have a route to the primary and/or alternate destination addresses, it MUST set bits 120 through 123 of the packet's destination address to indicate the unavailable path(s) according to the table in section 4.3.1. Except for the Path Availability bits, 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. 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 Loch Expires July 31, 2005 [Page 14] Internet-Draft IPv6 Alternate Path Encoding January 2005 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 July 31, 2005 [Page 15] Internet-Draft IPv6 Alternate Path Encoding January 2005 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 (2005). 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 July 31, 2005 [Page 16]