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

Versions: (draft-droms-mext-nemo-pd) 00 01 02 03 04 05 06 07 RFC 6276

Mobile IPv6 Extensions Group                                    R. Droms
Internet-Draft                                                P. Thubert
Intended status: Informational                                     Cisco
Expires: December 19, 2008                                     F. Dupont
                                                                     ISC
                                                               W. Haddad
                                                                Qualcomm
                                                           June 17, 2008


                   DHCPv6 Prefix Delegation for NEMO
                       draft-ietf-mext-nemo-pd-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 December 19, 2008.

Abstract

   One aspect of network mobility support is the assignment of a prefix
   or prefixes to a Mobile Router (MR) for use on the links in the
   Mobile Network.  DHCPv6 prefix delegation can be used for this
   configuration task.







Droms, et al.           Expires December 19, 2008               [Page 1]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


1.  Introduction

   One aspect of network mobility support is the assignment of a prefix
   or prefixes to a Mobile Router for use on the links in the Mobile
   Network.  DHCPv6 prefix delegation [RFC3633] (DHCPv6PD) can be used
   for this configuration task.


2.  Terminology

   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 [RFC2119].

   The following terms used in this document are defined in the IPv6
   Addressing Architecture document [RFC4291]:
      link-local unicast address
      link-local scope multicast address

   The following terms used in this document are defined in the mobile
   IPv6 specification [RFC3775]:
      home agent (HA)
      home link

   The following terms used in this document are defined in the Mobile
   Network terminology document [RFC4886]:
      Mobile Router (MR)
      Mobile Network
      mobile host (MH)

   The following terms used in this document are defined in the DHCPv6
   [RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications:
      delegating router (DR; acts as a DHCPv6 server)
      requesting router (RR; acts as a DHCPv6 client)
      DHCPv6 relay agent

   The following acronym is used in this document:
   DHCPv6PD:  DHCPv6 prefix delegation


3.  Application of DHCPv6 prefix delegation to mobile networks for
    delegation of home prefixes

   The NEMO Basic protocol [RFC3963] extends the mobile IPv6 protocol
   [RFC3775] to enable network mobility.  In this extension, a MR uses
   the mobile IPv6 protocol to establish and maintain a session with its
   HA, and uses bidirectional tunneling between the MR and HA to provide
   a path through which nodes attached to links in the Mobile Network



Droms, et al.           Expires December 19, 2008               [Page 2]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


   can maintain connectivity with nodes not in the Mobile Network.

   The requirements for NEMO [RFC4885] include the ability of the MR to
   receive delegated prefixes that can then be assigned to links in the
   Mobile Network.  DHCPv6PD can be used to meet this requirement for
   prefix delegation.

   To use DHCPv6PD for Mobile Networks, the HA assumes the role of
   either the DR or a DHCPv6 relay agent and the MR assumes the role of
   the RR.  Throughout the remainder of this document, the HA will be
   assumed to be acting as a DHCPv6PD DR or relay agent and the MR will
   be assumed to be acting as a RR.

   If the HA is acting as relay agent, some other device acts as the DR.
   For example, the server providing DHCPv6 service in the home network
   might also provide NEMO DHCPv6PD service.  Or, a home network with
   several HAs might configure one of those HAs as a DHCPv6PD server
   while the other HAs act as relay agents.

   The HA and MR exchange DHCPv6PD protocol messages through the tunnel
   connecting them.  The tunnel acts as the link labeled "DSL to
   subscriber premises" in figure 1 of the DHCPv6PD specification.

   The DHCPv6PD server is provisioned with prefixes to be assigned using
   any of the prefix assignment mechanisms described in the DHCPv6PD
   specifications.  Other updates to the HA data structures required as
   a side effect of prefix delegation are specified by the particular
   network mobility protocol.  For example, in the case of Basic Network
   Mobility Support [RFC3963], the HA would add an entry in its binding
   cache registering the delegated prefix to the MR to which the prefix
   was delegated.

3.1.  When the MR uses DHCPv6

   The MR initiates a DHCPv6 message exchange for prefix delegation
   whenever it establishes an MR-HA tunnel to its HA.  If the MR does
   not have any active delegated prefixes (with unexpired leases), the
   MR initiates a DHCPv6 message exchange with a DHCPv6 Solicit message
   as described in section 17 of RFC 3315 and section 12.1 of RFC 3633.
   If the MR has one or more active delegated prefixes, the MR initiates
   a DHCPv6 message exchange with a DHCPv6 Rebind message as described
   in section 18.1.2 of RFC 3315 and section 12.1 of RFC 3633.

3.2.  Use of MR-HA tunnel for DHCPv6 messages

   The DHCPv6 specification requires the use of link-local unicast and
   link-local scope multicast addresses in DHCPv6 messages (except in
   certain cases as defined in section 22.12 of the DHCPv6



Droms, et al.           Expires December 19, 2008               [Page 3]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


   specification).  Section 10.4.2 of the mobile IPv6 specification
   describes forwarding of intercepted packets, and the third paragraph
   of that section begins:

      However, packets addressed to the mobile node's link-local address
      MUST NOT be tunneled to the mobile node.

   The DHCPv6 messages exchanged between the HA and the MR originate
   only with the HA and the MR, and therefore are not "intercepted
   packets" and may be sent between the HA and the MR through the
   tunnel.

   Even though the MR-HA tunnel is a point to point connection, the MR
   SHOULD use multicast DHCPv6 messages as described in RFC 3315 over
   that tunnel.

3.3.  DHCPv6 Relay Agent for transmission of DHCPv6 messages

   A DHPCv6 relay agent function [RFC3315] can be used as an alternative
   to multicast DHCPv6 messages over the tunnel between the MR and the
   HA.  In this configuration, the relay agent function is co-located in
   the MR with the DHCPv6 client function.  Rather than using multicast
   to send DHCPv6 messages through the tunnel to the DHCPv6 server, the
   DHCPv6 client in the MR hands any outbound DHCPv6 messages to the co-
   located relay agent.  Responses from the DHCPv6 server are delivered
   to the relay agent function in the MR, which extracts the
   encapsulated message and delivers it to the DHCPv6 client in the MR.

3.3.1.  Relay agent configuration

   The use of the relay agent function in the MR allows the MR to
   unicast DHCPv6 messages to the DHCPv6 server.  The relay agent must
   be configured with the address of the DHCPv6 server or another DHCPv6
   relay agent that will forward message on to a DHCPv6 server.  For the
   purposes of NEMO, the relay agent assumes that the HA for the MR
   hosts the next hop in the path the to the DHCPv6 server: either the
   DHCPv6 server or a relay agent that will forward message to the
   DHCPv6 server.  Therefore, if the MR acts as a DHCPv6 relay agent,
   the MR MUST configure the DHCPv6 relay agent to forward DHCPv6
   messages to the HA.

3.3.2.  Transmission of DHCPv6 messages

   In this configuration, when the DHCPv6 client in the MR sends a
   message, it hands the message to the DHCPv6 relay agent in the MR.
   The way in which this handoff takes place is beyond the scope of this
   document.  The relay agent encapsulates the message from the client
   according to RFC 3315 in a Relay-forward message and sends the



Droms, et al.           Expires December 19, 2008               [Page 4]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


   resulting DHCPv6 message to the HA.  The relay agent sets the fields
   in the Relay-forward message as follows:
   msg-type       RELAY-FORW
   hop-count      1
   link-address   A non-link-local address from the MR interface to the
                  tunnel between the HA and MR
   peer-address   A non-link-local address from the MR interface to the
                  tunnel between the HA and MR
   options        MUST include a "Relay Message option" [RFC3315]; MAY
                  include other options added by the relay agent.

3.3.3.  Receipt of DHCPv6 messages

   In this configuration, messages from the DHCPv6 server will be
   returned to the DHCPv6 relay agent, with the message for the DHCPv6
   client encapsulated in the Relay Message option [RFC3315] in a Relay-
   reply message.  The relay agent function extracts the message for the
   client from the Relay Message option and hands the message to the
   DHCPv6 client in the MR.  The way in which this handoff takes place
   is beyond the scope of this document.

3.4.  Exchanging DHCPv6 messages when MR is at home

   When the MR is on its home link, the HA uses the home link to
   exchange DHCPv6PD messages with the MR.  It is the responsibility of
   the implementation to determine when the MR is on its home link and
   to avoid use of any existing tunnel.

3.5.  Minimizing DHCPv6PD messages

   DHCPv6PD in a Mobile Network can be combined with the Rapid Commit
   option [RFC3315] to provide DHCPv6 prefix delegation with a two
   message exchange between the mobile node and the DHCPv6PD DR.

3.6.  DHCPv6PD and DHAAD

   The MR acting as RR needs a direct link to the DR (or relay)
   function.  When the MR is away from Home, that link is the MR-HA
   tunnel.  If a MR needs to obtain a prefix by means of DHCPv6PD, it
   has to locate a HA that is capable of serving either as a DHCPv6PD
   relay agent or server.  Since the use of DHCPv6PD is optional and
   comes as an addition to RFC 3775 existing protocols and RFC 3963, it
   can not be expected that all HAs are DHCPv6PD capable.

   This specification extends Dynamic Home Agent Address Discovery and
   the Home Agent Information Option in order to enable the detection by
   a MR of all HAs that are DHCPv6PD capable.  A new 'D' bit is
   introduced to let Home Agents advertise that they are willing to



Droms, et al.           Expires December 19, 2008               [Page 5]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


   participate to DHCP.  Note that there is no direct way for the MR
   acting as RR to know whether a HA is actually a DR or simply acting
   as a relay.

3.6.1.  Modified Dynamic Home Agent Address Discovery Request

   A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD
   Request message, defined in RFC 3775 and RFC 3963.  The Mobile Router
   sets this flag to indicate that it wants to discover Home Agents
   participating to DHCPv6 Prefix Delegation.

   A the MR which sets the 'D' flag MUST also set the 'R' flag, to
   declare that it is a Mobile Router and asks for a HA that supports
   Mobile Routers, as defined in RFC 3963.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |            Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |R|D|        Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        DHCPv6PD Support Flag (D)

           A one-bit flag that when set indicates that the Mobile Router
           wants to discover Home Agents participating to DHCPv6 Prefix
           Delegation.


   For a description of the other fields in the message, see RFC 3775
   and RFC 3963.

3.6.2.  Modified Dynamic Home Agent Address Discovery Reply

   A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD
   Reply message, defined in RFC 3775 and RFC 3963.  If a Home Agent
   receives a Dynamic Home Agent Discovery request message with the
   DHCPv6PD Support Flag set, it MUST a list of Home Agents
   participating to DHCPv6PD to any replies.

   The DHCPv6PD Support Flag MUST be set if there is at least one Home
   Agent participating to DHCPv6PD.  In that case, the reply will list
   only those HAs that participate to DHCPv6PD, whether they act as
   servers (DRs) or relays.

   A HA that supports DHCPv6PD MUST support Mobile Routers as well, so



Droms, et al.           Expires December 19, 2008               [Page 6]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


   if the 'D' bit is set, then the 'R' bit should be set as well.  So
   there is no need in an implementation to support the case where some
   HAs would support Mobile Routers while others would be participating
   to DHCPv6 Prefix Delegation but none could do both.

   If none of the Home Agents support DHCPv6PD, the Home Agent MAY reply
   with a list of Home Agents that only support NEMO basic Mobile
   Routers or Mobile IPv6 Mobile Nodes.  In this case, the DHCPv6PD
   Support Flag MUST be set to 0.

   The modified message format is as follows.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |            Checksum           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |R|D|         Reserved          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      DHCPv6PD Support Flag (D)

         A one-bit flag that when set indicates that the Home Agents
         listed in this message participate to DHCPv6 Prefix Delegation.

   For a description of the other fields in the message, see RFC 3775
   and RFC 3963.

3.6.3.  Modified Home Agent Information Option

   A new flag (D) (Support for DHCPv6PD) is introduced in the Home Agent
   Information Option defined in RFC 3775 and RFC 3963.

   If a Home Agent participates to DHCPv6PD, it SHOULD set the flag.  If
   the HA sets the 'D' flag, then it MUST also set the 'R' flag,
   Indicating that it supports Mobile Routers, as defined in RFC 3963.










Droms, et al.           Expires December 19, 2008               [Page 7]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |R|D|       Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Home Agent Preference     |      Home Agent Lifetime      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           DHCPv6PD Support Flag (D)

            A one-bit flag that when set indicates that the Home Agents
            participates to DHCPv6 Prefix Delegation.

   For a description of the other fields in the message, see RFC 3775
   and RFC 3963.

3.7.  Location of DHCPv6PD Delegating Router function

   Support of DHCPv6PD for a Mobile Network is optional.

   The use of a DHCPv6 relay agent in DHCPv6PD may require "a protocol
   or other out-of-band communication to add routing information for
   delegated prefixes into the provider edge router" (section 14 of RFC
   3633).  If the DHCPv6PD DR function is implemented in the HA for the
   MR, no relay agent function is required.

   It may be desirable to use a single DR to manage RRs in a network
   with multiple HAs.  In this scenario, the HAs will act as DHCP relay
   agents, forwarding messages between the RRs and the DR.

   Use of the DHCPv6 relay agent function with DHCPv6PD requires that
   there be some mechanism through which routing information for the
   delegated prefixes can be added to the appropriate routing
   infrastructure.  If the HA is acting as a DHCPv6 relay agent, the HA
   SHOULD add a route to the delegated prefix and advertise that route
   after receiving a binding update for the prefix from the RR
   [RFC3963].

   In particular, if the MR uses NEMO explicit mode, then it must add
   the delegated prefix to the prefix list in the Binding Update
   messages.  If the binding cache is cleared before the prefix valid
   lifetime, the MR might bind that prefix again using explicit mode,
   till the lifetime expires.

   In implicit mode, the HA must save the delegated prefix with the
   binding cache entry (BDE) of the Mobile Router.  When the BCE is
   cleared, the HA loses the information about the delegated prefix.
   Because the MR will use DHCPv6 when it reestablishes its tunnel to



