[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: ng

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/