[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Proposed Configuration payload for IKEv2



Attached is a draft which is intended to be merged with the IKEv2 draft.
There is no intent for this draft to continue on its own.  It contains a
payload and description of how an IPsec Remote Access Client (IRAC) may use
that payload to get configuration information (internal IP, subnets, etc.)
from an IPsec Remote Access Server (IRAS).

The payload in this draft is very similar to the IKEv1 modecfg draft, this
draft states the differences between the two.

Why do this?  (copied from vpnc.org) "At the IETF meeting in Atlanta in
November, 2002, the IPsec WG decided to add remote access capabilities
(legacy authentication and remote client configuration) to IKEv2. At an
informal design team meeting after the WG meeting, the VPN vendors attending
decided that the best options to propose to the WG were to add capabilities
similar to XAUTH and MODE-CFG."

Please send all comments regarding this draft to ipsec@lists.tislabs.com

Thanks,
  Darren

INTERNET-DRAFT                                             Darren Dukes 
Expires July 2003                                                       
Document: <draft-dukes-ikev2-config-payload-00.txt>       Cisco Systems 
                                                          December 2002 
 
 
                         Configuration payload 
               <draft-dukes-ikev2-config-payload-00.txt> 
 
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  
    
   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. 
    
    
Abstract 
    
   This document proposes changes to IKEv2 [IKEv2] to allow 
   configuration data to be securely distributed to IPsec Remote Access 
   Clients (IRACs) by IPsec Remote Access Servers (IRASs).  It is 
   assumed this draft will be merged with the IKEv2 draft [IKEv2] and 
   refers to sections in that draft, preceded by "****”.  This draft, 
   on its own, is not intended to progress to any RFC status. 
    
   Comments regarding this draft should be sent to ddukes@cisco.com or 
   ipsec@lists.tislabs.com 
    
Conventions used in this document 
    
   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 [2]. 
    
    





  
Dukes                                                                1 

                     IKEv2 Configuration Payload        December 2002 
 
 
    
Table of Contents 
   1. Introduction...................................................3 
   1.1. Changes from draft-dukes-ike-mode-cfg-02.txt.................3 
   1.2. Reader Prerequisites.........................................3 
   2. IKE_SA_AUTH Exchange changes...................................3 
   2. Informational (Phase 2) Exchanges..............................4 
   3. Configuration Payload..........................................4 
   3.1. Configuration Attributes.....................................6 
   4. Notify Message Types...........................................8 
   5. Implementation Notes...........................................8 
   5.1. Requesting an Internal Address...............................8 
   5.2. Requesting the Peer's Version................................9 
   6. Enterprise Management Considerations..........................10 
   7. Security Considerations.......................................10 
   8. References....................................................10 
   9. Acknowledgments...............................................11 
   10. Author's Addresses...........................................11 
   Full Copyright Statement.........................................12 
    

































  
Dukes                                                                2 

                     IKEv2 Configuration Payload        December 2002 
 
 
    
1. Introduction 
    
   In remote access scenarios it is desirable and often necessary for 
   an IRAS to provide configuration data, such as an internal IP 
   address, to an IRAC before Child-SAs are created.  This document 
   describes requirements on TSi and TSr, and an additional 
   Configuration Payload in message 3 and 4 (IKE_SA_AUTH) of IKE-SA 
   creation in order to provide configuration data necessary for the 
   creation of Child-SAs.  The Configuration Payload MAY also be used 
   within an Informational Exchange protected by an IKE-SA to request 
   or set configuration data from or to an IKE peer. 
    
1.1. Changes from draft-dukes-ike-mode-cfg-02.txt 
    
   This document is similar to draft-dukes-ike-mode-cfg-02.txt for 
   IKEv1 [IKE], but is not intended to interoperate directly with 
   implementations of that draft. 
    
   Some differences for IKEv2 
   1 - No transaction exchange, use the Informational exchange and the 
   IKE_SA_AUTH exchange. 
   2 - The payload was called Attribute payload in the IKEv1 modecfg, 
   it is called Configuration payload in IKEv2.  
   3 - No Identifier in the Configuration Payload since this was a 
   major point of confusion in the IKEv1 modecfg draft, with no known 
   use other than XAUTH. 
   4 - Configuration payloads are always secured via the IKE-SA. 
    
    
1.2. Reader Prerequisites 
    
   It is assumed that the reader is familiar with Proposal for the 
   Internet Key Exchange (IKEv2) Protocol [IKEv2] 
    
2. IKE_SA_AUTH Exchange changes 
    
**** [Below are changes to section 3.1 of [IKEv2], Message 3 and 4 are 
modified to include the Configuration Payload and additional 
description of CP and TS requirements are added] 
 
          HDR, SAi1, KEi, Ni, Nr, 
                SK {IDi, [CERT,] [CERTREQ,] [IDr,] 
                     AUTH, [CP], SAi2, TSi, TSr}     --> 
    
   The optional CP (Configuration Payload) MAY be sent by the initiator 
   to request configuration data.  If CP is used to request an internal 
   IP address (as is often the case when the initiator is an IRAC) the 
   initiator may not know what to place in the TSi payload, in this 
   case she MUST include at least one Traffic Selector in TSi with a 
   suitable range of ports, and addresses.  As an example, if the 
   initiator did not have a selector trigger SA creation (as may be the 
   case when an IRAC starts up) she may include the selector (0.0.0.0-
  
Dukes                                                                3 

                     IKEv2 Configuration Payload        December 2002 
 
 
   255.255.255.255) all ports and protocols.  At least one suitable 
   selector MUST be included in TSr.  Continuing with this example, the 
   initiator may not have any knowledge of the addresses secured by the 
   responder so she MAY include the selector (0.0.0.0-255.255.255.255) 
   all ports and protocols, requiring the responder to choose a 
   narrower selector if necessary. 
 
                                     <--    HDR, SK {IDr, [CERT,] AUTH, 
                                                [CP], SAr2, TSi, TSr} 
    
   If CP was present in message 3 there MUST be a corresponding CP in 
   message 4.  When the responder sends a CP containing an internal IP 
   address in message 4, he MUST limit the traffic selector(s) in TSi 
   to contain only the address, or addresses, in the CP.  The responder 
   MAY choose to limit TSr as described in section 4.9 Negotiating 
   Traffic Selectors of [IKEv2]. 
    
2. Informational (Phase 2) Exchanges 
    
**** [This is an amendment to [IKEv2] section 3.3, paragraph 5 and the 
exchange description at the end of that section] 
    
   Messages in an Informational Exchange may contain zero or one 
   Configuration Payloads.  If there is a Configuration Payload in a 
   request there MUST be a corresponding Configuration Payload in the 
   response. 
    
   The Informational Exchange is defined as: 
    
     Initiator                        Responder 
    -----------                      ----------- 
     HDR, SK {N, ..., D, ..., CP, ...} --> 
                              <--     HDR, SK {N, ..., D, ..., CP, ...} 
    
3. Configuration Payload 
    
**** [This should be added to [IKEv2] section 5.?] 
 
   A Configuration payload, denoted CP in this document, is used to 
   exchange configuration information between IKE peers.  Typically the 
   peers would be an IRAC and IRAS.  A Configuration Payload MAY appear 
   in an Informational exchange, or an IKE_SA_AUTH exchange, and MUST 
   NOT be in any other exchanges. 
    
   Configuration payloads are of type CFG_REQUEST/CFG_REPLY or 
   CFG_SET/CFG_ACK (see CFG Type in the payload description below)  
    
   o "CFG_REQUEST/CFG_REPLY" allows an IRAC to request information from 
   an IRAS.  If an attribute in the CFG_REQUEST Configuration Payload 
   is not zero length it is taken as a suggestion for that attribute.  
   The CFG_REPLY Configuration Payload MAY return that attribute, or a 
   new one.  It MAY also add new attributes and not include some 
   requested ones. 
  
Dukes                                                                4 

                     IKEv2 Configuration Payload        December 2002 
 
 
    
   A CFG_REPLY MUST be sent when a CFG_REQUEST is received, even if it 
   is empty, or missing attributes from the CFG_REQUEST.  This merely 
   means that the requested attributes were not available or unknown. 
    
       Initiator                       Responder 
       ---------------                 -------------- 
       HDR, SK{CP(CFG_REQUEST)} --> 
                                 <--   HDR, SK{CP(CFG_REPLY)} 
    
   o "CFG_SET/CFG_ACK" allows an IRAS to push configuration data to an 
   IRAC.  In this case the CFG_SET Configuration Payload contains 
   attributes the initiator wants its peer to alter.  The responder 
   MUST return a Configuration Payload and it MUST contain the zero 
   length attributes that the responder accepted.  Those attributes 
   that it did not accept MUST NOT be in the CFG_ACK Configuration 
   Payload. 
    
       Initiator                       Responder 
       ---------------                 -------------- 
       HDR, SK{CP(CFG_SET)}      --> 
                                 <--   HDR, SK{CP(CFG_ACK)} 
    
    
   The Configuration Payload is defined as follows: 
                          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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     ! Next Payload  !C! RESERVED    !         Payload Length        ! 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     !   CFG Type    !                    RESERVED                   ! 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     !                                                               ! 
     ~                   Configuration Attributes                    ~ 
     !                                                               ! 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
   o CFG Type (1 octet) - The type of exchange represented by the 
   Configuration Attributes. 
    
          Types            Value 
          ================ =========== 
           RESERVED         0 
           CFG_REQUEST      1 
           CFG_REPLY        2 
           CFG_SET          3 
           CFG_ACK          4 
    
   values 5-127 are reserved to IANA. Values 128-255 are for private 
   use among mutually consenting parties. 
    
   o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored. 
  
Dukes                                                                5 

                     IKEv2 Configuration Payload        December 2002 
 
 
    
   o Configuration Attribute (variable length) - These are type length 
   values specific to the Configuration Payload and are defined below.  
   There may be zero or more Configuration Attributes in this payload. 
    
   The payload type for the Configuration Payload is **TBD** (**TBD**). 
    
    
3.1. Configuration Attributes 
    
**** [ This section would be a subsection 5.?.1] 
    
                          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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     !R|         Attribute Type      !            Length             | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               | 
     ~                             Value                             ~ 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
   o Reserved (1 bit) - This bit MUST be set to zero and MUST be 
   ignored. 
    
   o Attribute Type (7 bits) - A unique identifier for each of the 
   Configuration Attribute Types, the following are currently defined: 
    
                                   MUST 
     Attribute Type          Value Support  Length 
     ======================= ===== =======  ================== 
      RESERVED                 0 
      INTERNAL_IP4_ADDRESS     1     YES    0 or 4 octets 
      INTERNAL_IP4_NETMASK     2     NO     0 or 4 octets 
      INTERNAL_IP4_DNS         3     NO     0 or 4 octets 
      INTERNAL_IP4_NBNS        4     NO     0 or 4 octets 
      INTERNAL_ADDRESS_EXPIRY  5     YES    0 or 4 octets 
      INTERNAL_IP4_DHCP        6     NO     0 or 4 octets 
      APPLICATION_VERSION      7     YES    0 or more 
      INTERNAL_IP6_ADDRESS     8     YES    0 or 16 octets 
      INTERNAL_IP6_NETMASK     9     NO     0 or 16 octets 
      INTERNAL_IP6_DNS        10     NO     0 or 16 octets 
      INTERNAL_IP6_NBNS       11     NO     0 or 16 octets 
      INTERNAL_IP6_DHCP       12     NO     0 or 16 octets 
      INTERNAL_IP4_SUBNET     13     YES    0 or 8 octets 
      SUPPORTED_ATTRIBUTES    14     YES    0 or multiples of 2 
      INTERNAL_IP6_SUBNET     15     YES    0 or 17 octets 
    
     values 16-16383 are reserved to IANA. Values 16384-32767 are for 
     private use among mutually consenting parties. 
      

  
Dukes                                                                6 

                     IKEv2 Configuration Payload        December 2002 
 
 
     o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 
     internal network, sometimes called a red node address or private 
     address and MAY be a private address on the Internet.  Multiple 
     internal addresses MAY be requested by requesting multiple 
     internal address attributes.  The responder MAY only send up to 
     the number of addresses requested. 
      
     The requested address is valid until the expiry time defined with 
     the INTERNAL_ADDRESS EXPIRY attribute or there are no IKE-SAs 
     between the peers. 
      
     o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal 
     network's netmask.  Only one netmask is allowed in the request and 
     reply messages (e.g. 255.255.255.0) and it MUST be used only with 
     an INTERNAL_ADDRESS attribute. 
      
     o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a 
     DNS server within the network.  Multiple DNS servers MAY be 
     requested.  The responder MAY respond with zero or more DNS server 
     attributes. 
      
     o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a 
     NetBios Name Server (WINS) within the network.  Multiple NBNS 
     servers MAY be requested.  The responder MAY respond with zero or 
     more NBNS server attributes. 
      
     o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that 
     the host can use the internal IP address.  The host MUST renew the 
     IP address before this expiry time.  Only one of these attributes 
     MAY be present in the reply. 
      
     o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to 
     send any internal DHCP requests to the address contained within 
     the attribute.  Multiple DHCP servers MAY be requested.  The 
     responder MAY respond with zero or more DHCP server attributes. 
      
     o APPLICATION_VERSION - The version or application information of 
     the IPSec host.  This is a string of printable ASCII characters 
     that is NOT null terminated. 
      
     o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
     device protects.  This attribute is made up of two fields; the 
     first being an IP address and the second being a netmask.  
     Multiple sub-networks MAY be requested.  The responder MAY respond 
     with zero or more sub-network attributes. 
      
     o SUPPORTED_ATTRIBUTES - When used within a Request, this 
     attribute must be zero length and specifies a query to the 
     responder to reply back with all of the attributes that it 
     supports.  The response contains an attribute that contains a set 
     of attribute identifiers each in 2 octets.  The length divided by 
     2 (bytes) would state the number of supported attributes contained 
     in the response. 
  
Dukes                                                                7 

                     IKEv2 Configuration Payload        December 2002 
 
 
      
     o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
     device protects.  This attribute is made up of two fields; the 
     first being a 16 octet IPv6 address the second being a one octet 
     prefix-mask as defined in [ADDRIPV6].  Multiple sub-networks MAY 
     be requested.  The responder MAY respond with zero or more sub-
     network attributes. 
      
     Note that no recommendations are made in this document how an 
     implementation actually figures out what information to send in a 
     reply.  i.e. we do not recommend any specific method of an IRAS 
     determining which DNS server should be returned to a requesting 
     IRAC. 
    
   o Length (2 octets) - Length in octets of Value. 
    
   o Value (0 or more octets) - The variable length value of this 
   Configuration Attribute. 
    
4. Notify Message Types 
 
**** [ This section is an amendment to 5.10.1 of [IKEv2] ] 
    
    
   INTERNAL-ADDRESS-FAILURE                 36 
    
      Indicates an error assigning an internal address (i.e., 
      INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the 
      processing of a Configuration Payload by a Responder.  If this 
      error is generated within an IKE_SA_AUTH exchange no Child-SA 
      will be created. 
    
    
5. Implementation Notes 
    
****[ This section and its subsections should be placed in an appendix 
to [IKEv2] ]  
    
   The following descriptions detail how to perform specific functions 
   using the configuration payload.  Other functions are possible and 
   thus this list is not a complete list of all of the possibilities.  
   While other functions are possible, the functions listed below MUST 
   be performed as detailed in this document to preserve 
   interoperability among different vendor's implementations. 
    
    
5.1. Requesting an Internal Address 
    
   This function provides address allocation to an IRAC trying to 
   tunnel into a network protected by an IRAS.  Since the IKE_SA_AUTH 
   exchange creates an IKE-SA and a Child-SA the IRAC MUST request the 
   internal address, and optionally other information concerning the 
   internal network, in the IKE_SA_AUTH exchange.  The may IRAS procure 
  
Dukes                                                                8 

                     IKEv2 Configuration Payload        December 2002 
 
 
   an internal address for the IRAC from any number of sources such as 
   a DHCP/BOOTP server or its own address pool. 
    
    Initiator                           Responder 
   -----------------------------       ------------------------------- 
    HDR, SAi1, KEi, Ni, Nr, 
     SK {IDi, [CERT,] [CERTREQ,] [IDr,] 
     AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> 
    
                              <--       HDR, SK {IDr, [CERT,] AUTH, 
                                         CP(CFG_REPLY), SAr2, TSi, TSr} 
    
   CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 
   (either IPv4 or IPv6) but MAY contain any number of additional 
   attributes the initiator wants returned in the response. 
    
   For example, message from Initiator to Responder: 
   CP(CFG_REQUEST)= 
     INTERNAL_ADDRESS(0.0.0.0) 
     INTERNAL_NETMASK(0.0.0.0) 
     INTERNAL_DNS(0.0.0.0) 
   TSi = (0, 0-65536,0.0.0.0-255.255.255.255) 
   TSr = (0, 0-65536,0.0.0.0-255.255.255.255) 
    
   NOTE: Traffic Selectors are a (protocol, port range, address range) 
    
   message from Responder to Initiator: 
    
   CP(CFG_REPLY)= 
     INTERNAL_ADDRESS(192.168.219.202) 
     INTERNAL_NETMASK(255.255.255.0) 
     INTERNAL_SUBNET(192.168.219.0/255.255.255.0) 
   TSi = (0, 0-65536,192.168.219.202-192.168.219.202) 
   TSr = (0, 0-65536,192.168.219.0-192.168.219.255) 
    
   All returned values will be implementation dependent.  As can be 
   seen in the above example, the IRAS MAY also send other attributes 
   that were not included in CP(CFG_REQUEST) and MAY ignore the non-
   mandatory attributes that it does not support. 
    
    
5.2. Requesting the Peer's Version 
    
   An IKE peer wishing to inquire about the other peer's version 
   information MUST use the method below.  This is an example of a 
   configuration request within an Informational Exchange, after the 
   IKE-SA and first Child-SA have been created. 
    
    Initiator                           Responder 
   -----------------------------       -------------------------- 
   HDR, SK{CP(CFG_REQUEST)}      --> 
                                 <--    HDR, SK{CP(CFG_REPLY)} 
    
  
Dukes                                                                9 

                     IKEv2 Configuration Payload        December 2002 
 
 
   CP(CFG_REQUEST)= 
     APPLICATION_VERSION("") 
    
   CP(CFG_REPLY) 
     APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 
    
6. Enterprise Management Considerations 
    
    
****[ Something similar to this section could be placed in an appendix 
to [IKEv2] as well]  
   The method defined in this document SHOULD NOT be used for wide 
   scale management.  Its main intent is to provide a bootstrap 
   mechanism to exchange information within IPSec from IRAS to IRAC.  
   While it MAY be useful to use such a method to exchange information 
   between some Security Gateways (SGW) or small networks, existing 
   management protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or 
   LDAP [LDAP] should be considered for enterprise management as well 
   as subsequent information exchanges. 
    
    
7. Security Considerations 
    
   This draft defines a payload for the Informational Exchange and MUST 
   be protected by an IKE-SA. 
    
    
8. References 
    
 
   [1]         Bradner, S., "The Internet Standards Process -- Revision 
               3", BCP 9, RFC 2026, October 1996. 
    
   [2]         Bradner, S., "Key words for use in RFCs to Indicate 
               Requirement Levels", BCP 14, RFC 2119, March 1997 
    
   [IKE]       D. Harkins, D. Carrel, "The Internet Key Exchange 
               (IKE)", RFC240 
    
   [IKEv2]     Charlie Kaufman, "Internet Key Exchange(IKEv2) Protocol”  
               draft-ietf-ipsec-ikev2-03.txt 
    
   [DHCP]      R. Droms, "Dynamic Host Configuration Protocol", 
               RFC2131 
    
   [RADIUS]    C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 
               Authentication Dial In User Service (RADIUS)", RFC2138 
    
   [LDAP]      M. Wahl, T. Howes, S. Kille., "Lightweight Directory 
               Access Protocol (v3)", RFC2251 
    
   [ESP]       S. Kent, "IP Encapsulating Security Payload (ESP)", 
               RFC2406 
  
Dukes                                                               10 

                    IKEv2 Configuration Payload        December 2002 


    
   [ADDRIPV6]  Hinden, R., "IP Version 6 Addressing Architecture", 
               RFC 2373, July 1998. 
    
    
. Acknowledgments 
    
   The editor would like to thank Stephane Beaulieu, Dan Harkins, 
   Derrell Piper, and Paul Hauffman. 
    
    
0. Author's Addresses 
    
   Darren Dukes 
   Cisco Systems Co. 
   2000 Innovation Drive 
   Kanata, ON, Canada 
   Phone: 1-613-254-3679 
   Email: ddukes@cisco.com 
    
    
































 
ukes                                                               11 

                    IKEv2 Configuration Payload        December 2002 


    
ull Copyright Statement 

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

































 
ukes                                                               12