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

Versions: 00 01 02                                                      
MIPSHOP WG                                                  Gabor Bajko
Internet Draft                                                    Nokia
Intended Status: Standards Track                              Subir Das
Expires: May 18, 2008                                         Telcordia
                                                      November 18, 2007


  Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
                    Mobility Server (MoS) discovery
                    draft-bajko-mos-dhcp-options-01


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 May 18, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines a number of Dynamic Host Configuration
   Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) options that contain a
   list of domain names or IP addresses that can be mapped to servers
   providing IEEE 802.21 type of Mobility Services. These Mobility
   Services are used to assist an MN in handover preparation (network
   discovery) and handover decision (network selection). The services
   addressed by this document are the Media Independent Handover
   Services defined in [1].

Conventions used in this document

G. Bajko                   Expires 02/20/08                  [Page 1]


Mobility Services DHCP Options                             August 2007

   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 RFC-2119 [1].

Terminology and abbreviations used in this document

   Mobility Services: comprises of a set of different services provided
   by the network to mobile nodes to facilitate handover preparation
   and handover decision.

   Mobility Server: a network node providing Mobility Support Services.

   MIH: Media Independent Handover, as defined in [1].

   MIH Service: IS, ES or CS type of service, as defined in [1].

Table of Content

   1. Introduction ...................................................2
   2. DHCPv4 Options for MoS Discovery................................3
        2.1 Domain Name List .........................................4
        2.2 IPv4 Address List ........................................5
   3. DHCPv6 Options for MoS Discovery................................5
        3.1 MoS Identifier Option.....................................6
        3.2 IPv6 Relay Agent MoS Option...............................7
        3.3 MoS Information Option                                    8
   4. Option Usage                                                   10
        4.1 Usage of DHCPv4 Options for MoS Discovery                10
        4.2 Usage of DHCPv6 Options for MoS Discovery                11
   5. Security Considerations .......................................11
   6. IANA Considerations ...........................................11
   7. Acknowledgements ..............................................12
   8. Normative References ..........................................12
   9. Informative References ........................................12
   10. Author's Addresses ...........................................12

1. Introduction

   IEEE 802.21 [1] defines three distinct service types to facilitate
   link layer handovers across heterogeneous technologies:

   a) Information Services (IS)
        IS provides a unified framework to the higher layer entities
   across the heterogeneous network environment to facilitate discovery
   and selection of multiple types of networks existing within a
   geographical area, with the objective to help the higher layer
   mobility protocols to acquire a global view of the heterogeneous
   networks and perform seamless handover across these networks.

   b) Event Services (ES)
        Events may indicate changes in state and transmission behavior
   of the physical, data link and logical link layers, or predict state

G. Bajko                   Expires 02/20/08                  [Page 2]


Mobility Services DHCP Options                             August 2007

   changes of these layers. The Event Service may also be used to
   indicate management actions or command status on the part of the
   network or some management entity.

   c) Command Services (CS)
        The command service enables higher layers to control the
   physical, data link, and logical link layers. The higher layers may
   control the reconfiguration or selection of an appropriate link
   through a set of handover commands.

   In IEEE terminology these services are called Media Independent
   Handover (MIH) services.
   While these services may be co-located, the different pattern and
   type of information they provide does not necessitate the co-
   location.

   An MN may make use of any of these MIH service types separately or
   any combination of them.

   It is anticipated that a Mobility Server will not necessarily host
   all three of these MIH services together, thus there is a need to
   discover the MIH services types separately.

   This document defines three dhcp options for DHCPv4 and DHCPv6, one
   for each of the services defined in [1], namely IS, ES and CS. The
   options would allow an MN to locate a Mobility Server which hosts
   the desired MIH service type (IS, ES or CS) the MN is looking for.
   This is one of the possible solutions for locating a server
   providing Mobility Services; manual configuration is an example of
   another.

2. DHCPv4 Options for MoS Discovery

   This section describes three options for DHCPv4.

   The DHCPv4 options for MoS discovery carry either a 32-bit (binary)
   IPv4 address or, preferably, a DNS [RFC1035] fully-qualified domain
   name to be used by the MN to locate a server hosting either an IS,
   an ES or a CS service.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |OPTION_code|    Length     |      enc      |  ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               ...   Mos Server (domain name or IP address list)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option code: IPv4 MoS option codes assigned by IANA (tbd), separate
   ones for IS (IPv4-IS), for ES (IPv4-ES) and CS (IPv4-CS).
   Length: indicates the total number of octets in the option following
   the 'Length' field, including the encoding byte

