Network Working Group                                         C. Huitema
Internet-Draft                                                 R. Draves
Expires: April 4, 2006                                         Microsoft
                                                              M. Bagnulo
                                                                    UC3M
                                                            October 2005


       Ingress filtering compatibility for IPv6 multihomed sites
                draft-huitema-shim6-ingress-filtering-00

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 4, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The note presents a set of mechanisms to provide ingress filtering
   compatibility for legacy hosts in IPv6 multihomed sites.







Huitema, et al.           Expires April 4, 2006                 [Page 1]


Internet-Draft      Ingress filtering and multihoming       October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Reference topology . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The problem: Ingress filtering incompatibility . . . . . . . .  5
   4.  Goals and non goals of the presented solution  . . . . . . . .  6
     4.1.  Goal . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Non-goals  . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Proposed solution  . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Relaxing the ingress filtering . . . . . . . . . . . . . .  7
     5.2.  Source Address Dependent (SAD) routing . . . . . . . . . .  8
       5.2.1.  Single site exit router  . . . . . . . . . . . . . . .  8
       5.2.2.  DMZ  . . . . . . . . . . . . . . . . . . . . . . . . .  9
       5.2.3.  General case . . . . . . . . . . . . . . . . . . . . . 10
   6.  Appendix A: Host based optimization  . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17































Huitema, et al.           Expires April 4, 2006                 [Page 2]


Internet-Draft      Ingress filtering and multihoming       October 2005


1.  Introduction

   A way to solve the issue of site multihoming is to have a separate
   site prefix for each connection of the site, and to derive as many
   addresses for each hosts.  This approach to multi-homing has the
   advantage of minimal impact on the inter-domain routing fabric, since
   each site prefix can be aggregated within the larger prefix of a
   specific provider; however, it opens a number of issues, that have to
   be addressed in order to provide a multihoming solution compatible
   with such addressing scheme.

   In this memo we will present a set of mechanisms to deal with the
   problem created by the interaction between ingress filtering [3] and
   legacy hosts in multihomed sites.

   The remaining of this memo is structured as follows: we will first
   present the reference topology and then the problem created by the
   interaction of ingress filtering and multihoming.  Then, we will
   state the goals and non goals of the mechanisms presented in this
   memo.  Next the proposed mechanisms are described.  The Appendix A
   include a possible optimization for the case that the host within the
   multihomed site involved in the communication has special multihoming
   support.




























Huitema, et al.           Expires April 4, 2006                 [Page 3]


Internet-Draft      Ingress filtering and multihoming       October 2005


2.  Reference topology

   In the following discussion, we will use this reference topology:


             /-- ( A ) ---(      ) --- ( C ) --\
   X (site X)             ( IPv6 )              (Site Y) Y
             \-- ( B ) ---(      ) --- ( D ) --/


   The topology features two hosts, X and Y, whose respective sites are
   both multi-homed.  Host X has two global IPv6 addresses, which we
   will note "A:X" and "B:X", formed by combining the prefixes allocated
   by ISP A and B to "site X" with the host identifier of X. Similarly,
   Y has two addresses "C:Y" and "D:Y".

   We assume that X, when it starts engaging communication with Y, has
   learned the addresses C:Y and D:Y, for example because they were
   published in the DNS.  We assume that Y, when it receives packets
   from X, has only access to information contained in the packet coming
   from X, e.g. the source address; we do not assume that Y can retrieve
   by external means the set of addresses associated to X.





























Huitema, et al.           Expires April 4, 2006                 [Page 4]


Internet-Draft      Ingress filtering and multihoming       October 2005


