IPv6 Operations Working Group                                M. Stenberg
Internet-Draft                                                  O. Troan
Expires: June 12, 2008                               Cisco Systems, Inc.
                                                       December 10, 2007

      IPv6 Prefix Delegation routing state maintenance approaches

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on June 12, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Stenberg & Troan          Expires June 12, 2008                 [Page 1]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007


   The maintenance of Prefix Delegation (PD) routing state is an issue
   that people have discussed in the IETF DHC WG, and there have been
   drafts on the topic.  However, as the pros and cons of the different
   routing state maintenance solutions have not been examined
   thoroughly, this text attempts to shed some light on both the actual
   problem and the various alternative solutions.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Different approaches for maintaining routing state . . . . . .  5
     2.1.  Backend provisioning system responsible for routing
           state  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Delegating router responsible for routing state  . . . . .  6
       2.2.1.  Approach 1: On-demand lease query  . . . . . . . . . .  7
       2.2.2.  Approach 2: Anticipatory lease query . . . . . . . . .  7
       2.2.3.  Approach 3: Persistent storage . . . . . . . . . . . .  8
     2.3.  Requesting router responsible for routing state  . . . . .  9
       2.3.1.  Approach 1: Layer-2 detection of link state  . . . . .  9
       2.3.2.  Approach 2: Keepalive  . . . . . . . . . . . . . . . .  9
       2.3.3.  Approach 3: Short lifetimes  . . . . . . . . . . . . . 10
       2.3.4.  Approach 4: Routing protocol to the requesting
               router . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Informative references . . . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 16
   Appendix B.  Revision history  . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

Stenberg & Troan          Expires June 12, 2008                 [Page 2]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