G. Bajko                   Expires 02/20/08                  [Page 3]


Mobility Services DHCP Options                             August 2007

   enc: one byte indicating the encoding type of the next field

   The options have two encodings, specified by the encoding byte
   ('enc') that follows the code byte. If the encoding byte has the
   value 0, it is followed by a list of domain names, as described
   below (Section 2.1). If the encoding byte has the value 1, it is
   followed by one or more IPv4 addresses (Section 2.2). All
   implementations MUST support both encodings. The 'Length' field
   indicates the total number of octets in the option following the
   'Length' field, including the encoding byte.

   A DHCP server MUST NOT mix the two encodings in the same DHCP
   message, even if it sends two different instances of the same
   option. Attempts to do so would result in incorrect client behavior
   as DHCP processing rules call for the concatenation of multiple
   instances of an option into a single option prior to processing the
   option [7].

   The code for the MIH IS option is XXX. The code for the MIH ES
   option is YYY. The code for the MIH CS option is ZZZ.

2.1 Domain Name List

   If the 'enc' byte has a value of 0, the encoding byte is followed by
   a sequence of labels, encoded according to Section 3.1 of [RFC1035],
   quoted below:

        Domain names in messages are expressed in terms of a sequence
        of labels. Each label is represented as a one octet length
        field followed by that number of octets.  Since every domain
        name ends with the null label of the root, a domain name is
        terminated by a length byte of zero. The high order two bits of
        every length octet must be zero, and the remaining six bits of
        the length field limit the label to 63 octets or less. To
        simplify implementations, the total length of a domain name
        (i.e., label octets and label length octets) is restricted to
        255 octets or less.

   [RFC1035] encoding was chosen to accommodate future
   internationalized domain name mechanisms.
   The minimum length for this encoding is 3.

   The option MAY contain multiple domain names, but these SHOULD refer
   to different NAPTR records, rather than different A records. The
   client MUST try the records in the order listed, applying the
   mechanism described in [8] for each. The client only resolves the
   subsequent domain names if attempts to contact the first one failed
   or yielded no common transport protocols between the MN and the
   server.




G. Bajko                   Expires 02/20/08                  [Page 4]


Mobility Services DHCP Options                             August 2007

   Use of multiple domain names is not meant to replace NAPTR and SRV
   records, but rather to allow a single DHCP server to indicate MIH
   servers operated by multiple providers.

   Clients MUST support compression according to the encoding in
   Section 4.1.4 of "Domain Names - Implementation And Specification"
   [RFC1035].

        Since the domain names are supposed to be different domains,
        compression will likely have little effect, however.

   If the length of the domain list exceeds the maximum permissible
   within a single option (254 octets), then the domain list MUST be
   represented in the DHCP message as specified in [7].

   The DHCP option for this encoding has the following format:

           Code  Len   enc   DNS name of MoS server
         +-----+-----+-----+-----+-----+-----+-----+-----+--
         | XXX |  n  |  0  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
         +-----+-----+-----+-----+-----+-----+-----+-----+--

   As an example, consider the case where the server wants to offer two
   MIH IS servers, "example.com" and "example.net".  These would be
   encoded as follows:

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |XXX|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   +---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+

2.2 IPv4 Address List

   If the 'enc' byte has a value of 1, the encoding byte is followed by
   a list of IPv4 addresses indicating appropriate MIH servers
   available to the MN. Servers MUST be listed in order of preference.

   Its minimum length is 5, and the length MUST be a multiple of 4 plus
   one. The DHCP option for this encoding has the following format:

          Code   Len   enc  IPv4 Address 1          IPv4 Address 2
         +-----+-----+-----+-----+-----+-----+-----+-----+--
         | XXX |  n  |  1  | a1  | a2  | a3  | a4  | a1  |  ...
         +-----+-----+-----+-----+-----+-----+-----+-----+--


3. DHCPv6 Options for MoS discovery

3.1 MoS Identifier Option


G. Bajko                   Expires 02/20/08                  [Page 5]


