One document matched: draft-ponomarev-hip-dns-locators-00.xml

<?xml version='1.0'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<rfc ipr="trust200902" category="exp">
<front>
<title abbrev="Locators in HIP RR">Storing Host Locators in HIP 
Resource Record</title>

<author initials='O.' surname='Ponomarev' fullname='Oleg Ponomarev'>
<organization>Helsinki Institute for Information Technology</organization>
<address>
<postal>
<street>HIIT, PO Box 9800</street>
<city>TKK</city>
<code>FIN-02015</code>
<country>Finland</country>
</postal>
<email>oleg.ponomarev@hiit.fi</email>
</address>
</author>

<date day='6' month='July' year='2009' />

<area>Host Identity Protocol</area>
<workgroup>Host Identity Protocol</workgroup>

<abstract><t>There is a resource record (RR) in the Domain Name System 
(DNS) used for the Host Identity Protocol (HIP). This document proposes 
to store the host locators in the HIP resource records as well.</t></abstract>
</front>

<middle>

<section title='Introduction'>

<t>The HIP RR allows a node to store its Host Identity (HI, the public 
component of the node public-private key pair), Host Identity Tag (HIT, 
a truncated hash of its public key), and the Domain Names of its 
rendezvous servers (RVSs) in the DNS <xref target="RFC5205" />. The host 
may have a set of IP address(es) in A <xref target="RFC1035" /> and AAAA 
<xref target="RFC3596" /> RR sets (RRSets <xref target="RFC2181" 
/>).</t>

<t>However there is no mechanism to specify custom UDP port for incoming 
UDP-encapsulated HIP control packets without using a third party as a 
rendezvous server (RVS)<xref target="RFC5204" />. Furthermore separate 
queries for the set of IP address cause extra delays and additional load 
to the nameservers. The situation can be changed by listing locators in 
HIP RR. The format of extended LOCATOR parameter <xref 
target="I-D.ietf-hip-nat-traversal" /> may be used.</t>

<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 RFC 2119<xref 
target="RFC2119"/>.</t></section>


<section title="IANA Considerations">
<t>This section will be added later on.</t>
</section>

<section anchor="Security" title="Security Considerations">
<t>This section will be added later on.</t>
</section>

</middle>
<back>

<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5205.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3596.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2181.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5204.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hip-nat-traversal-08.xml"?>
</references>

</back>
</rfc>