3.  The problem: Ingress filtering incompatibility

   Ingress filtering refers to the verification of the source address of
   the IP packets at the periphery of the Internet, typically at the
   link between a customer and an ISP.  This process, which is described
   in [3] is intended to thwart a class of denial of service attacks in
   which attackers hide their identity by using a "spoofed" source
   address.

   A special complication appears when the ISPs who serve the multihomed
   site perform ingress filtering.  In the above configuration, X is
   served by ISP A and B, and thus can be reached by the addresses A:X
   and B:X. In addition Y is served by ISP C and D, and thus can be
   reached by the addresses C:Y and D:Y. To communicate with Y, X will
   choose the destination address that appears to be easier to reach,
   for example D:Y; then, it will choose the source address that
   provides the most efficient reverse path, say A:X.

   Suppose now that the ISP connections at Site X are managed by two
   different site exit routers, RXA and RXB, and that there is a similar
   configuration at Site Y, with routers RYC and RYD.



                /-- ( A ) ---(      ) --- ( C ) --\
              (RXA)          (      )            (RYC)
      X (site X)             ( IPv6 )              (Site Y) Y
              (RXB)          (      )            (RYD)
                \-- ( B ) ---(      ) --- ( D ) --/


   Within Site X, the interior routing will decide which of RXA or RXB
   is the preferred exit router for the destination "D:Y"; similarly,
   within Site Y, the interior routing will decide which of RYC or RYD
   is the preferred exit for destination A:X. If the chosen exit router
   at Site X is RXA, the packet will flow freely to RYD; If the chosen
   exit router at Site Y is RYD, the response will also flow freely.
   However, if the exit routers are RXB or RYC, and if the ISPs perform
   ingress filtering, we have a problem: ISP B sees a packet coming from
   RXB, whose source address does not match the prefix assigned by B to
   X; ISP C, similarly, sees a packet whose source address does not
   match the prefix assigned by that ISP to Y. If either of these ISPs
   decides to drop the packet, the communication will be broken.
   Similar problems can also occur in communications between a host
   within a multihomed site and a host within a single-homed site.






Huitema, et al.           Expires April 4, 2006                 [Page 5]


Internet-Draft      Ingress filtering and multihoming       October 2005


4.  Goals and non goals of the presented solution

4.1.  Goal

   The goal of the proposed solution is to provide ingress filtering
   compatibility for legacy hosts in multihomed environments, as
   described in RFC 3582 [2] .

   "The solution should not destroy IPv6 connectivity for a legacy host
   implementing RFC 3513 [4] , RFC 2460 [1] , RFC 3493 [5], and other
   basic IPv6 specifications current in April 2003.  That is to say, if
   a host can work in a single-homed site, it should still be able to
   work in a multihomed site, even if it cannot benefit from site-
   multihoming.

   It would be compatible with this goal for such a host to lose
   connectivity if a site lost connectivity to one transit provider,
   despite the fact that other transit provider connections were still
   operational."[sic]

   So, the goal of the presented solution is to enable a communication
   of two legacy hosts when at least one of them is in multihomed site,
   as long as no outage has occurred in the connectivity.

4.2.  Non-goals

   - It is not a goal of the presented solution to provide a complete
   multihoming solution.  In particular, the presented solution does not
   provide fault tolerance capabilities (it does not preserve
   established communication through outages nor it enable hosts to
   initiate communications after an outage).  So, the presented solution
   is a single component of a multihoming solution.



















Huitema, et al.           Expires April 4, 2006                 [Page 6]


Internet-Draft      Ingress filtering and multihoming       October 2005


5.  Proposed solution

   In order to support legacy hosts, the addresses included in packets
   must be honored i.e. cannot be changed after that the host that is
   initiating the communication has selected them.  So, there are two
   possible approaches to provide ingress filtering compatibility: to
   relax the ingress filtering or to perform some form of source address
   dependent routing.  Both mechanisms will be presented next.

5.1.  Relaxing the ingress filtering

   An obvious way to avoid failures due to ingress filtering is to
   simply make sure that all the addresses used by the hosts of a given
   site will be considered acceptable by each of the site's providers.
   In our site X example, that would mean that provider A would accept
   addresses of the form "B:X" as valid, and that provider B will in
   turn accept addresses of the form "A:X" as valid.

   One way to achieve this is simply to ask the service provider to turn
   off source address checks on the site connection.  This requires a
   substantial amount of trust between the provider and the site, as
   source address checks are in effect delegated to the site routers.
   One possible way to achieve this trust is to make sure that the site
   routers, or possibly the site firewalls, meet a quality level
   specified by the provider.

   Another way to achieve this relaxed level of checking is to check
   source addresses against a list of "authorized prefixes" for the site
   connection, rather than simply the single prefix delegated by the
   provider.  This solution requires that the site communicates the
   authorized prefixes to the provider, either through a management
   interface or through a routing protocol.  This is obviously more
   complex than simply lifting the controls, and in fact ends up with a
   very similar requirement of trust: the provider has to be believe
   that the site will transmit the right prefixes.

   In conclusion, relaxing the source address checks requires some form
   of explicit trust between the site and its providers.  There is no
   doubt that this level of trust will exist in many cases; there is
   also no doubt that there will be many cases in which the provider is
   unwilling to grant this trust, particularly in the case of small
   sites, such as for example home networks dual-homes to a DSL provider
   and a cable network provider.  So, this solution is a perfectly
   reasonable solution for large sites, i.e. the sites that benefit of
   IPv4 multihoming today: it should not be more complex to convince a
   provider to relax address checks for a particular customer tomorrow,
   than to convince today a similar provider to advertise in its routing
   table the global IPv4 address of the site.  If we choose this



