One document matched: draft-hain-ipv6-ulac-01.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629-fixed.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY ADDARCH SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3513.xml">
<!ENTITY GLOBAL SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml">
<!ENTITY ICMPv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY IPv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY NTP SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1305.xml">
<!ENTITY RANDOM SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY SHA1 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3174.xml">
<!ENTITY ULA SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY FIPS SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.180-1.1995.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="std" docName="draft-hain-ipv6-ulac-01" ipr="pre5378Trust200902" obsoletes="" updates="" xml:lang="en" submissionType="IETF">
<front>
<title abbrev="IPv6 ULA-C">Centrally Assigned IPv6 Unicast Unique Local Address Prefixes</title>
<author fullname="Tony Hain" initials="T." surname="Hain">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>500 108th Ave NE</street>
<street></street>
<city>Bellevue</city>
<region>WA</region>
<code>98004</code>
<country>USA</country>
</postal>
<phone>+1 425 468-1061</phone>
<email>alh-ietf@tndh.net</email>
</address>
</author>
<author fullname="Robert Hinden" initials="R." surname="Hinden">
<organization>Nokia</organization>
<address>
<postal>
<street>313 Fairchild Drive</street>
<street></street>
<city>Mountain View</city>
<region>Ca</region>
<code>94043</code>
<country>USA</country>
</postal>
<phone>+1 650 625 2400</phone>
<email>bob.hinden@nokia.com</email>
</address>
</author>
<author fullname="Geoff Huston" initials="G." surname="Huston">
<organization>APnic</organization>
<address>
<postal>
<street></street>
<street></street>
<city></city>
<region></region>
<code></code>
<country>AU</country>
</postal>
<phone></phone>
<email>gih@apnic.net</email>
</address>
</author>
<date day="25" month="October" year="2009" />
<abstract>
<t>This document defines Centrally Allocated IPv6 Unique Local address prefixes. These prefixes are globally unique and are intended for local communications, usually within a single network administration. They are not intended to be used in place of Provider Independent (PI) address prefixes available from the Regional Internet Registries (RIR) <ref: http://www.iana.org/numbers/ > , and should not appear in the global routing table for the Internet. </t>
<t>The draft is being discussed on the ipv6@ietf.org list. </t>
</abstract>
<note title="Legal">
<t>This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
<middle>
<section title="Introduction" toc="default">
<t>This document defines the characteristics, technical allocation and registration requirements for Centrally Assigned Local IPv6 addresses in the framework defined in <xref target="ULA" pageno="false" format="default" />. There are organizations looking for address space that is independent of the ranges used for public Internet routing, yet they also need the uniqueness of central allocation which the locally assigned ULA block cannot provide. A stumbling block in earlier attempts at defining the Centrally Allocated portion of the ULA prefix range (ULA-C) was the lack of public policy at the RIR's for organizations to acquire PI address prefixes, so the ULA-C effort was seen as an end-run around the public policy process. As the ability to acquire PI space is now resolved by allocation policy, it is time to resurrect the definition for the lower half of the ULA prefix range. The requirements to register a ULA-C prefix should be much less stringent than the requirements to acquire a PI prefix, but for the sake of policy continuity it makes sense for the RIR's to collectively manage this registry under IANA's authority.<xref target="NUMBERS" pageno="false" format="default" /></t>
<t>In any case, the prefixes defined here are not expected to appear in the routing system for the global Internet. The appropriate use of these prefixes is within a single network administration, or between privately interconnected networks that want to ensure that private communications do not accidentally get routed over the public Internet.</t>
<t>Centrally registered Local IPv6 unicast addresses have the following characteristics:<figure title="" suppress-title="false" align="left" alt="" width="70%" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[- Globally unique prefix.
- Well known designator prefix to allow for easy filtering at
administrative boundaries.
- Allows sites to be combined or privately interconnected without
creating any address conflicts or requiring renumbering of
interfaces.
- Internet Service Provider independent and can be used for
communications inside of a private network where public Internet
connectivity is intermittent or not available.
- If accidentally leaked outside of a private network via routing
or DNS, there is no conflict with any other addresses.
- In practice, applications may treat these addresses like global
scoped addresses.]]>
</artwork></figure></t>
<t> Topics that are general to all Local IPv6 address can be found in the following sections of <xref target="ULA" pageno="false" format="default" />:<figure title="" suppress-title="false" align="left" alt="" width="70%" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[ 3.3 Scope Definition
4.0 Operational Guidelines **
4.1 Routing
4.2 Renumbering and Site Merging
4.3 Site Border Router and Firewall Packet Filtering
4.5 Application and Higher Level Protocol Issues
4.6 Use of Local IPv6 Addresses for Local Communications
4.7 Use of Local IPv6 Addresses with VPNs
6.0 Advantages and Disadvantages]]></artwork></figure> ** Operational guidelines specific to centrally assigned Local IPv6 addresses are in Section 4.0 of this document.</t>
<t>Where the Unique Local Address prefixes defined in <xref target="ULA" pageno="false" format="default" />were probabilistically unique, the major difference between those and the Centrally Allocated local address prefixes defined in this document is that the ULA-C prefixes are registered and verified unique before allocation, with the registrations escrowed to resolve any disputes regarding duplicate allocations.</t>
<t>It is expected that network administrators of larger organizations, or those with business practice or governmental requirements to avoid conflict in future mergers or acquisitions will prefer central allocations, while most small or disconnected organizations will prefer local allocations. It is recommended that network administrations which are planning to use Local IPv6 address prefixes, for extensive inter-site communication over a long period of time, use a Centrally Allocated prefix as there is no possibility of allocation conflicts when interconnecting or merging networks. Individual administrations are free to choose either approach, and in fact may choose both, with a Centrally Allocated prefix for their production networks while using locally allocated prefixes in their experimental or lab networks. </t>
<section anchor="acks" title="Acknowledgements" toc="default">
<t>Robert Hinden and Brian Haberman attempted a version of this specification between 2002 & 2005, followed by another attempt by Geoff Huston and Thomas Narten in 2007. Both of those drafts were significant resources for much of the text used in developing this document, as those included comments from Alan Beard, Alex Zinin, Brian Carpenter, Charlie Perkins, Christian Huitema, Hans Kruse, Harald Alvestrand, Keith Moore, Leslie Daigle, Margaret Wasserman, Pekka Savola, Shannon Behrens, Steve Bellovin, Tim Chown, and Bill Fenner. Additional comments to this document were provided by ...</t>
</section>
</section>
<section title="Terminology" toc="default">
<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" pageno="false" format="default"></xref>
.</t>
</section>
<section title="Centrally Assigned Local IPv6 Unicast Address prefixes" toc="default">
<section title="Format" toc="default">
<t>The Centrally assigned Local IPv6 addresses, based on Unique Local Addresses <xref target="ULA" pageno="false" format="default" />, have the following format:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+-----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+-----------------------------+
Where:
Prefix FC00::/7 prefix to identify Local IPv6 unicast
addresses.
L Set to 1 if the prefix is locally assigned,
Set to 0 if it is centrally assigned.
Global ID 40-bit global identifier used to create a
globally unique prefix.
Subnet ID 16-bit Subnet ID is an identifier of a subnet
within the site.
Interface ID 64-bit Interface ID as defined in [ADDARCH].
]]>
</artwork>
</figure>
<t>NOTE: This document defines the allocation and registration procedure for creating global- IDs for Centrally Allocated local IPv6 address prefixes (L=0 ; FC00::/8). The allocation procedure for locally allocated local IPv6 address prefixes (L=1 ; FD00::/8) is defined in <xref target="ULA" pageno="false" format="default" />.</t>
</section>
<section title="Global ID" toc="default">
<t>The allocation of Global IDs should be pseudo-random <xref target="RANDOM" pageno="false" format="default" />. They MUST NOT be allocated sequentially, or with well known numbers as a vanity prefix, or by locality. This is to ensure that there is not any relationship between allocations and to help clarify that these prefixes are not intended to be routed globally in the public Internet. Specifically, these prefixes are designed to not aggregate between customers of a service provider, but for the sake of internal routing management and subnet alignment with PI or PA prefix, a single organization may be allocated a single aggregated set (single prefix between ::/44 & ::/48), but this ULA-C set is still not routable across the public Internet.</t>
<t>Global IDs should be allocated under a single allocation and registration authority because they are pseudo-random and without any structure. This is easiest to accomplish if there is a single authority, though there may be multiple organizations handling the actual registration of allocations through a common procedure. It also makes sense from a policy consistency perspective for the single authority to be the same as the one for managing public IPv6 prefixes.</t>
<t>The requirements for ULA-C allocation and registrations are:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[- Available to anyone in an unbiased manner.
- Globally Unique.
- When justified, available as a single prefix between /44 - /48.]]></artwork>
</figure>
<t>The allocation and registration authority should permit allocations to be obtained without having any sort of Internet connectivity and must include the ability to make an allocation on a permanent basis, without any need for renewal. The registration authority may covers its costs through registration fees and may also use registration agreements to clearly set forth the terms conditions and liabilities associated with registration of such allocations. The payments and conditions associated with this function should not be unreasonably onerous to the extent that the availability of allocations is impaired.</t>
<t>The allocation and registration authority should include sufficient provisions to mitigate attempts to artificially reduce the number pool through hoarding of prefixes. The actual mechanisms are beyond the scope of this document, but can be accomplished in various ways. These mechanisms should not include onerous provisions that reduce the intent that these allocations should be available to anyone in an unbiased manner, and should not attempt to perform rationing or impose quotas upon individual allocations, but may restrict the allocation of an aggregated set based on demonstrated need to align with other PI or PA allocations.</t>
<t>The registration of centrally assigned ULAs should be available in a public database. This function should support a query of a specific ULA prefix and then return the registrant's provided detail. Information should be provided in a robust fashion, consistent with the current state of similar registration services provided by address and domain name registration authorities. </t>
</section>
<section title="Sample Code for Pseudo-Random Global ID Algorithm" toc="default">
<t>The algorithm described below is essentially the same as that for locally assigned <xref target="ULA" pageno="false" format="default" />, with the L bit set to 0, and the additional step of verifying global uniqueness before allocation.</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[1) Obtain the current time of day in 64-bit NTP format [NTP].
2) Obtain an EUI-64 identifier from the system running this
algorithm. If an EUI-64 does not exist, one can be created from
a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64
cannot be obtained or created, a suitably unique identifier,
local to the node, should be used (system serial number).
3) Concatenate the time of day with the system-specific identifier
creating a key.
4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
the resulting value is 160 bits.
5) Use the least significant 40 bits as the Global ID.
6) Concatenate FC00::/7, the L bit set to 0, and the 40 bit
Global ID to create a centrally assigned Local IPv6 address
prefix.
7) Verify that the computed prefix is not in the escrow. If it is,
discard the value and rerun the algorithm.
]]></artwork>
</figure>
<t>[note: in the case where a prefix shorter than /48 is required, at step 5 zero the low order bits as needed (up to 4 bits), at step 7 verify all of the contained Global IDs are available, then register all of the contained /48 values to the same administrative organization.] </t>
<t>This algorithm will result in a Global ID that is unique, and after verification that it is not already registered it can be used as a centrally assigned local IPv6 address prefix.</t>
</section>
</section>
<section title="Operational Guidelines" toc="default">
<section title="DNS Issues" toc="default">
<t>Given their inherent uniqueness, AAAA and PTR records for centrally assigned local IPv6 addresses may be installed and appear in the global DNS. This may be useful if these addresses are being used for site to site or VPN style applications, or for sites that wish to avoid separate or split-DNS systems for inside and outside traffic. Any operational issues relating to this are beyond the scope of this document.</t>
</section>
<section title="Routing Considerations" toc="default">
<t>Section 4.1 of <xref target="ULA" pageno="false" format="default" />provides operational guidelines that inhibit default routing of local addresses between sites. During the initial attempts at defining the ULA-C space, concerns were raised to the IPv6 working group and to the IETF as a whole that lacking an alternative, sites would attempt to use local address prefixes as globally routed, provider-independent (PI) prefixes. Subsequent policy changes have mitigated these concerns by allowing for PI allocations. This section describes why using local addresses in place of PI prefixes is unadvisable, and why existing RIR mechanisms for acquiring PI prefix blocks should be used instead.</t>
<section title="From the standpoint of the Internet" toc="default">
<t>IPv6 unicast addresses are designed to be routed hierarchically down to physical subnet (link) level and only have to be flat-routed within the physical subnet prefix. Attempting to use IPv6 local address prefixes publicly would result in them being flat-routed over the wide area Internet, and thus a larger routing table. This contravenes the operational assumption that for global public routing, long prefixes will be aggregated into fewer short prefixes to limit the table size and convergence time of the routing protocol. </t>
<t>Collecting all local-use prefixes under one short designator prefix (FC00::/7) simplifies the development and maintenance of bogon route filters. Given that everything registered under the procedures defined in this document are intended for local, non-public use only, it is expected to be common practice for all public service providers to filter any prefixes within the entire ULA range (both centrally registered and locally defined), and remove them from the public global routing table. The alternative would be to enumerate every prefix that should not be publicly routed, and then hope that there are no operational errors that inadvertently allow a private prefix to be propagated publically. </t>
<t>Entities wishing to use IPv6 Provider Independent Addresses (PI
Space) in such larger routing contexts should consult the Regional
Internet Registries policies relating to the allocation of PI Space
[RIR-PI].
</t>
</section>
<section title="From the Standpoint of a local network administrator" toc="default">
<t>The operational guidelines regarding routing of centrally allocated
local addresses is that such address prefixes should be readily
routed within a site or comparable administrative routing domain.</t>
<t>By default, such prefixes should not be announced beyond such a local scope, due to the non-aggregateability of these prefixes within the global routing system and the potential negative impact on the total size of the routing space in large scale Internet environments.</t>
</section>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>The IANA is instructed to designate an allocation authority, based on instructions from the IAB, for centrally assigned Unique Local IPv6 unicast address prefixes. This allocation authority shall comply with the requirements described in Section 3.2 of this document, including in particular allocation on a permanent basis and with sufficient provisions to avoid hoarding of numbers. The IAB MAY instruct IANA to designate itself as the allocation and registration authority, and IANA in turn MAY choose to delegate the day-to-day operational functions to the same organizations that handle publicly routed prefixes to maintain consistency between allocation policies.</t>
<t>The designated allocation authority is required to document how they will meet the requirements described in Section 3.2 of this document in an RFC, which will be shepherd through the IETF by the IAB.</t>
</section>
<section title="Security Considerations" toc="default">
<t>Local IPv6 address prefixes do not provide any inherent security to the nodes that use them. They may be used with filters at site boundaries to keep Local IPv6 traffic inside of the site, but this is no more or less secure than filtering any other type of global IPv6 unicast address prefixes.</t>
<t>They should be filtered by public network operators to ensure that publicly routed prefixes are publicly documented, but beyond accountability there is no security aspect related to propagating the route. On the other hand, the lack of a public routing entry is considered by many to be one layer in a defense-in-depth strategy, so widespread practice of filtering the entire ULA prefix range would automatically provide that layer even for sites that don't implement an explicit filter of their own.</t>
<t>Local IPv6 address prefixes do allow for address-based security mechanisms, including IPSEC, across end to end VPN connections or other private interconnects.</t>
</section>
<section title="IANA Considerations" toc="default">
<t>The IAB is expected to instruct IANA to designate an allocation authority for Centrally Allocated Unique Local IPv6 unicast address prefixes. This allocation authority shall comply with the requirements described in Section 3.2 of this document, including in particular allocation on a permanent basis and with sufficient provisions to avoid hoarding of numbers. The IAB MAY instruct IANA to designate itself as the allocation and registration authority, and IANA in turn MAY choose to delegate the day-to-day operational functions to the same organizations that handle publicly routed prefixes to maintain consistency between allocation policies.</t>
<t>The designated allocation authority is required to document how they will meet the requirements described in Section 3.2 of this document in an RFC, which will be shepherd through the IETF by the IAB.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RANDOM">
<front>
<title>Randomness Requirements for Security</title>
<author initials="D." surname="Eastlake" fullname="D. Eastlake">
<organization />
</author>
<author initials="J." surname="Schiller" fullname="J. Schiller">
<organization />
</author>
<author initials="S." surname="Crocker" fullname="S. Crocker">
<organization />
</author>
<date year="2005" month="June" />
<abstract>
<t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t><t> Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106" />
<seriesInfo name="RFC" value="4086" />
<format type="TXT" octets="114321" target="ftp://ftp.isi.edu/in-notes/rfc4086.txt" />
</reference>
<reference anchor="SHA1">
<front>
<title>US Secure Hash Algorithm 1 (SHA1)</title>
<author initials="D." surname="Eastlake" fullname="D. Eastlake">
<organization />
</author>
<author initials="P." surname="Jones" fullname="P. Jones">
<organization />
</author>
<date year="2001" month="September" />
<abstract>
<t>The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3174" />
<format type="TXT" octets="35525" target="ftp://ftp.isi.edu/in-notes/rfc3174.txt" />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott 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>sob@harvard.edu</email>
</address>
</author>
<date year="1997" month="March" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list><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.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" />
<format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" />
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" />
</reference>
<reference anchor="ADDARCH">
<front>
<title>Internet Protocol Version 6 (IPv6) Addressing Architecture</title>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization />
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization />
</author>
<date year="2003" month="April" />
<abstract>
<t>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3513" />
<format type="TXT" octets="53920" target="ftp://ftp.isi.edu/in-notes/rfc3513.txt" />
</reference>
<reference anchor="GLOBAL">
<front>
<title>IPv6 Global Unicast Address Format</title>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization />
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization />
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization />
</author>
<date year="2003" month="August" />
<abstract>
<t>This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3587" />
<format type="TXT" octets="8783" target="ftp://ftp.isi.edu/in-notes/rfc3587.txt" />
</reference>
<reference anchor="NTP">
<front>
<title>Network Time Protocol (Version 3) Specification, Implementation</title>
<author initials="D." surname="Mills" fullname="David L. Mills">
<organization>University of Delaware, Electrical Engineering Department</organization>
<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19716</code>
<country>US</country>
</postal>
<phone>+1 302 451 8247</phone>
<email>mills@udel.edu</email>
</address>
</author>
<date year="1992" month="March" />
<abstract>
<t>This document describes the Network Time Protocol (NTP), specifies its normal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self-organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1305" />
<format type="TXT" octets="307085" target="ftp://ftp.isi.edu/in-notes/rfc1305.txt" />
<format type="PDF" octets="442493" target="ftp://ftp.isi.edu/in-notes/rfc1305.pdf" />
</reference>
<reference anchor="IPv6">
<front>
<title abbrev="IPv6 Specification">Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials="S.E." surname="Deering" fullname="Stephen E. Deering">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<region>CA</region>
<code>95134-1706</code>
<country>USA</country>
</postal>
<phone>+1 408 527 8213</phone>
<facsimile>+1 408 527 8254</facsimile>
<email>deering@cisco.com</email>
</address>
</author>
<author initials="R.M." surname="Hinden" fullname="Robert M. Hinden">
<organization>Nokia</organization>
<address>
<postal>
<street>232 Java Drive</street>
<street>Sunnyvale</street>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<phone>+1 408 990 2004</phone>
<facsimile>+1 408 743 5677</facsimile>
<email>hinden@iprg.nokia.com</email>
</address>
</author>
<date year="1998" month="December" />
<area>Internet</area>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
<abstract>
<t>
This document specifies version 6 of the Internet Protocol (IPv6),
also sometimes referred to as IP Next Generation or IPng.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2460" />
<format type="TXT" octets="85490" target="ftp://ftp.isi.edu/in-notes/rfc2460.txt" />
<format type="HTML" octets="99496" target="http://xml.resource.org/public/rfc/html/rfc2460.html" />
<format type="XML" octets="93343" target="http://xml.resource.org/public/rfc/xml/rfc2460.xml" />
</reference>
<reference anchor="ICMPv6">
<front>
<title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
<author initials="A." surname="Conta" fullname="A. Conta">
<organization />
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization />
</author>
<author initials="M." surname="Gupta" fullname="M. Gupta">
<organization />
</author>
<date year="2006" month="March" />
<abstract>
<t>This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4443" />
<format type="TXT" octets="48969" target="ftp://ftp.isi.edu/in-notes/rfc4443.txt" />
</reference>
<reference anchor="ULA">
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization />
</author>
<author initials="B." surname="Haberman" fullname="B. Haberman">
<organization />
</author>
<date year="2005" month="October" />
<abstract>
<t>This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4193" />
<format type="TXT" octets="35908" target="ftp://ftp.isi.edu/in-notes/rfc4193.txt" />
</reference>
<reference anchor="FIPS" target="http://www.itl.nist.gov/fipspubs/fip180-1.htm">
<front>
<title>Secure Hash Standard</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="April" year="1995" />
</front>
<seriesInfo name="FIPS" value="PUB 180-1" />
</reference>
</references>
<references title="Informative References">
<reference anchor="NUMBERS" target="http://www.iana.org/numbers/">
<front>
<title>IANA Numbers Authority</title>
<author>
<organization />
<address />
</author>
<date month="" year="" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 10:57:50 |