Droms, et al.           Expires December 19, 2008               [Page 8]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


   the HA (see Section 3.1), the HA will be able to add the delegated
   prefix back to the BCE.

   At the time this draft was written, one way in which a DR can
   explicitly notify a relay agent about delegated prefixes, is to use
   the "DHCP Relay Agent Assignment Notification Option"
   [I-D.ietf-dhc-dhcpv6-agentopt-delegate].

   Another alternative, if the RR is part of the same administrative
   domain as the home network to which it is attached through the HA,
   and the RR can be trusted, the RR can use a routing protocol like
   OSPF to advertise any delegated prefixes.

   NEMO explicit mode is recommended to take advantage of the function
   already defined for NEMO.

3.8.  Other DHCPv6 functions

   The DHCPv6 messages exchanged between the MR and the HA may also be
   used for other DHCPv6 functions in addition to DHCPv6PD.  For
   example, the HA may assign global addresses to the MR and may pass
   other configuration information such as a list of available DNS
   recursive name servers [RFC3646]xref> to the MR using the same DHCPv6
   messages as used for DHCPV6PD.

   The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR
   for MRs.


4.  Changes in this draft

   This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes
   the use of the DHCPv6 relay agent in the MR, as described in
   Section 3.3, from draft-dupont-mext-dhcrelay-00.