Huitema, et al.           Expires April 4, 2006                 [Page 7]


Internet-Draft      Ingress filtering and multihoming       October 2005


   solution, we should choose its simplest implementation, i.e. one in
   which the provider completely delegates source address checks to the
   site's router or firewalls.  This is however not a general solution,
   since we cannot expect all sites to convince every provider to relax
   their checks.

5.2.  Source Address Dependent (SAD) routing

   In order to provide ingress filtering compatibility it is possible to
   perform some kind of Source Address Dependent (SAD) routing within
   the site, so that the site exit is effectively a function of the
   source address in the packet.  It should be noted that SAD routing
   does not have to be supported by all the routers of the multihomed
   site, but its support is only required to a connected domain that
   includes all the site exit routers as in the next figure:



                 Multiple site exits
                 |     |     |     |
            -----+-----+-----+-----+-----
           (                             )
           (      SAD routing domain     )
           (                             )
            ----+----+----+----+----+----
           (                             )
           (   Generic routing domain    )
           (                             )
            -----------------------------

   In this schema, all site exit routers are connected to a SAD routing
   domain.  Packets initiated in the generic routing domain and bound to
   an "out of site" address are passed to the nearest access point to
   the SAD routing domain, using classic "hot potato" routing.  The
   routers in the SAD routing domain maintain as many parallel routing
   tables as there are valid source prefixes, and would choose a route
   that is a function of both the source and the destination address;
   the packets exit the site through the "right" router.  There are
   multiple possible implementations of this general concept, depending
   on the site topology and the amount of routers involved.  We will
   next present different scenarios and how SAD routing can be adopted
   in each of them.

5.2.1.  Single site exit router

   The simplest implementation is to have only one exit router for the
   site; in this case, the SAD routing domain is reduced to the exit
   router itself.  This exit router chooses the exit link on the basis



Huitema, et al.           Expires April 4, 2006                 [Page 8]


Internet-Draft      Ingress filtering and multihoming       October 2005


   of the source address in the packet.  Many of the commercial routers
   already support this functionality so the solution in this cases
   could be easily adopted.

5.2.2.  DMZ

   A slightly less complex implementation is to connect all site exit
   routers to the same link, e.g. to what is often referred to as the
   "DMZ" for the site.  This solution requires that all site exit
   routers connected to the DMZ support SAD routing.  In this case, when
   a site exit router receives a packet, it verifies the source address;
   if the source address corresponds to its directly connected ISP, the
   site exit router forwards the packet through the ISP; if the source
   address of the packet does not corresponds to the directly connected
   ISP, the site exit router forwards the packet to the site exit router
   which ISP corresponds to the source address included in the packet.

   In the case that a DMZ is not naturally available in the site, it is
   possible to create a virtual DMZ by using a mesh of tunnels between
   the site exit routers.  In this case, a site exit router that
   receives a packet bound for an out-of-site address would perform a
   source address check before forwarding the packet on one of its
   outgoing interfaces; if the source address check is positive, the
   packet will effectively be sent on the interface; if it is not, the
   packet would be "tunneled" to the appropriate router.

   The main requirement of the DMZ alternative is that site-exit routers
   be able to perform address checks, and that each site exit router be
   able to associate to each valid site prefix the address of a
   corresponding site exit router.  An obvious possibility is to
   configure prefixes and corresponding addresses in each router; it
   would however be preferable to derive these addresses automatically.
   An assumption of the IPv6 architecture is that all prefixes of a site
   will have the same length; it is thus possible to derive a prefix
   from the source address of a "misdirected" packet, by combining this
   prefix with a conventional suffix.  The suffix should be chosen to
   not collide with the subnet numbers used in the site; a null value
   will be inadequate, since it could be matched by any router with
   knowledge of the prefix, not just the site exit router; a value of
   "all ones" could be adequate.

   So, each router managing a site prefix will then inject a "host
   route" announcing the anycast address associated to its locally
   managed prefixes in the interior routing protocol.  Site exit routers
   can then use the standard routing procedures to detect whether the
   anycast address corresponding to the prefix in use is reachable; they
   can automatically reject, rather than forward, packets whose source
   address does not correspond to a reachable anycast address.



