Internet DRAFT - draft-wang-dhc-ldn-option

draft-wang-dhc-ldn-option



Network Working Group
                                                                Y. Wang
                                                                  Q. Wu
Internet Draft                                                   Huawei
Intended status: Standards Track                           July 6, 2009
Expires: January 2010


                DHCP Option for Local Domain Name Discovery
                     draft-wang-dhc-ldn-option-00.txt


Status of this Memo

    This Internet-Draft is submitted to IETF in full conformance with
    the provisions of BCP 78 and 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 January 6, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.








wang                  Expires January 6, 2010                [Page 1]

Internet-Draft         Local Domain Name Option              July 2009


Abstract

   This document defines the local domain name option for DHCPv4 and
   DHCPv6. This option is used by the Peer (DHCP client) to request
   local domain name described in [RFC5296] which is used to derive the
   local root key, e.g., DSRK defined in [RFC5295].



Table of Contents

   1. Introduction.................................................3
   2. Conventions used in this document............................3
   3. Local Domain Name Option.....................................3
      3.1. DHCPv4 Local Domain Name Option.........................3
      3.2. DHCPv4 Local Domain Name Sub-Option.....................4
      3.3. DHCPv6 Local Domain Name Option.........................4
   4. Appearance of the option.....................................5
   5. Client Behavior..............................................5
   6. Relay Agent Behavior.........................................5
   7. Server Behavior..............................................6
   8. Security Considerations......................................6
   9. IANA Considerations..........................................6
   10. References..................................................6
      10.1. Normative References...................................6
      10.2. Informative References.................................7
   11. Acknowledgments.............................................7
   Appendix A. Example of Local Domain Name Discovery..............8




















Wang                  Expires January 6, 2010                [Page 2]

Internet-Draft         Local Domain Name Option              July 2009



1. Introduction

   [RFC5295] defines the domain-specific root keys (DSRK) which can be
   used in the specific domain, e.g., local domain which the peer may be
   attached to. [RFC5296] introduces one re-authentication mechanism in
   which the local root key, e.g., DSRK is used to derive re-
   authentication key to re-authenticate the peer in the local domain
   where the peer is attached. Considering the local root key is
   generated based on the local domain name, the local domain name (LDN)
   discovery is one important part of re-authentication. If the peer
   does not know the local domain name, ERP exchange or lower-layer
   announcement mechanism is required as described in the [RFC5296].
   However lower-layer announcement to obtain the local domain name is
   not specified.

   This document defines a Local Domain Name (Sub-)Option for DHCPv4 and
   DHCPv6. It can be used by the Peer acting as DHCP client to obtain
   the local domain name.

   If a DHCPv4 client involves in the local domain name discovery, then
   the DHCPv4 Local Domain Name Option defined in section 3.1 or 3.2
   should be included.

   If a DHCPv6 client involves in the local domain name discovery, then
   the DHCPv6 Local Domain Name Option defined in section 3.3 should be
   included.

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

3. Local Domain Name Option

   In general, the local domain name discovery is used to request local
   domain name. It happens after network access authentication. An
   example of local domain name discovery is described in Appendix A. In
   the local domain name discovery, the LDN option is used by the client
   (Peer) to obtain the local domain name from DHCP Server.

3.1. DHCPv4 Local Domain Name Option

   The format of the option is:




Wang                  Expires January 6, 2010                [Page 3]

Internet-Draft         Local Domain Name Option              July 2009


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |      Local Domain Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code:     The option code (TBD).

   Length:   The option length, minimum 1 octet.

   Local Domain Name: The local domain name MUST be encoded using the
   technique described in section 3.1 of RFC1035 [RFC1035]. It MUST NOT
   be stored in compressed form, as described in section 4.1.4 of
   RFC1035 [RFC1035].