1.  Introduction

   A prefix delegation deployment consists of Requesting Routers (RR),
   Delegating Routers (DR) and possibly a backend provisioning system
   (see Figure 1).  The delegated prefix has to be routed in the
   network.  This document explores various alternatives for how the
   route for the delegated prefix can be injected in the network, and
   how the routing state can be maintained.

   | Network |
    |                                         \
    | +-----------------------------+-------------------+
    | | Backend provisioning system | DR 4 (integrated) |
    | +-----------------------------+-------------------+
    |    |                       |             |
    | +------+                +------+     +------+
    |-| DR 1 |                | DR 3 |     | RR 3 |
    \ +------+                +------+     +------+
     --- | --------------------/ |
      +------+                +------+
      | DR 2 |                | RR 2 |
      +------+                +------+
      | RR 1 |

          Figure 1: Possible prefix delegation deployment cases.

   Prefix delegation is a stateful protocol.  The RR needs to maintain
   state so that it can sub-delegate prefixes to downstream links.  The
   RR maintains soft-state which can be recovered by redoing the prefix
   request (for example, using Dynamic Host Configuration Protocol for
   IPv6 (DHCPv6) [RFC3315] with the Prefix Delegation options defined in

   If the DR should do route injection on behalf of the RR, it needs to
   maintain state.  The backend provisioning system must maintain a list
   of prefixes delegated, as a prefix delegation is a long-lived entity
   (lifetime of a customer relationship, as in months or years).  The
   backend system and DR might run on the same router.  This document
   focuses on the case where the backend system and DR are separate and
   the DR has little or no persistent storage.  Therefore the DR 4 case
   (in Figure 1) is not covered here, as it is trivial - the backend has

Stenberg & Troan          Expires June 12, 2008                 [Page 3]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

   nonvolatile storage for the prefixes, and it can re-inject the routes
   when the integrated DR 4 restarts.

   The DR's routing state that needs to be maintained can be divided
   into two distinct categories: local routing state (that is, a local
   RIB entry containing the next-hop and the interface the assigned
   prefix is connected to), and global (AS-wide) routing state which
   requires advertising the route via a routing protocol.

   Advertising a route per delegation from the DR can be avoided if
   there is an aggregate prefix covering the delegation.  This requires
   stringent address allocation procedures and prohibits an RR from
   moving to a different DR.

Stenberg & Troan          Expires June 12, 2008                 [Page 4]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

2.  Different approaches for maintaining routing state

   As any router (or the backend system for that matter) can go offline
   and come back up later, it is necessary for the system to recover
   from these intermittent failures.

   The problem is how to delegate responsibility for route maintenance
   to one (or more) of the three components of the system, and letting
   it take care of maintaining the required routing state in place for
   the RR's prefix.

2.1.  Backend provisioning system responsible for routing state

   Considering the backend provisioning system is the only component in
   the system that actually requires significant amount of nonvolatile
   storage, from data system point of view it would be ideal to have the
   backend provisioning system responsible for maintaining the routing
   state as well.

   It would mean that the backend provisioning system should, when DR
   restarts, (securely) re-inject the local or global routing state into
   the DR(s).  Similarly, whenever first hop DR-RR link goes down, the
   backend provisioning system should remove the routing state for the

   In practise, this is infeasible as a general-purpose, standard-
   oriented solution - there is a significant amount of both information
   access and routing state configuration change methods that cannot be
   done with the currently available standards.

   o  There is no standard way for the backend to detect when the DR is
      restarted, or when the first hop DR-RR link goes down without some
      sort of keepalive mechanism, and if the keepalive mechanism fails,
      there are multiple potential reasons for that which require
      different reactions from the backend system.  This leads to
      implementation complexity.

   o  None of the current routing protocols are suitable for altering
      remote router's local routing information, and therefore some
      protocol development would be in order for this approach to be
      usable.  As alternative, some out of band configuration method
      might be used for this, such as say, XML over some secure
      transport, but those are also currently not defined.  There are
      also security implications with this solution when passing
      administrative boundaries.

   o  The backend may lack the information to identify the DR to the
      routing system.  With multiple DRs, if the delegation protocol

Stenberg & Troan          Expires June 12, 2008                 [Page 5]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

      does not contain everything needed to re-inject the route later on
      to the specific DR, the re-injection cannot be performed (without
      some statistic configuration, at least).  For example, DHCPv6 does
      not uniquely identify the relays.  And if interim DRs do not have
      backend provisioning system-addressible addresses, there is a
      problem.  All DRs may not have global unicast addresses, and this
      is problematic especially in configurations spanning multiple
      administrative domains.

   In addition to lacking the ways of retrieving/altering the DR state,
   there are also some issues with the backend system performing active
   role for the maintenance of the routing state:

   o  Redundancy of DR, or the links between DR and backend system,
      makes it difficult for the backend system to judge the state of
      the DR accurately without significant extra configuration data
      about the deployed configuration.

   o  Lack of scalability; the benefit of having 'backend' provisioning
      system disappears as it will need to take care of maintaining
      routes of every one of its DRs.

   Having noted these disclaimers about "standard"-oriented ways of
   shifting the routing state maintenance to the backend system, it must
   be noted that given some proprietary solutions for the state
   retrieval from the DR, as well as method of pushing routing state,
   the backend system may be viable candidate for maintaining the
   routing state.  This type of approach would consist of (for example)
   Bidirectional Forwarding Detection (BFD - [I-D.ietf-bfd-base]) or
   some layer-2 way for the backend provisioning system to make sure
   that the RR connectivity is available; if it is down for significant
   period of time, the route for the allocated prefix could be removed
   until either connectivity resumes (that is, either the RR reconnects
   or some intermediate network failure is repaired).  If the first-hop
   DR requires some sort of updating whenever connectivity is restored,
   some way of accessing DR and querying and updating it's state would
   be needed.

   Having the backend provisioning system responsible for the routing
   state of the whole system seems possible only in some walled-garden
   proprietary applications; for general-purpose approach, we look
   elsewhere, that is, delegating router/requesting router-based

2.2.  Delegating router responsible for routing state

   As the DR is part of the local routing infrastructure, placing the
   responsibility for routing state in the DR seems sensible.  With that

Stenberg & Troan          Expires June 12, 2008                 [Page 6]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

   design decision, the next problem is _when_ the routing information
   is updated after the DR restarts:

2.2.1.  Approach 1: On-demand lease query

   In the on-demand lease query case as defined in
   [I-D.ietf-dhc-dhcvp6-leasequery], the routing state maintenance
   problem is assumed to be local, and therefore the DR will receive
   packets both from the network at large as well as the RR even after a
   loss of local state caused by a restart.

   When traffic arrives to DR either from the RR, or from the network to
   the DR for a prefix without local routing information, the DR will
   perform lease query, acquire the allocated prefix, and update the
   routing information appropriately.

   This approach, while simple to specify, has some major issues:

   o  It depends on the aggregated prefix to cause the inbound traffic
      to wind up in the DR.  This assumption may not be valid, depending
      on the address assignment policies of the organization.
      Geographical or network topological hierarchical address
      assignment at large seems to be a failure, and it is unclear if
      all deployments can really implement this.

   o  It requires the incoming traffic both from the RR and the network,
      for which no route exists, to trigger the lease query.  This has
      two negative side effects: it requires support from the fast path
      hardware in the DR, and potentially causes large amount of
      spurious requests to the backend provisioning system (up to the
      desired rate that is considered harmful to the system).

   o  It requires simulated ordering of the unordered transaction
      stream, to ensure that the routing state is maintained correctly.
      The DR cannot be argued to be particularly stateless anymore.

2.2.2.  Approach 2: Anticipatory lease query

   Anticipatory, or bulk lease query, solves the routing state problem
   by requesting ALL prefix information from the backend provisioning
   system at the DR restart time.  There are two different ways: The
   first approach is asynchronous, that is, the old state is fetched
   while handling the delegation requests, requiring synchronization
   algorithm between the bulk data retrieved from the backend system,
   and the requests served during that.  For synchronization, some sort
   of ordering of the transaction stream is needed.  The second
   alternative is synchronous: the bulk query is performed first, and
   only then the RRs' requests are handled.

Stenberg & Troan          Expires June 12, 2008                 [Page 7]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

   Bulk query has several advantages over the on-demand case:

   o  No need for triggering based on either inbound or outbound traffic
      for the prefix.

   o  If DR handles the query synchronously, we can avoid the ordering
      of the transaction stream and the associated complexity rising
      from it.

   o  Given reasonable TCP transport scheme, the transfer of the state
      is more efficient than the on-demand case in terms of total number
      of packets.

   o  Does not require changes to fast path hardware, as no new triggers
      are needed from the traffic.  Instead, simple additional code in
      the system initialization is enough.

   But, unfortunately it has also some disadvantages:

   o  It causes more uneven load on the backend provisioning system than
      the on-demand case.  If the prefix is not being actively used at
      the time, it will not cause traffic in the on-demand case, but it
      will in the bulk case.

   o  Synchronization is non-trivial if the DR serves RR requests during
      the bulk retrieval of the data.

   o  Doesn't work very well with virtual interfaces - it is hard to
      retrieve state at boot time if the interfaces themselves get up
      only at some point, and with their transient nature mapping a DUID
      to individual customers is difficult.

2.2.3.  Approach 3: Persistent storage

   It is possible for the DR to store the route information to be
   injected either locally, or on some adjacent storage node.  The clear
   advantage of this is the lack of traffic on the wire.

   Unfortunately, it has also some problems - the data being possibly
   outdated due to lack of synchronization, and the management overhead
   when the customers for example move around would be significant.

   However, in most deployment scenarios persistent storage at or near
   all routers is not desirable or possible in the first place, so this
   is listed simply for the sake of completeness.

Stenberg & Troan          Expires June 12, 2008                 [Page 8]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

2.3.  Requesting router responsible for routing state

   The most interested party in the routing state of the given prefix is
   the RR itself; therefore, giving the responsibility for maintaining
   its routing state to it seemed to be idea worth considering.

   Due to the operators wariness of the systems not under their direct
   control, even with the RR responsible for maintenance of the state,
   the real route injection should be handled by the DR.

   The nice thing about some of the RR-oriented solutions is that they
   can be deployed without any changes to the rest of the

2.3.1.  Approach 1: Layer-2 detection of link state

   If the RR implementation gets notifications about the state of the
   link layer, it can actually detect the state of the network link
   going down and coming back up; performing reconfiguration to ensure
   that the routing state is still up seems like a trivial solution in
   this case.

   This solution can be the best one when operating over connection-
   oriented media (PPPoE, L2TP) but it doesn't work on say, Ethernet
   without direct connection between the RR and DR.

2.3.2.  Approach 2: Keepalive

   If the RR doesn't have L2 way of detecting DR being restarted, it can
   maintain a keepalive mechanism using, for example, BFD to send self-
   addressed echo packets to the DR and waiting for their replies.  The
   implementations SHOULD do this only if there is no traffic from the
   network within a desired period of time - see IPv6 Neighbor
   Unreachability Detection (NUD)'s definition of forward progress
   detection as a way to send keepalives only when truly necessary in

   Assuming sub-second round-trips (reasonable assumption in most modern
   network environments), the longest factor for the determining the
   keepalive timeout is the recovery speed of the DR (by orders of
   magnitude), as it can take from some seconds (hot standby) to minutes
   (non-HA restart, or cold standby with huge configurations).  The
   initial keepalive timer should be some fraction of the highest delay
   in the system, that is, the DR recovery time.  The subsequent retries
   if no reply is received within reasonable timeframe should be
   calculated based on the link delay, and jitter, to ensure that the
   reply is unlikely to be coming back by the time the keepalive message
   is re-sent.

Stenberg & Troan          Expires June 12, 2008                 [Page 9]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

   As far as overhead is concerned, assuming the cold standby/restart
   taking minute(s), with a keepalive per 60 seconds for example, the
   QoS would remain roughly same as with faster intervals (as the DR
   going down would cause interruption in the routing in the order of
   minute(s) in any case).  This value would cause overhead of 0.017pps
   per RR, and it is unlikely to be the straw that breaks camel's back
   for the DR, as the BFD handling on should on the receiver side should
   be simply a matter of re-forwarding the traffic within fast path, and
   therefore it should not require any routing plane resources to
   handle.  With any traffic, even NUD packets should outnumber the
   keepalive traffic.

   As far as resource utilization is concerned, this solution involves
   only routing plane of the RR, the data link between RR and DR, and
   fast path of DR which bounces the packets back.  Therefore it can be
   argued to be fairly lightweight general-purpose solution.

2.3.3.  Approach 3: Short lifetimes

   The current best practice for maintaining the routing state is to set
   short configuration lifetimes (DHCP T1/T2 values).  It causes extra
   traffic and load on the whole DHCP infrastructure.  That is because
   during every reconfiguration, even with the DR constantly up and
   running, the backend system is queried.  The transaction involves all
   three components.  Due to that, every RR will cause constant load on
   the backend system itself over the time, making the solution simply
   not scale well.

2.3.4.  Approach 4: Routing protocol to the requesting router

   The final RR-based approach consists of the RR actually running a
   routing protocol; this way, the RR router can simply advertise the
   prefix as it receives it, and everything just works.  Or not, as it
   may be.

   The downside is the security, or complete lack of it.  The DR
   accepting arbitrary RR-advertised prefixes (assuming no state at the
   DR) should be acceptable only if DR and RR are within the same
   administrative domain.  For that case, this is probably the cleanest
   solution of all.

   If administrative boundaries are crossed, the DR will not take prefix
   advertisement at face value.  The DR will have extra overhead of
   checking the backend provisioning system for AAA purposes before
   actually doing anything with the prefix.  This can imply look-up for
   validity using the prefix and the interface the advertisement came
   from, including the DUID or some other identifier within the route
   advertisement message, or using some real AAA mechanism if the

Stenberg & Troan          Expires June 12, 2008                [Page 10]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

   routing protocol supports one.  If minimal changes to the routing
   protocol implementation are desired, it is also possible to ignore
   the advertisement itself, and just trigger on-demand lease query,
   thereby using the routing protocol just as an alternative keepalive
   mechanism the with most of the logic shoved in DR instead of RR.

                     |  Network |
                         |   |
                ---------/   \---------
               /                       \
   +---------------------+   +---------------------+
   | Delegating router 1 |   | Delegating router 2 |
   +---------------------+   +---------------------+
               \                       /
                | Requesting router   |

                     Figure 2: Multihomed deployment.

   There is also a case where the RR HAS to run its own routing
   protocol; in multihomed situation like Figure 2, with the same
   routable prefix advertised via two different DRs, there is no other
   practical way to get the system working.  Of course, static route
   configuration is always an alternative but it is seldom desirable.

   The routing-protocol-based solutions all require a significant level
   of trust between RR and DR; regrettably the current routing protocols
   are not designed with AAA (or security for that matter) in mind, and
   therefore when crossing administrative boundaries, the alternatives
   are either using them as-is as a hint that something needs to be
   done, or significantly extending the protocols in the AAA direction.
   Adding extra complexity to the DR's routing protocol implementation
   or configuration is not desirable in general.

   Finally, the current prefix delegation solution (DHCPv6 PD) does not
   provide the information about which routing protocol to use, and
   there is no routing protocol auto-negotiation protocol.  Therefore
   the auto-configuration of the RR with arbitrary routing protocol
   cannot be done currently.

Stenberg & Troan          Expires June 12, 2008                [Page 11]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

3.  Security Considerations

   The backend-oriented solution detailed in Section 2.1 implies a
   significant level of trust between the DR and the backend
   provisioning system.  The system's configuration is simpler if the
   backend provisioning system can inject arbitrary routes to the DR,
   but allowing injection of routes for only specific sub-prefixes of a
   specific prefix is considerably more secure solution.  Unfortunately
   it requires advance configuration of the prefix(es) involved.

   The delegating router-based solutions detailed in Section 2.2 do not
   have any security issues, assuming the delegation protocol itself is
   secured, or can be assumed to be used only within a trusted network.

   The requesting router-based solutions in Section 2.3, even
   incorrectly implemented, at most just cause extra load to the DR.  As
   noted in Section 2.3.4, even when running routing protocol from the
   RR, ideally the DR should consider the advertisements only a hint at
   best if not part of the same adminstrative domain.  This may not be
   ideal if the routing protocol information should be propagated as-is
   onward, as in the the multihoming cases.  Unfortunately, those cases
   also most likely cross administrative boundaries (the requesting
   router being part of one domain, and connected to delegating routers
   in most likely more than one), the providers will not most likely
   trust the routing protocol to be used as-is at the delegating
   routers, and their complexity will increase due to the required AAA/
   policy checks.  This is a potential security risk in a critical part
   of the network infrastructure.

Stenberg & Troan          Expires June 12, 2008                [Page 12]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

4.  IANA Considerations

   As this document is informational in nature and only summarizes
   current best practices, it does not require action from IANA.

Stenberg & Troan          Expires June 12, 2008                [Page 13]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

5.  Summary

   The backend provisioning system should not be assigned the
   responsibility for the maintenance of the route.  As seen in
   Section 2.1, that approach has significant obstacles without any
   clear benefits.

   If the link layer state can be used to detect the (potential) restart
   of delegating router, the requesting router-based simple
   reconfiguration described in Section 2.3.1 seems to be the best

   When link layer state is not available, there is no clear 'best'
   solution.  The tradeoff seems to be between increasing the complexity
   of the delegation protocol and the delegating router/backend system
   (as described in the lease query cases in Section 2.2.1 and
   Section 2.2.2), decreasing scalability of the system significantly by
   using low lifetimes for configuration (as described in
   Section 2.3.3), or small overhead of the keepalive (as described in
   Section 2.3.2).  The keepalive is most likely the preferred solution
   among these, as it causes load mostly only to the requesting router

   Only in multihoming cases, given some extensions to the current
   prefix delegation protocol, should routing protocol on the requesting
   router be considered, as described in Section 2.3.4.  Multihoming
   solution itself is challenging to do securely, as noted in Section 3,
   due to lack of AAA support in routing protocols.

Stenberg & Troan          Expires June 12, 2008                [Page 14]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

6.  Informative references

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

              Brzozowski, J., "DHCPv6 Leasequery",
              draft-ietf-dhc-dhcvp6-leasequery-01 (work in progress),
              December 2006.

              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", draft-ietf-bfd-base-06 (work in progress),
              March 2007.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

Stenberg & Troan          Expires June 12, 2008                [Page 15]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

Appendix A.  Acknowledgements

   Thanks to Bernie Volz for feedback during writing of the document.
   Also thanks to the assorted people on the DHC mailing list, who
   submitted comments to the second iteration of the draft.

Stenberg & Troan          Expires June 12, 2008                [Page 16]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

Appendix B.  Revision history

   October 2006: draft-stenberg-pd-route-maintenance-00 - initial
   version (IETF67)

   December 2007: draft-stenberg-v6ops-pd-route-maintenance-00 -
   resubmitted at request of some people, with small editorial changes
   and clear indication of preference for the L2 or keepalive solutions.

Stenberg & Troan          Expires June 12, 2008                [Page 17]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

Authors' Addresses

   Markus Stenberg
   Cisco Systems, Inc.
   Shinjuku Mitsui Building, 2-1-1, Nishi-Shinjuku
   Shinjuku-Ku, Tokyo-to  1630409

   Email: mstenber@cisco.com

   Ole Troan
   Cisco Systems, Inc.
   GPK02/2/250 Longwater Avenue
   Reading, England  RG2 6GB

   Email: ot@cisco.com

Stenberg & Troan          Expires June 12, 2008                [Page 18]

Internet-Draft    IPv6 PD route maintenance approaches     December 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   This document and the information contained herein are provided on an

Intellectual Property

   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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Stenberg & Troan          Expires June 12, 2008                [Page 19]