Huitema, et al.           Expires April 4, 2006                 [Page 9]


Internet-Draft      Ingress filtering and multihoming       October 2005


   An inconvenience of this set-up is that some packet will follow a
   less than direct path; in the case of a natural DMZ, the additional
   path is probably negligible.  However, in the case of a mesh of
   tunnels, the additional path may be significant, so this is not by
   itself a definitive solution.  A possibility is to use this approach
   to support legacy hosts within the multihomed site and complement the
   solution by adopting the host based mechanism presented in Appendix A
   to allow upgraded host to select the optimal path.  Another
   possibility is to use this approach as a way to "phase in" a full SAD
   routing solution described in the next section.

5.2.3.  General case

   In the most general set up, SAD routing is supported in all the site
   exit routers and all the internal routers required to create a
   connected SAD routing domain.  Each router of the SAD domain would
   maintain as many parallel routing tables as there are valid source
   prefixes, and would choose a route that is a function of both the
   source and the destination address.  Depending on how routes to
   external destinations are configured in routers the amount of work
   required to support SAD routing varies considerably.

5.2.3.1.  Manual configuration

   If routes to external destinations are manually configured, then the
   manual configuration of additional routes corresponding to each of
   the available prefixes is required.  So, if within the multihomed
   site there are n prefixes and each router has m external routes
   configured, then (n-1)m additional routes need to be configured per
   router of the SAD routing domain.

   It should be noted than multiple commercial routers currently support
   manually configured SAD routing, so this solution is already
   available.

   It should also be noted that the usage of manually configured static
   routes does not preclude the fault tolerance capabilities of a
   multihoming solution, since fault tolerance is achieved by changing
   the prefix used for the communication, which is likely to be
   performed by the host itself, and not by the routing system.
   However, obtaining dynamic routing information may help the host to
   detect outages and enable faster response to outages.

5.2.3.2.  Dynamic configuration

   Information about external routes can be propagated within the
   multihomed site using a routing protocol, whether a IGP or BGP.




Huitema, et al.           Expires April 4, 2006                [Page 10]


Internet-Draft      Ingress filtering and multihoming       October 2005


   In order to support SAD routing in this scenario, routing protocols
   also have to convey information about the prefix associated with
   routing information that is being propagated.  That is the prefix
   corresponding to the ISP through which the routing information was
   obtained.

   When BGP is used, it would be possible to use a private community
   attribute to encode such information.  However, current commercial
   routers don't support updating the different routing tables required
   to support SAD routing based on a BGP attribute (as far as we know).

   In the general case, it is possible to run multiple instances of the
   routing protocol and associate each instance to a prefix, so that
   each instance of the routing protocol only carries information
   learned through the ISP corresponding to the prefix.  However, our
   preliminary tests on this mechanisms seem to indicate that such
   mechanism wouldn't be currently supported by commercial routers.

   It should be noted that having dynamic routing information about
   external routes does not provide fault tolerance to the multihomed
   sites as it did in IPv4-style multihoming, since, in sites with
   multiple prefixes, fault tolerance requires changing the prefix used
   for the communication.  However, having dynamic routing information
   available does provide a faster feedback about failures, enabling
   faster response to outages.


























Huitema, et al.           Expires April 4, 2006                [Page 11]


Internet-Draft      Ingress filtering and multihoming       October 2005