3.2. DHCPv4 Local Domain Name Sub-Option

   It is a sub-option of the relay-agent-information option [RFC3046].
   The format of the sub-option is:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |      Local Domain Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code:     The option code (TBD).

   Length:   The option length, minimum 1 octet.

   Local Domain Name: The local domain name MUST be encoded using the
   technique described in section 3.1 of RFC1035 [RFC1035]. It MUST NOT
   be stored in compressed form, as described in section 4.1.4 of
   RFC1035 [RFC1035].

3.3. DHCPv6 Local Domain Name Option

   The format of this option is:








Wang                  Expires January 6, 2010                [Page 4]

Internet-Draft         Local Domain Name Option              July 2009


   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_LOCAL_DOMAIN_NAME      |         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             local-domain-name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   option-code: OPTION_LOCAL_DOMAIN_NAME (TBD)

   option-length: Length of the 'local domain name' field in octets

   local-domain-name: The local domain name MUST be encoded as specified
   in section "Representation and use of domain names" of [RFC3315].

4. Appearance of the option

   The DHCPv4 LDN option MUST NOT appear in DHCPv4 messages other than
   the types DHCPOFFER and DHCPACK. Also the option-code of DHCPv4 LDN
   option MAY appear in the Parameter Request List in the DHCPv4 message
   types DHCPDISCOVERY and DHCPREQUEST.

   The DHCPv4 LDN sub-option MUST NOT appear in DHCPv4 messages other
   than the types DHCPDISCOVERY and DHCPREQUEST.

   The DHCPv6 LDN option MUST NOT appear in DHCPv6 messages other than
   the types Solicit, Advertise, Request, Information-Request and Reply.
   Also the option-code of LDN option MAY appear in the Option Request
   Option in the DHCPv6 message types Solicit, Request and Information-
   Request.

5. Client Behavior

   If a DHCPv4 client (Peer) requires DHCP Server to provide the DHCPv4
   LDN option, it MUST include an Parameter Request List, requesting the
   DHCPv4 LDN option, as described in section 9.8 of RFC2132 [RFC2132].

   If a DHCPv6 client (Peer) requires DHCP Server to provide the DHCPv6
   LDN option, it MUST include an Option Request option, requesting the
   DHCPv6 LDN option, as described in section 22.7 of RFC3315 [RFC3315].

6. Relay Agent Behavior

   If a DHCPv4 relay agent retrieves the local domain name from
   authentication server, it SHOULD include it in the DHCPv4 LDN sub-



Wang                  Expires January 6, 2010                [Page 5]

Internet-Draft         Local Domain Name Option              July 2009


   option in a relay-agent-information option [RFC3046] and forward to
   the DHCPv4 server.

   If a DHCPv6 relay agent retrieves the local domain name from
   authentication server, it SHOULD include it in the DHCPv6 LDN option
   and forward to the DHPv6 server.

7. Server Behavior

   If a DHCPv4 LDN option in the Parameter Request List or a DHCPv6 LDN
   option in an ORO has been requested, the server SHOULD return the
   DHCPv4 or DHCPv6 the LDN option to the client. If a DHCPv4 LDN sub-
   option or a DHCPv6 LDN option is included from relay agent, the
   server SHOULD extract the local domain name and encapsulate it in the
   returned LDN option.

8. Security Considerations

    The communication between the DHCP client and the DHCP server for
    the exchange of local domain name information is security sensitive
    and requires authentication, integrity and replay protection. Either
    lower-layer security (such as link layer security established as
    part of the network access authentication protocol run) or DHCP
    security [RFC3118] can be used.

9. IANA Considerations

   Three option codes need to be assigned.

     DHCPv4 LDN Option Code

     DHCPv4 LDN Sub-Option Code

     DHCPv6 LDN Option Code

10. References

