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

Versions: 00 01

Network Working Group                                 A.K. Vijayabhaskar
Internet-Draft                                           Hewlett-Packard
Expires: Sep 14, 2003                                        14 Mar 2003


                 Client Preferred Prefix option for DHCPv6
               draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt

Status of this Memo

   This document is an  Internet-Draft  and is in full  conformance with
   all provisions of Section 10 of RFC2026.

   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 September 14, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes the Client Preferred Prefix option by which
   the client can specify its preferred prefixes on which the addresses
   need to be allocated by the server.

1. Introduction

   Scenario 1: The client's link has multiple prefixes of different
   scopes and the administrator policy on the server insists that the
   addresses need to be allocated on site-local prefixes only. The
   client will not be able to communicate with a node that belongs to a
   different site, as the server allocates only site-local addresses in
   IAs.







Vijayabhaskar A K           Expires September 14, 2003          [Page 1]


Internet-Draft    Client Preferred Prefix option for DHCPv6     Mar 2003

   Scenario 2: The client's link has two prefixes: site-local and global.
   The administrator policy insists that addresses need to be allocated
   on both the prefixes. All the nodes on a link will not communicate
   with external sites and thus all of them do not require global
   addresses. However, the server allocates addresses on both the
   prefixes. So, the client needs to send the release message to release
   the unwanted addresses, which requires extra transactions.

   Scenario 3: The node has used the stateless autoconf and learned
   about prefixes. Say, the link has two prefixes 3ffe::/64 and
   3fff::/64 and the link has been subnetted to two sets with these
   prefixes. Now, suddenly the RAs say to use stateful autoconf. It
   depends up on the dhcpv6 configuration whether the node will get both
   the prefixes or not. It will be worser if the node using 3ffe::/64
   has to renumber to 3fff::/64 unnecessarily, though both the prefixes
   are valid in the link.

   Scenario 4: In a highly secured environment where there is only a
   known IPv6 prefix by specific entities provided the knowledge of that
   prefix out of band not over a network. The entity will request this
   prefix as a DHCPv6 client and will provide secret security parameter
   to the DHCPv6 server. The server then provides a complete address for
   that prefix.  The entity client now can use that address for
   communications with nodes that accept no other prefix on the network.
   The applications for this are special operations for entities like
   the Military, Law Enforcement, Fire Departments, and Doctors.

   To overcome the problems described in the above Scenarios, the client
   can specify its preferred prefixes to the server using Client
   Preferred Prefix option.

2.  Requirements

   The keywords  MUST, MUST NOT,  REQUIRED,  SHALL,  SHALL NOT,  SHOULD,
   SHOULD NOT,  RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [2]

3. Terminology

   This document uses terminology specific to IPv6 and DHCPv6 as defined
   in section "Terminology" of the DHCP specification.

4. Client Preferred Prefix option

   Client Preferred Prefix option is used by the client to specify its
   preferred prefixes to the server.











Vijayabhaskar A K           Expires September 14, 2003          [Page 2]


Internet-Draft    Client Preferred Prefix option for DHCPv6     Mar 2003

   The format of the Client Preferred Prefix option is as shown below:

    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_CLIENT_PREF_PREFIX   |             option-len        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    prefix-len   |                                             |
   +-+-+-+-+-+-+-+-+-+                                             |
   |                                                               |
   |                 subnet prefix  (n bytes)                      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    prefix-len   |                                             |
   +-+-+-+-+-+-+-+-+-+                                             |
   |                                                               |
   |                 subnet prefix  (n bytes)                      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                  client-pref-prefix-options                   .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code:   OPTION_CLIENT_PREF_PREFIX (tbd)

   option-len: total length of the prefix-len and subnet prefix lists
                    and its encapsulated options.

   prefix-len: prefix length of the subnet address.

   subnet prefix: 'n' bytes of subnet prefix, where 'n' is minimum
                    number of bytes required to refer 'prefix-len' bits
                    of the prefix.

   client-pref-prefix-options: options associated with Client
                    Preferred Prefix option.

5. Server Behavior

   If the server policy doesn't support client preferred prefix option,
   then it can either send reply with OptionUnsupported in the
   encapsulated error code option in client preferred prefix option or
   allocate addresses based on its original policy. The server behavior
   SHOULD be configurable by the administrator.

   If the server policy supports client preferred prefix option and if
   this option contains one or more prefixes which are not valid for the
   client's link, then, the server MUST send the reply with error code
   NotOnLink.





Vijayabhaskar A K           Expires September 14, 2003          [Page 3]


Internet-Draft    Client Preferred Prefix option for DHCPv6     Mar 2003

   If the server policy supports client preferred prefix option and all
   the prefixes in this option are valid for the client's link, then the
   server MUST allocate addresses only on the prefixes specified in
   client preferred prefix option encapsulated in the IAs.

6. Client Behavior

   If the client has received OptionUnsupported error, it can either
   choose the next server to send request, till the server list gets
   exhausted or it can start the configuration exchange as specified in
   Section 18.1.1 of [1] without the client preferred prefix option.

   If the server list has exhausted then, it MUST start the configuration
   exchange as specified in Section 18.1.1 of [1] without the client
   preferred prefix option.

   If the client has received the addresses with the prefixes that were
   not specified in client preferred prefix option, it can release the
   unwanted addresses.

7. Appearance of these options

   Client Preferred Prefix option MUST occur only in Request and Reply
   messages. This option MUST occur in Reply messages only if it
   encapsulates the Error code option.

   Client Preferred Prefix option MUST occur only as an encapsulated
   option in the IA or IA_TA option.

   Client Preferred Prefix option MUST only have Error code option as the
   encapsulated option.



8. Security Considerations

   Since, this option can occur only in IA or IA_TA option, all the
   IA-relevant security considerations are applicable to this option too.

   To avoid attacks through this option, the DHCP client SHOULD use
   authenticated DHCP (see section "Authentication of DHCP messages"
   in the DHCPv6 specification [1]).

9. IANA Considerations

   IANA is requested to assign an option code to this option from the
   option-code space defined in section "DHCPv6 Options" of the DHCPv6
   specification [1].

10. Normative Reference

   [1]  Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R.
        Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
        (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), November
        2002.


Vijayabhaskar A K           Expires September 14, 2003          [Page 4]


Internet-Draft    Client Preferred Prefix option for DHCPv6     Mar 2003


11. Informative Reference

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

Author's Address

   Vijayabhaskar A K
   Hewlett-Packard ESD-I
   29, Cunningham Road
   Bangalore - 560052
   India

   Phone: +91-80-2053085
   E-Mail: vijayak@india.hp.com









































Vijayabhaskar A K           Expires September 14, 2003          [Page 5]


Internet-Draft    Client Preferred Prefix option for DHCPv6     Mar 2003

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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 languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society. Thanks to Jim Bound for his thorough review
   of the document.

























Vijayabhaskar A K           Expires September 14, 2003          [Page 6]


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