6.  Appendix A: Host based optimization

   In this Appendix we present a host based mechanism to provide ingress
   filtering compatibility.  The mechanism, called "Exit router
   discovery", enables the host to discover the preferred exit router
   for a given source address so that the host can tunnel the packet
   directly to the adequate exit router, obtaining optimal site exit
   path.

   Exit router discovery is a natural complement of the tunneling
   mechanism between site exit routers.  When an exit router tunnels a
   misdirected packet towards another exit, it may send an appropriate
   ICMP Destination Unreachable error message with code 5 which means
   source address failed ingress policy.  If the host is a legacy host,
   the ICMP message will be ignored; further packets will continue using
   the same slightly sub-optimal path.  On the other hand, if the host
   has been upgraded to take advantage of multi-homing, the packets will
   be tunneled to the appropriate exit router; they will follow a direct
   path to this router.

   So, according to this mechanisms presented in this memo, site exit
   routers are expected to perform necessary source address checks
   before forwarding any packet on a site exit link.  The amount of
   checking will vary depending on the exit link.  If the provider has
   agreed to relax source address checking, the router will be
   configured to not do any checking at all; if the provider is expected
   to enforce a source address check, the site exit router must do the
   check first, in order to avoid local packets being routed to a black
   hole.  If the result of the check is positive, the packet will be
   forwarded.  If the result is negative, the router will derive a "site
   exit anycast address" from the source address of the incoming packet.
   If the anycast address is unreachable, the incoming packet will have
   to be discarded.  If the anycast address is reachable, the incoming
   packet will be tunneled towards that address, and the router may
   issue a ICMP Destination Unreachable error message with code 5 which
   means source address failed ingress policy.

   The reception of the ICMP packet is interpreted by the host
   implementing the exit discovery mechanism as an indication that the
   exit path being used is suboptimal.  So, the host will first generate
   the site exit anycast address that corresponds to the source prefix
   of the packet that caused the generation of the ICMP packet (this is
   possible because the ICMP message payload contains enough information
   about the initial packet).  Then, the host will associate this site
   exit anycast address to the source and destination address pair of
   the initial packet, and then tunnel packets directly to that exit
   router which will decapsulate these packets and send them over the
   appropriate exit link.



Huitema, et al.           Expires April 4, 2006                [Page 12]


Internet-Draft      Ingress filtering and multihoming       October 2005


   This mechanism requires a change to the caches used in neighbor
   discovery, specifically the management of a "source exit cache" that
   associates a specific source address with an exit router, or maybe
   the combination of a destination address and a source address with an
   exit router.

   We should note that "exit router discovery" is not implemented in
   current hosts.  We must meet the requirement expressed in RFC 3582
   that hosts implementing the current version of IPv6 can continue to
   operate in a multi-homed site, even if they would not take advantage
   of multihoming; in consequence, these procedures can only be used as
   an optional optimization.  It should also be noted that the presented
   mechanism does not requires any support from the host outside the
   multihomed site.





































Huitema, et al.           Expires April 4, 2006                [Page 13]


Internet-Draft      Ingress filtering and multihoming       October 2005


7.  Security Considerations

   There are elements presented in this draft that require further
   analysis from a security point of view: the usage of the anycast
   address of the site exit router associated to a given prefix and the
   usage of ICMP error messages to redirect following packets.

   The usage of the anycast address of the site exit router router
   associated to a given prefix may enable potential attacks where the
   attacker announces the anycast address associated with a certain
   perifx and sinks the traffic containing such prefix in the source
   address.  However, this threat is similar to the case where an
   attacker simply injects a route in the interior routing system, for
   instance a default route, sinking the packets of those routers and
   hosts that preffer such route.

   An attacker could generate false ICMP errors to trigger the
   tunnelling of packets to the anycast address associated with the
   prefix of the source address.  However, the result of such attack
   would simply be that packets are tunnelled through the appropriate
   site exit router.  In the worst case, the packet would carry an extra
   tunnel header that would not be really required, causing additional
   overhead.  In any case, these attack does not seem to cause
   cosniderable harm.



























Huitema, et al.           Expires April 4, 2006                [Page 14]


Internet-Draft      Ingress filtering and multihoming       October 2005


8.  Acknowledgments

   This memo contains parts of a previous work entitled "Host-Centric
   IPv6 Multihoming" that benefited from comments from Alberto Garcia
   Martinez, Cedric de Launois, Brian Carpenter, Dave Crocker, Xiaowei
   Yang and Erik Nordmark.

9.  References

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

   [2]  Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
        Multihoming Architectures", RFC 3582, August 2003.

   [3]  Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
        Denial of Service Attacks which employ IP Source Address
        Spoofing", RFC 2267, January 1998.

   [4]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

   [5]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
        Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
        March 2003.


























Huitema, et al.           Expires April 4, 2006                [Page 15]


Internet-Draft      Ingress filtering and multihoming       October 2005


Authors' Addresses

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA

   Phone:
   Email: huitema@microsoft.com
   URI:


   Richard Draves
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   USA

   Phone:
   Email: richdr@microsoft.com
   URI:


   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


















Huitema, et al.           Expires April 4, 2006                [Page 16]


Internet-Draft      Ingress filtering and multihoming       October 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.




Huitema, et al.           Expires April 4, 2006                [Page 17]