10.1. Normative References

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

   [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
             "Specification for the Derivation of Root Keys from an
             Extended Master Session Key (EMSK)", RFC 5295, August 2008.




Wang                  Expires January 6, 2010                [Page 6]

Internet-Draft         Local Domain Name Option              July 2009


   [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
             authentication Protocol (ERP)", RFC 5296, August 2008.

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

   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
             Bucknell University, March 1997.

   [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
             Extensions", RFC 2132, March 1997.

   [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
             RFC 3046, January 2001.

   [RFC1035] Mockapetris, P., "Domain Names -- Implementation and
             Specification", STD 13, RFC 1035, USC/Information Sciences
             Institute, November 1987.

10.2. Informative References

   [RFC1034] Mockapetris, P., "Domain Names -- Concepts and Facilities",
             STD 13, RFC 1034, USC/Information Sciences Institute,
             November 1987.

11. Acknowledgments

   Thanks to DHC and Hokey members for their comments.



















Wang                  Expires January 6, 2010                [Page 7]

Internet-Draft         Local Domain Name Option              July 2009


Appendix A.                Example of Local Domain Name Discovery

   This section introduces a example of local domain name discovery. In
   this example, the AAA client and DHCP Relay agent integrates into the
   same NAS. The local domain name can be assigned by the AAA server,
   e.g., ER server in the hokey re-authentication architecture or
   allocated by the DHCP server. The detailed procedure is shown below.

    +--------------+  +-------------+  +-------------+  +--------------+
    | Client(Peer) |  | Relay Agent |  | DHCP Server |  | AAA Server   |
    |              |  | (AAA Client)|  |             |  |              |
    +------+-------+  +------+------+  +------+------+  +------+-------+
           |                 |                |                |
           |  1. Initial Attachment and Access Authentication  |
           |<--------------->+<---------------+--------------->|
           |                 |                |                |
           |                 | 2. AAA (Local Domain Name)      |
           |                 |<--------------------------------|
           |                 |                |                |
           |  +-----------------------------+ |                |
           |  | 3.Extract Local Domain Name | |                |
           |  +-----------------------------+ |                |
           |                 |                |                |
           |4.DHCP Solicit/Request/Info-Request                |
           |---------------->|                |                |
           |                 |5 DHCP Solicit/Request/Info-Request
           |                 |--------------->|                |
           |                 |                |                |
           |                 |6. DHCP Advertise/Reply/Info-Reply
           |                 |<---------------|                |
           |7.DHCP Advertise/Reply/Info-Reply |                |
           |<----------------|                |                |
           |                 |                |                |


   During step1 ~ step3, the client (Peer) performs initial attachment
   and access authentication with the AAA Server through NAS (relay
   agent). In success case, the AAA Server sends the AAA message with
   the local domain name to NAS (relay agent). NAS (relay agent)
   extracts the local domain name from the AAA message and then stores
   it in the local database.

   During step4 ~ step11, the client (Peer) initiates the DHCP process,
   requesting a LDN option in an ORO in DHCP Solicit/ Request/
   Information-Request message, to DHCP Server. If the local domain name
   is allocated by the AAA server at said step2, the relay agent SHOULD



Wang                  Expires January 6, 2010                [Page 8]

Internet-Draft         Local Domain Name Option              July 2009


   include the local domain name in the LDN option/sub-option of the
   being relayed message, and send it to the DHCP Server.

   The DHCP Server checks if the LDN option code is included in an ORO
   of DHCPv6 message or in the Parameter Request List of DHCPv4 message.
   If included, it MUST return the local domain name with the LDN option
   encapsulated in DHCP message to the client (Peer). If a DHCPv4 LDN
   sub-option or a DHCPv6 LDN option is included by the relay agent,
   i.e., the AAA server allocate the local domain name, the DHCP server
   SHOULD extract the local domain name received from the relay agent
   and encapsulate it in the returned LDN option.



Authors' Addresses

   Yungui Wang
   Huawei Technologies Co.,Ltd.
   Floor 10, HuiHong Mansion, No.91 BaiXia Rd.
   Nanjing, Jiangsu, 210001 P.R.China

   Email: w52006@huawei.com


   Qin Wu
   Huawei Technologies Co.,Ltd.
   Floor 12, HuiHong Mansion, No.91 BaiXia Rd.
   Nanjing, Jiangsu, 210001 P.R.China

   Email: sunseawq@huawei.com


















Wang                  Expires January 6, 2010                [Page 9]