[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                         M. Bagnulo
Internet-Draft                                        A. Garcia-Martinez
Expires: April 29, 2003                                             UC3M
                                                        October 29, 2002


             Extension Header for Site-Multi-homing support
                    draft-bagnulo-multi6-mhexthdr-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 April 29, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This note describes an IPv6 multi-homing solution that achieves
   equivalent fault tolerance benefits to those provided by current IPv4
   multi-homing solution while preserving the route aggregation
   capabilities of the Provider-based Aggregation scheme.  The solution
   lies on the inclusion, in every packet flowing to a multi-homed site,
   of an extension header containing multiple alternative route
   information to the destination, so that if the original destination
   address becomes unreachable, alternative route is used for reaching
   the destination.





Bagnulo & Garcia-Martinez    Expires April 29, 2003             [Page 1]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


1. Introduction

   This note describes an IPv6 multi-homing solution that achieves
   equivalent fault tolerance benefits to those provided by current IPv4
   multi-homing solution while preserving the route aggregation
   capabilities of the Provider-based Aggregation scheme.  The solution
   lies on the inclusion, in every packet flowing to a multi-homed site,
   of an extension header containing multiple alternative route
   information to the destination, so that if the original destination
   address becomes unreachable, alternative route is used for reaching
   the destination.  Additionally, a Destination option is defined (the
   Alternative Prefix Destination Option) to convey multiple alternative
   prefix information from a multi-homed host to the other end of the
   communication.





































Bagnulo & Garcia-Martinez    Expires April 29, 2003             [Page 2]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


2. Solution components

2.1 Alternative Prefix Destination option

   The following destination option is defined:


                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      | Option Type   |Opt Data Len   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Reserved                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Alternative Prefix #1 (64 bits)               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                               .                               .
      .                               .                               .
      .                               .                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Alternative Prefix #n  (64 bits)              |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type value is 000xxxxx (in bits): The two highest order bits
   set to O, so that if the option is not recognized, the option is
   ignored and the packet is processed [1].  This allows that hosts not
   implementing this solution to be capable of communication with hosts
   which do implement the solution.  Note that multi-homing benefits are
   lost in this particular communication.  The third bit is set to 0,
   since the option data does not change in the route [1].  Remaining
   bits are set to xxxxx (TBD by IANA)

   Option Data Length value is 4n+2, since the option contains n
   Alternative Prefixes, and each one has 4 octets and 2 octets to
   preserve alignment.

   Alternative Prefix field contains alternative Prefixes assigned to
   the source interface other than the one included in the Source
   Address field of the IPv6 header [1].

   The intended use of the above destination option is the communication
   of multiple alternative routes to the multi-homed site, from a multi-
   homed source node to a destination node.

2.2 Alternative Prefix Extension Header

   A new Extension Header is defined with the following format:




Bagnulo & Garcia-Martinez    Expires April 29, 2003             [Page 3]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Next Header  |  Hdr Ext Len  |     Pleft     |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Reserved                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Alternative  Prefix #1 (64 bits)           |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                               .                               .
       .                               .                               .
       .                               .                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Alternative Prefix #n (64 bits)            |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next header value: 8-bit selector.  Identifies the type of header
   immediately following the Alternative Prefix Extension Header.

   Hdr Ext Len: 8-bit unsigned integer.  Length of the Alternative
   Prefix Extension Header in 8-octet units, not including the first 8
   octets.

   Pleft: 8-bit unsigned integer.  Number of Alternative Prefixes left,
   i.e., number of Prefixes that have not been used for reaching the
   final destination.

   Alternative Prefix field contains alternative prefixes assigned to
   the destination interface other than the one included in the
   Destination Address field of the IPv6 header [1].

   The Alternative Prefix Extension Header is identified by a Next
   Header value of xx (TBD by IANA) in the immediately preceding header.

   The position of the new extension header relative to the ones already
   defined is after the routing header and before the fragment header,
   since it is to be processed by intermediate routers when no route to
   destination is found.

   The intended usage of the above Extension header is the following:
   when a router receives a packet and it has no route to the address
   contained in the destination field, the router must look for an
   Alternative Prefix Extension Header.  If such header is included in
   the packet, and the value of Pleft is different than zero, then the
   router must swap the 64 most significant bits of the Destination
   address with the ones located in the position number (Ext Hdr Len
   minus Pleft) of the extension header.  Then the router must update
   the Pleft by Pleft minus one.  Finally, the router must try to



Bagnulo & Garcia-Martinez    Expires April 29, 2003             [Page 4]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


   forward the packet to the new destination address.  If there is no
   Alternative Prefix Extension Header or the Pleft value is zero, then
   the packet must be discarded and an ICMP error must be sent to the
   source.



   If (No Route to Destination) AND (Exists Alternative Prefix Extension Header)
   then
    {
      if Pleft = 0 {
          Discard packet
                     }
      else {
         if Pleft is greater than Hdr Ext Len
            {
            send an ICMP Parameter Problem, Code 0, message to the Source
            Address, pointing to the Pleft field, and discard the
            packet
            }
         else {
            decrement Pleft by 1;
            compute i, the index of the next Prefix to be used by subtracting Pleft from Hdr Ext Len
            and swap the prefix of the IPv6 Destination Address and the Alternative Prefix #i
            resubmit the packet to the IPv6 module for transmission
            to the new destination
              }
          }
     }






















Bagnulo & Garcia-Martinez    Expires April 29, 2003             [Page 5]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


3. Solution description

3.1 Scenario Description


           +-----+
           |Host1|
           |     |
           +-----+
              |
             ...
              |
       _______|_______________________________________
      |                                              |
      |                                              |
      |                                              |
      |   +------------+             +------------+  |
      |   |  PA::/nA   |             |   PB::/nB  |  |
      |   |   ISPA     |   DFZ       |    ISPB    |  |
      |   +------------+             +------------+  |
      |       |                             |        |
      |_______|_____________________________|________|
              |                             |
           |  |    ^                     |  |  ^
           |  |    |PA:PC::/nC           |link2|
      0::/0| link1 |                0::/0|  |  |PB:PD::/nD
           V  |    |                     V  |  |
       +---------------+          +---------------+
       |     ISPC      |          |     ISPD      |
       |   PA:PC::/nC  |          |   PB:PD::/nD  |
       +---------------+          +---------------+
              |                            |
              |                            |
              |                            |
            link3                        link4
            __|____________________________|___
           |   RA                         RB   |
           |                                   |
           |       Multi-homed end-site        |
           |PA:PC:PS1::/n1             Host2   |
           |PB:PD:PS2::/n2                     |
           |___________________________________|


   The considered scenario is as follows:

   A Multi-homed end-site obtains global connectivity through two ISPs
   i.e.  ISPC and ISPD.  These ISPs do not belong to the Default free



Bagnulo & Garcia-Martinez    Expires April 29, 2003             [Page 6]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


   zone and they buy transit from ISPA and ISPB respectively.  ISPA and
   ISPB do belong to the Default Free Zone i.e.  at least one of their
   routers have full routing information.  In the figure above, some of
   the routing information exchanged between peers is included.  Since
   the end-site is multi-homed, it has obtained two address ranges: one
   delegated from ISPC address range i.e.  PA:PC:PS1::/n1 and the other
   one from ISPD address space i.e.  PB:PD:PS2::/n2.  ISPC and ISPD have
   obtained a range of the address space from the address range assigned
   to their respective providers, i.e.  ISPA and ISPB.  So ISPA has
   delegated the range PA:PC::/nC to ISPC and ISPB has delegated the
   range PB:PD::/nD to ISPD.

3.2 Normal operation.

   Let´s now consider the possible communication between Host1 (a given
   host in the Internet) and Host2 (a host belonging to the multi-homed
   end-site considered)

   Since Host2 belongs to the Site, it has at least two addresses i.e.
   PA:PC:PS1:PL1:IIdHost2 and PB:PD:PS2:PL2:IIdHost2, which will be
   included in the DNS (if we suppose that Host2 wants to be reached
   through the two providers).  It should be noted that the solution
   requires that all addresses of the same interface used in the
   solution share the Interface identifier part

   Communication initiated by Host2.

   Host2 sends a packet to Host1 address and it includes a Alternative
   Prefix Destination option with all the different prefixes it is
   willing to use to receive replies to this packet.  When Host1
   replies, it addresses the packet to the source address included in
   the first packet and it also includes in the reply packet an
   Alternative Prefix Extension Header with the prefixes included in the
   Alternative Prefix Destination option of the initial packet.  When
   Host2 receives the reply, it verifies that the destination address
   and all the prefixes included in the Alternative Prefix Extension
   Header are assigned to its interfaces.  If at least one of the
   derived addresses is not assigned to any of the interfaces, the
   packet is discarded (See Security Considerations Section).  Even if
   different packets of a given communication may have different
   destination addresses, Host2 must present them to its upper layer as
   if they had the same destination address.  This can be done since it
   is possible to identify the original destination address used by
   Host1 in the following way: If the Ext Hdr Len value in the
   Alternative Prefix Extension Header is equal to the value of the
   Pleft field, then the original Destination address is the one
   included in the Destination Address field of the IPv6 header.  If the
   Ext Hdr Len value in the Alternative Prefix Extension Header is



Bagnulo & Garcia-Martinez    Expires April 29, 2003             [Page 7]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


   greater than the value of the Pleft field, then the original
   Destination address can be reconstructed by replacing the prefix of
   the address included in the destination address field of the IPv6
   header by the first prefix included in the Extension header.  Then
   the packet exchange will continue as above.

   Communication initiated by Host1:

   Host1 performs an A-type query to the DNS and it obtains two
   addresses i.e.  PA:PC:PS1:PL1:IIdHost2 and PB:PD:PS2:PL2:IIdHost2.

   At this point Host1 can make two different uses of the obtained
   information:

   First option: Host1 uses one of the obtained addresses as the
   destination address and it includes the other address in an
   Alternative Prefix Extension Header.  This option would provide the
   same treatment for all the packets sent by Host1 and in particular it
   would provide fault tolerance for this packet.  However, this option
   would imply some changes in the way applications manage multiple
   addresses obtained from a DNS query.

   Second option: The first packet is sent using available fault
   tolerance capabilities when multiple addresses are available i.e.
   Host1 sends a first packet with one of the obtained addresses and if
   no reply is obtained it retries with an alternative address.  When
   finally a reply is received, an Alternative Prefix Destination Option
   is included in it, so that alternative addresses are learned, as in
   the previous case.

   Eventually, in either case, packets flowing from Host1 to Host2 will
   carry the Alternative Prefix Extension Header, and communication will
   continue as detailed above.

3.3 Fault Tolerance Support

   We will next study fault tolerance performance of the solution.
   Let´s suppose that Host1 is sending packets to Host2 address
   PA:PC:PS1:PL1:IIdHost2 and Link1 fails.  In this case, when next
   packets arrive to ISPA, there will be no route to the destination, so
   the ISPA router with no route to destination in its routing tables
   will look for an Alternative Prefix Extension Header in the packet.
   If this header is found, it will be processed and the prefix of the
   destination address will be replaced with the one found in the
   extension header, and the packet will follow the alternative route
   towards its destination.  Some may argue that Alternative Prefix
   Extension Header processing imposes an unacceptable load in routers,
   specially in Core Routers.  Another issue that could be raised, is



Bagnulo & Garcia-Martinez    Expires April 29, 2003             [Page 8]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


   the need for upgrading all the routers of the ISP in order to be able
   to process the newly defined Extension Header.  A workaround for this
   issues can be found by noting that the extension header processing
   can be performed by specific upgraded routers connected to the ISP
   network which would work in the following way: These upgraded routers
   announce a  default route (in our example, the upgraded router is
   connected to the ISPA network and it announces the a route to 0/0).
   Then if link1 is working properly, longest prefix match rule will
   make packets flow through link1.  If link1 is down, packets will be
   forwarded to the upgraded router, that will process the Alternative
   Prefix Extension Header, swapping prefix information.  Once this is
   done, it will forward the packet to the ISPA network, and then to the
   alternative route.  A slightly different approach is needed to
   provide a sink route for packets with unreachable destination address
   when link3 fails.  Since ISPC obtains a default route from its
   provider ISPA, it is not possible to announce a default route to sink
   packets with unreachable destination, as in the previous case where
   the ISP (ISPA) belongs to the default free zone.  In this case, the
   upgraded routers announce a route to the address range allocated to
   the ISP (in our example, the upgraded router is connected to the ISPC
   network and it announces the a route to PA:PC::/nC).  Then if link3
   is working properly, the longest prefix match rule will make packets
   flow through link3.  If link3 is down, packets will be forwarded to
   the upgraded router, who will process the Alternative Prefix
   Extension Header, swapping prefix information.  Once this is done, it
   will forward the packet to the ISPC network, and then to the
   alternative route.
























Bagnulo & Garcia-Martinez    Expires April 29, 2003             [Page 9]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


4. Security Considerations.

   The extension header and the destination option defined above may
   seem to introduce new security risks, since they seem to enable the
   inclusion of spoofed alternative address.  This would allow different
   type of attacks such as communication hijacking.  However, this
   situation can detected by the host belonging to the multi-homed site,
   since if any of the addresses included in the Alternative Prefix
   Extension Header does not correspond to a configured one, the packet
   will be discarded.  This makes us to conclude that packets carrying
   the newly defined option or header are not more susceptible to
   attacks than regular unicast packets.  It must be noted that both
   types of packets are susceptible to man in the middle attacks, but
   the goal of this solution is not improving security features but
   avoiding the introduction of new security risks.

   IPSec support: Alternative Prefix Destination option does not change
   in route so interaction with IPSec is straightforward.  Alternative
   Prefix Extension Header can be modified en-route, as well as the
   destination address of the IPv6 header during extension header
   processing.  However, original IPv6 header and extension header can
   be reconstructed at the destination with the information included in
   the packet, so this solution is compatible with IPSec.




























Bagnulo & Garcia-Martinez    Expires April 29, 2003            [Page 10]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


5. Acknowledgements

   We would like to thank Ignacio Soto, Juan Francisco Rodriguez
   Hervella, Iljitsch van Beijnum and Michael Py for their reviews and
   comments.














































Bagnulo & Garcia-Martinez    Expires April 29, 2003            [Page 11]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


References

   [1]  Hinden, R. and S. Deering, "Internet Protocol, Version 6 (IPv6)
        Specification", December 1998.

   [2]  Hinden, R. and S. Deering, "IP version 6 Addressing
        Architecture", July 1998.


Authors' Addresses

   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN

   Phone: 34 91 6249500
   EMail: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es/marcelo


   Alberto Garcia-Martinez
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN

   Phone: 34 91 6249500
   EMail: alberto@it.uc3m.es
   URI:   http://www.it.uc3m.es/alberto




















Bagnulo & Garcia-Martinez    Expires April 29, 2003            [Page 12]


Internet-Draft    Extension Header for Site-Multi-homing support        October 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Bagnulo & Garcia-Martinez    Expires April 29, 2003            [Page 13]