Mobility Services DHCP Options                             August 2007

   This option is included in the Information-request message and used
   to request an MoS-type information from a given network by the
   mobile node from the DHCP server.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OPTION IPv6-MoS         |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |target network |   MoS-type    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      .                                                               .
      .                        Home Network Identifier                .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            option-code

               OPTION_IPv6-MoS (TBD)

            option-len

               2 + length of the Home Network Identifier field

            Target network

               The target network for the location of MoS Identifier:

                    1 local network
                    2 home network
                    3 both local and home networks

            MoS-Type

               The type of Mobility Services the MN is looking for,
               i.e. IS, ES or CS or a combination of these:
                    1    IS service
                    2    ES service
                    3    both IS and ES services
                    4    CS service
                    5    IS and CS services
                    6    ES and CS services
                    7    IS, ES and CS services

            Home Network Identifier

               The identifier to specify the requested home network of
               the mobile node. This field MUST be set in the form of
               FQDN [RFC1035].

   The target network value 1 indicates the mobile node is interested
   in learning MoS information that pertains to the currently visited
   network.  This type can be used to discover local MoS. In this case,

G. Bajko                   Expires 02/20/08                  [Page 6]


Mobility Services DHCP Options                             August 2007

   the option-len field is set to 2 and the Home Network Identifier
   field MUST NOT be included.

   The target network value of 2 indicates the mobile node is
   interested in learning the MoS information that pertains to the home
   network of the MN. This type can be used to discover MoS that are
   hosted by a user's home domain. The MN's home network is specified
   in the Home Network Identifier field.

   The target network value of 3 indicates the mobile node is
   interested in learning the MoS information that pertains to both
   local and home networks of the MN.


3.2 IPv6 Relay Agent MoS Option

   This option carries the home network information which was
   transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius-MoS,
   TBD]. The DHCP relay agent sends this option to the DHCP server in
   the Relay-forward Message.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     OPTION_IPv6-MoS-RELAY     |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                             sub-options                       .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            option-code

               OPTION_IPv6-MoS-RELAY (TBD).

            option-len

               The length of sub-options

            sub-options

               A series of IPv6 Relay Agent sub-options.


3.2.1. IPv6 Relay Agent Sub-option

   This sub-option carries the MoS information to the DHCP server.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          sub-opt-code         |        sub-opt-len            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   MoS Type    |                                               |

G. Bajko                   Expires 02/20/08                  [Page 7]


Mobility Services DHCP Options                             August 2007

      .                     MoS Address                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            sub-opt-code

               A 16-bit unsigned integer for the type of the following
                MoS Address field. Possible values are:

                   1    MoS IP address list

                   2    MoS FQDN list

            sub-opt-len

               1 + The length of MoS Address field.

            MoS type

               The type of MoS services the server supports. Valid
               values:
                    1    IS service
                    2    ES service
                    3    both IS and ES services
                    4    CS service
                    5    IS and CS services
                    6    ES and CS services
                    7    IS, ES and CS services


            MoS Address

               An MoS IP address or MoS FQDN to be provided to a mobile
   node according to the sub-opt-code.

   When the sub-opt-code is set to 1, the MoS Address field MUST
   contain the 128-bit IPv6 address of the MoS.

   When the sub-opt-code is set to 2, the MoS Address field MUST
   contain the FQDN of the MoS as described in Section 8 of [RFC3315].

   Multiple sub-options may exist in a IPv6 Relay Agent option to carry
   more than one MoS address or FQDN.

3.3 MoS Information Option

   This option is included in the Reply message and used to carry MoS
   information to the mobile node in the form of one or more of MoS IP
   address(es) or MoS FQDN(s).


       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

G. Bajko                   Expires 02/20/08                  [Page 8]


Mobility Services DHCP Options                             August 2007

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OPTION_IPv6-MoSINF       |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                          sub-options                          .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            option-code

               OPTION_IPv6-MoSINF (TBD).

            option-len

               length of sub-options

            sub-options

               A series of MoS  Information sub-options.

3.3.1 MoS Information Sub-option

   This sub-option carries the assigned MoS information to the DHCP
   client.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          sub-opt-code         |          sub-opt-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   MoS Type    |  network      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      .                     MoS Information                           .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            sub-opt-code

               A 16-bit unsigned integer for the type of the following
               MoS Information field. Possible values are:

                   1    MoS address

                   2    MoS FQDN

            sub-opt-len

               2 + length of MoS Information field.

            MoS type

               An 8 bit integer specifying the type of MoS services the

