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]