5.  Security Considerations

   This document describes the use of DHCPv6 for prefix delegation in
   Mobile Networks.  It does not introduce any additional security
   considerations beyond those described in the "Security
   Considerations" section of the DHCPv6 base specification [RFC3315]
   and the "Security Considerations" of the DHCPv6 Prefix Delegation
   specification [RFC3633].

   If the network infrastrcuture connecting the various commmunicating
   nodes does not provide message integrity and source authentication
   for the DHCPv6PD messages, HAs and MRs SHOULD use DHCPv6



Droms, et al.           Expires December 19, 2008               [Page 9]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


   authentication as described in section "Authentication of DHCP
   messages" of the DHCPv6 specification [RFC3315], to guard against
   attacks mounted through prefix delegation.


6.  IANA Considerations

   This document describes the use of DHCPv6 for prefix delegation in
   Mobile Networks.  It does not introduce any additional IANA
   considerations.


7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              December 2003.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4885]  Ernst, T. and H-Y. Lach, "Network Mobility Support
              Terminology", RFC 4885, July 2007.

   [RFC4886]  Ernst, T., "Network Mobility Support Goals and
              Requirements", RFC 4886, July 2007.

   [I-D.ietf-dhc-dhcpv6-agentopt-delegate]
              Droms, R., "DHCPv6 Relay Agent Assignment Notification
              (RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02



Droms, et al.           Expires December 19, 2008              [Page 10]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


              (work in progress), November 2006.


Authors' Addresses

   Ralph Droms
   Cisco
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   Phone: +1 978.936.1674
   Email: rdroms@cisco.com


   Pascal Thubert
   Cisco
   Village d'Entreprises Green Side
   400, Avenue Roumanille
   Biot - Sophia Antipolis  06410
   FRANCE

   Email: pthubert@cisco.com


   Francis Dupont
   ISC

   Email: Francis.Dupont@fdupont.fr


   Wassim Haddad
   Qualcomm

   Email: whaddad@qualcomm.com
















Droms, et al.           Expires December 19, 2008              [Page 11]

Internet-Draft      DHCPv6 Prefix Delegation for NEMO          June 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.


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
   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.











Droms, et al.           Expires December 19, 2008              [Page 12]


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