G. Bajko                   Expires 02/20/08                  [Page 9]


Mobility Services DHCP Options                             August 2007

               server supports. Valid values are:


                    0    NULL
                    1    IS service
                    2    ES service
                    3    both IS and ES services
                    4    CS services
                    5    IS and CS services
                    6    ES and CS services
                    7    IS, ES and CS services

            network

                 An 8 bit integer specifying the network where the MoS
   whose address is attached, resides. Valid values:

                    1 home network
                    2 local network

            MoS Information

               An MoS IP address or MoS FQDN to be provided to a mobile
               node according to the sub-opt-code.


   The sub-opt-code, sub-opt-len and MoS Information fields are set in
   the same manner as those of an IPv6 Relay Agent sub-option.

4. Option Usage

4.1 Usage of DHCPv4 Options for MoS Discovery

   The requesting and sending of the proposed DHCPv4 options follow the
   rules for DHCP options in [RFC2131].

4.1.1 Mobile Node behavior

   The mobile node may perform the MoS information discovery procedure
   either during initial association with a network or when the
   mobility service is required. It may also try to perform the MoS
   information discovery when it lacks the network information for MoS
   or needs to change the  MoS for some reasons, for instance, to
   recover from the single point of failure of the existing MoS

   In order to acquire the MoS information, the mobile node MUST send a
   REQUEST message to a unicast server address. In this message the
   mobile node (DHCP client) MUST include the Option Code for the MoS
   Discovery option in the OPTION_code.

4.1.2 DHCP Server behavior


G. Bajko                   Expires 02/20/08                 [Page 10]


Mobility Services DHCP Options                             August 2007

   When the DHCP server receives the REQUEST message with the MoS
   Discovery option in the OPTION_code, the DHCP server MUST follow the
   [RFC2131] logic to construct a REPLY message with the MoS Discovery
   option. The reply message may contain IP address or the FQDN of the
   MoS Server.

   In case that the server cannot find any MoS information, it MUST
   return the MoS Discovery option by setting the MoS Server address
   0.0.0.0 with 'enc' 1.

4.2 DHCPv6 Options for MoS discovery

   TBD.

4.2.1 Mobile node behavior

4.2.2 DHCP Relay Agent behavior

4.2.3 DHCP Server behavior


5. Security Considerations

   The security considerations in [RFC2131] apply. If an adversary
   manages to modify the response from a DHCP server or insert its own
   response, an MN could be led to contact a rogue Mobility Server,
   possibly one that then would provide wrong information, event or
   command for handover.

   It is recommended to use either DHCP authentication option described
   in [RFC3118] where available, or rely upon link layer security. This
   will also protect the denial of service attacks to DHCP servers.
   [RFC3118] provides mechanisms for both entity authentication and
   message authentication.

6. IANA Considerations

   This document registers the following dhcpv4 options with IANA:

   IPv4-IS
   IPv4-ES
   IPv4-CS

   This document also registers the following dhcpv6 options with IANA:

   IPv6-MoSINF
   IPv6-MoS

   This document also registers the following dhcpv6 Relay options with
   IANA:

   IPv6-MoS-RELAY

G. Bajko                   Expires 02/20/08                 [Page 11]


Mobility Services DHCP Options                             August 2007


7. Acknowledgements

   Acknowledgements to the DT members.


8. Normative References

   [1] IEEE 802.21 Standard for Local and Metropolitan Area Networks:
      Media Independent Handover Services
   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
      2131, March 1997.
   [RFC1035] Mockapetris, P., "Domain names - implementation and
      specification", STD 13, RFC 1035, November 1987.
   [7] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
      RFC3396, November 2002.

   [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001

   [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6),
      Droms et al, July 2003



9. Informative References

   [8] Bajko, G. " Locating Mobility Servers", draft-bajko-mos-dns-
      discovery-00.txt


10. Author's Addresses

   Gabor Bajko
   Nokia
   gabor.bajko@nokia.com

   Subir Das
   Telcordia
   subir@research.telcordia.com














G. Bajko                   Expires 02/20/08                 [Page 12]


Mobility Services DHCP Options                             August 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 "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.


Acknowledgment

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






G. Bajko                   Expires 02/20/08                 [Page 13]