One document matched: draft-ietf-ecrit-dhc-lost-discovery-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml'>
<!ENTITY RFC3693 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml'>
<!ENTITY I-D.ietf-ecrit-lost PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-lost.xml'>
<!ENTITY RFC5012 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5012.xml'>
<!ENTITY RFC5069 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5069.xml'>
<!ENTITY RFC2131 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
<!ENTITY RFC2132 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'>
<!ENTITY RFC3315 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY RFC3396 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml'>
<!ENTITY RFC1035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY RFC4848 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4848.xml'>
<!ENTITY RFC1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="std" ipr="full3978" docName="draft-ietf-ecrit-dhc-lost-discovery-03.txt">
<front>
<title abbrev="DHCP-based LoST Discovery">A Dynamic Host Configuration Protocol (DHCP) based
Location-to-Service Translation Protocol (LoST) Discovery Procedure</title>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author initials="J." surname="Polk" fullname="James Polk">
<organization abbrev="Cisco">Cisco</organization>
<address>
<postal>
<street>2200 East President George Bush Turnpike</street>
<city>Richardson</city>
<region>Texas</region>
<code>75082</code>
<country>US</country>
</postal>
<email>jmpolk@cisco.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date year="2008"/>
<area>RAI</area>
<workgroup>ECRIT</workgroup>
<abstract>
<t>The Location-to-Service Translation Protocol (LoST) describes an XML-based protocol for
mapping service identifiers and geospatial or civic location information to service contact
Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement
closer to the end host, e.g., in the access network, is desireable. Such a LoST server
placement provides benefits in disaster situations with intermittent network connectivity
regarding the resiliency of emergency service communication. </t>
<t>This document describes how a LoST client can discover a LoST server using the Dynamic Host
Configuration Protocol (DHCP).</t>
</abstract>
</front>
<middle>
<!-- **************************************************************************************** -->
<section title="Introduction">
<t> The Location-to-Service Translation Protocol (LoST) <xref target="I-D.ietf-ecrit-lost"/>
describes an XML-based protocol for mapping service identifiers and geospatial or civic
location information to service contact Uniform Resource Locators (URLs).</t>
<t>In order to interact with a LoST server, the LoST client eventually needs to discover the
server's IP address. Several mechanisms can be used to learn this address, including manual
configuration. In environments where the access network itself either deploys a LoST server
or knows a third party that operates a LoST server, DHCP can provide the end host with a
domain name. This domain name is then used as input to the DNS-based resolution mechanism
described in LoST <xref target="I-D.ietf-ecrit-lost"/> that reuses the URI-enabled NAPTR
specification (see <xref target="RFC4848"/>).</t>
<t>This document specifies a DHCPv4 and a DHCPv6 option that allows LoST clients to discover
local LoST servers.</t>
<t>
<xref target="terms"/> provides terminology. <xref target="encoding"/> shows the encoding of
the domain name. <xref target="dhcpv4"/> describes the DHCPv4 option while <xref
target="dhcpv6"/> describes the DHCPv6 option, with the same functionality. IANA and
Security Considerations complete the document in <xref target="iana"/> and <xref
target="security"/>.</t>
</section>
<!-- **************************************************************************************** -->
<section anchor="terms" title="Terminology">
<t>In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC 2119 <xref target="RFC2119"/>.</t>
<t>Within this document, we use terminology from <xref target="RFC5012"/> and <xref
target="I-D.ietf-ecrit-lost"/>.</t>
</section>
<!-- **************************************************************************************** -->
<section anchor="encoding" title="Domain Name Encoding">
<t>This section describes the encoding of the domain name used in the DHCPv4 option shown in
<xref target="dhcpv4"/> and also used in the DHCPv6 option shown in <xref target="dhcpv6"
/>.</t>
<t>The domain name is encoded according to Section 3.1 of RFC 1035 <xref target="RFC1035"/>
whereby each label is represented as a one octet length field followed by that number of
octets. Since every domain name ends with the null label of the root, a domain name is
terminated by a length byte of zero. The high order two bits of every length octet MUST be
zero, and the remaining six bits of the length field limit the label to 63 octets or less.
To simplify implementations, the total length of a domain name (i.e., label octets and label
length octets) is restricted to 255 octets or less.</t>
</section>
<!-- **************************************************************************************** -->
<section anchor="dhcpv4" title="LoST Server DHCPv4 Option">
<t> The LoST server DHCPv4 option carries a DNS (RFC 1035 <xref target="RFC1035"/>)
fully-qualified domain name to be used by the LoST client to locate a LoST server. </t>
<t> The DHCP option for this encoding has the following format: <figure
anchor="DHCPv4-FQDN-Option" title="LoST FQDN DHCPv4 Option">
<artwork><![CDATA[
Code Len LoST Server Domain Name
+-----+-----+-----+-----+-----+-----+-----+----
| TBD1| n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+----
]]></artwork>
</figure>
</t>
<t>The values s1, s2, s3, etc. represent the domain name labels in the domain name encoding.
Note that the length field in the DHCPv4 option represents the length of the entire domain
name encoding, whereas the length fields in the domain name encoding (see <xref
target="encoding"/>) is the length of a single domain name label. </t>
<t>
<figure>
<artwork><![CDATA[
Code: OPTION_V4_LOST (TBD1)
Len: Length of the 'LoST Server Domain Name' field
in octets; variable.
LoST server Domain Name: The domain name of the LoST
server for the client to use.
]]></artwork>
</figure>
</t>
<t> A DHCPv4 client MAY request a LoST server domain name in an Parameter Request List option,
as described in <xref target="RFC2131"/>.</t>
<t>The encoding of the domain name is described in <xref target="encoding"/>.</t>
<t> This option contains a single doamin name, and as such MUST contain precisely one root
label.</t>
</section>
<!-- **************************************************************************************** -->
<section anchor="dhcpv6" title="LoST Server DHCPv6 Option">
<t>This section defines a DHCPv6 option to carry a domain name. </t>
<t>The DHCPv6 option has the format shown in <xref target="DHCPv6-FQDN-Option"/>. <figure
anchor="DHCPv6-FQDN-Option" title="DHCPv6 Option for LoST Server Domain Name List">
<artwork><![CDATA[
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_V6_LOST | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LoST Server Domain Name |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
<figure>
<artwork><![CDATA[
option-code: OPTION_V6_LOST (TBD2)
option-length: Length of the 'LoST Server Domain Name' field
in octets; variable.
LoST server Domain Name: The domain name of the LoST
server for the client to use.
]]></artwork>
</figure>
</t>
<t> A DHCPv6 client MAY request a LoST server domain name in an Options Request Option (ORO),
as described in <xref target="RFC3315"/>.</t>
<t>The encoding of the domain name is described in <xref target="encoding"/>.</t>
<t> This option contains a single doamin name, and as such MUST contain precisely one root
label.</t>
</section>
<!-- **************************************************************************************** -->
<section title="Example">
<t>This section shows an example of a DHCPv4 option where the DHCP server wants to offer the
"example.com" domain name to the client as input to the U-NAPTR LoST discovery procedure.
This domain name would be encoded as follows: </t>
<t>
<figure anchor="DHCPv4-FQDN-Option-example" title="Example for a LoST FQDN DHCPv4 Option">
<artwork><![CDATA[
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|TBD1|13 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
</t>
</section>
<!-- **************************************************************************************** -->
<section anchor="iana" title="IANA Considerations">
<section title="IANA Consideration for DHCPv4 Option">
<t> The following DHCPv4 option code for the Location-to-Service Translation Protocol (LoST)
server option must be assigned by IANA:</t>
<t>
<figure>
<artwork><![CDATA[
Option Name Value Described in
-----------------------------------------------
OPTION_V4_LOST TBD1 Section 4
]]></artwork>
</figure>
</t>
</section>
<section title="IANA Consideration for DHCPv6 Option">
<t>IANA is requested to assign the following DHCPv6 option codes for the Location-to-Service
Translation Protocol (LoST) options: </t>
<t>
<figure>
<artwork><![CDATA[
Option Name Value Described in
------------------------------------------------
OPTION_V6_LOST TBD2 Section 5
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- **************************************************************************************** -->
<section anchor="security" title="Security Considerations">
<t>If an adversary manages to modify the response from a DHCP server or insert its own
response, a LoST client could be led to contact a rogue LoST server under the control of the
adversary or be given an invalid address. These threats are documented in <xref
target="RFC5069"/>. The security considerations in <xref target="RFC2131"/>, <xref
target="RFC2132"/> and <xref target="RFC3315"/> are applicable to this document. </t>
<t>With respect to the LoST security mechanisms please refer to <xref
target="I-D.ietf-ecrit-lost"/>.</t>
</section>
<!-- **************************************************************************************** -->
<section title="Acknowledgements">
<t>The authors would like to thank Andrew Newton and Leslie Daigle for their draft review and
Andy for the proposed simplifications. </t>
<t>Mark Stapp and David W. Hankins did the document review for the DHC working group as part
of the joint working group last call.</t>
<t>We would like to thank Vijay K. Gurbani for the Gen-ART review. Furthermore, we would like
to thank Russ Housley, Tim Polk, Jari Arkko, and Christian Vogt. </t>
</section>
<!-- **************************************************************************************** -->
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>-</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
</reference> &RFC2131; &RFC2132; &RFC1034; &RFC3315; &RFC1035;
&RFC3396; </references>
<references title="Informative References"> &RFC5012; &RFC5069;
&I-D.ietf-ecrit-lost; &RFC4848; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 06:57:25 |