One document matched: draft-ietf-hokey-ldn-discovery-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3118 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc3748 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc5296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
<!ENTITY rfc5295 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml">
]>
<?rfc strict="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc editing="no"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc rfcprocack="no"?>
<?rfc tocindent="yes"?>
<rfc category="std" docName="draft-ietf-hokey-ldn-discovery-01"
ipr="trust200902">
<front>
<title>The Local Domain Name DHCP Option</title>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>77/440 Soi Phoomjit, Rama IV Road</street>
<street>Phra Khanong, Khlong Toie</street>
<city>Bangkok</city>
<code>10110</code>
<country>Thailand</country>
</postal>
<phone>+66 (0) 87 502 4274</phone>
<email>gwz@net-zen.net</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization abbrev="Huawei">Huawei Technologies Co.,
Ltd.</organization>
<address>
<postal>
<street>Site B, Floor 12, Huihong Mansion, No.91 Baixia Rd.</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>21001</code>
<country>China</country>
</postal>
<phone>+86-25-84565892</phone>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Yungui Wang" initials="Y." surname="Wang">
<organization abbrev="Huawei">Huawei Technologies Co.,
Ltd.</organization>
<address>
<postal>
<street>Site B, Floor 10, HuiHong Mansion, No.91 BaiXia Rd.</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210001</code>
<country>P.R. China</country>
</postal>
<phone>+86 25 84565893</phone>
<email>w52006@huawei.com</email>
</address>
</author>
<date year="2010" />
<abstract>
<t>In order to derive a Domain-Specific Root Key (DSRK) from the
Extended Master Session Key (EMSK) generated as a side-effect of an
Extensible Authentication Protocol (EAP) method, the EAP peer must
discover the name of the domain to which it is attached. <vspace
blankLines="1" /> This document specifies a Dynamic Host Configuration
Protocol (DHCP) option designed to allow a DHCP server to inform clients
of the name of the local domain..</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The EAP Re-authentication Protocol (ERP) <xref
target="RFC5296"></xref> is designed to allow faster re-authentication
of a mobile device which was previously authenticated by means of the
Extensible Authentication Protocol (EAP, <xref target="RFC3748"></xref>.
Given that the local root key (e.g., DSRK <xref
target="RFC5295">RFC 5295</xref>) is generated using the local domain name
(LDN), LDN discovery is an important part of re-authentication. As
described in <xref target="RFC5296">RFC 5296</xref>, the local domain
name can be learned by the mobile device through the ERP exchange or via
a lower-layer mechanism. However, no lower-layer mechanisms for LDN
discovery have yet been defined. <vspace blankLines="1" /> This document
specifies an extension to DHCP for local domain name discovery.</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Option Format">
<t>In DHCPv6-based local domain name discovery, the LDN option is used
by the DHCPv6 client (MD) to obtain the local domain name from the DHCP
Server after full EAP authentication has taken place.</t>
<section title="DHCPv6 Local Domain Name Option">
<t>The format of this option is: <figure anchor="LDN-OPT">
<artwork>
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure> <list style="hanging">
<t hangText="option code">OPTION_LOCAL_DOMAIN_NAME (TBD)</t>
<t hangText="option-length">Length of the ‘local domain name’
field in octets</t>
<t hangText="local-domain-name">This field contains the name of
the local domain and MUST be encoded as specified in Section "8 of
<xref target="RFC3315">RFC 3315</xref></t>
</list></t>
</section>
</section>
<section title="Appearance of the Option">
<t>The LDN option MUST NOT appear in DHCPv6 messages other than the
types Solicit, Advertise, Request, Information-Request and Reply. The
option-code of the LDN option MAY be included in the Option Request
Option in the DHCPv6 message types Solicit, Request and
Information-Request.</t>
</section>
<section title="Client Behavior">
<t>If a DHCPv6 client (MD) doesn't know the local domain name and
requires the 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 RFC 3315 <xref
target="RFC3315"></xref>.</t>
<t>When the DHCPv6 client recieves a LDN option with the local domain name
present in it, it MUST verify that the option length is no more than 256
octets (the maximum length of a single FQDN allowed by DNS), and that
the local domain name is a properly encoded single FQDN, as specified in
Section 8 "Representation and Use of Domain Names" of the RFC3315 <xref
target="RFC3315"></xref>.</t>
</section>
<section title="Relay Agent Behavior">
<t>If a DHCPv6 relay agent has pre-existing knowledge of the local
domain name (for example, from a previous AAA exchange), it SHOULD
include it in the DHCPv6 LDN option and forward to the DHPv6 server.</t>
</section>
<section title="Server Behavior">
<t>If the option code for the LDN option is included in an Option
Request option, the server SHOULD return the DHCPv6 LDN option to the
client. If a DHCPv6 LDN option is received from a relay agent with a
non-empty local-domain-name field, the server SHOULD extract this option
and include it in the reply message.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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 <xref
target="RFC3118"></xref> can be used.</t>
</section>
<section title="IANA considerations">
<t>IANA is requested to allocate one DHCPv6 Option code, referencing
this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5296;
&rfc5295;
&rfc3315;
</references>
<references title="Informative References">
&rfc3118;
&rfc3748;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:48:02 |