One document matched: draft-ietf-v6ops-host-addr-availability-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2993 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2993.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4389.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4941 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY RFC5902 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5902.xml">
<!ENTITY RFC6434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6434.xml">
<!ENTITY RFC6459 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6459.xml">
<!ENTITY RFC6877 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6877.xml">
<!ENTITY RFC7039 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7039.xml">
<!ENTITY RFC7217 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7217.xml">
<!ENTITY RFC7278 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7278.xml">
<!ENTITY RFC7421 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7421.xml">
<!ENTITY I-D.ietf-dhc-anonymity-profile SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-anonymity-profile.xml">
<!ENTITY I-D.tsvwg-quic-protocol SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.tsvwg-quic-protocol.xml">
<!ENTITY I-D.herbert-nvo3-ila SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.herbert-nvo3-ila.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- For a complete list and description of processing instructions,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents -->
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in table of contents. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these processing instructions as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc ipr="trust200902"
updates=""
obsoletes=""
category="bcp"
docName="draft-ietf-v6ops-host-addr-availability-02">
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>Host address availability recommendations</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Lorenzo Colitti" initials="L." surname="Colitti">
<organization>Google</organization>
<address>
<postal>
<street>Roppongi 6-10-1</street>
<city>Minato</city>
<region>Tokyo</region>
<code>106-6126</code>
<country>JP</country>
</postal>
<phone></phone>
<email>lorenzo@google.com</email>
</address>
</author>
<author fullname="Vint Cerf" initials="V." surname="Cerf">
<organization>Google</organization>
<address>
<postal>
<street>1875 Explorer St</street>
<street>10th Floor</street>
<city>Reston</city>
<region>VA</region>
<code>20190</code>
<country>US</country>
</postal>
<phone></phone>
<email>vint@google.com</email>
</address>
</author>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization>Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>
<phone></phone>
<email>cheshire@apple.com</email>
</address>
</author>
<author fullname="David Schinazi" initials="D." surname="Schinazi">
<organization>Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>
<phone></phone>
<email>dschinazi@apple.com</email>
</address>
</author>
<date/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>IPv6 Operations</workgroup>
<!-- WG name at the upper left corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In most aspects, the IPv6 protocol is very similar to IPv4. This similarity can create a tendency to think of IPv6 as 128-bit IPv4, and thus lead network designers and operators to apply identical configurations and operational practices to both. This is generally a good thing because it eases the transition to IPv6 and the operation of dual-stack networks. However, in some areas it can lead to carrying over IPv4 practices that are not appropriate in IPv6 due to significant differences between the protocols.</t>
<t>One such area is IP addressing, particularly IP addressing of hosts. This is substantially different because unlike IPv4 addresses, IPv6 addresses are not a scarce resource. In IPv6, each link has a virtually unlimited amount of address space <xref target="RFC7421"/>. Thus, unlike IPv4, IPv6 networks are not forced by address availability considerations to assign only one address per host. On the other hand, assigning multiple addresses has many benefits including application functionality and simplicity, privacy, future applications, and the ability to deploy the Internet without the use of NAT. Assigning only one IPv6 address per host negates these benefits.</t>
<t>This document describes the benefits of assigning multiple addresses per host and the problems with not doing so. It recommends that networks provide general-purpose end hosts with multiple global addresses when they attach, and lists current options for doing so.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in
<xref target="RFC2119">"Key words for use in RFCs to Indicate Requirement Levels"</xref>.</t>
</section>
</section>
<section title="Common IPv6 deployment model">
<t>IPv6 is designed to support multiple addresses, including multiple global addresses, per interface (<xref target="RFC4291"/> section 2.1, <xref target="RFC6434"/> section 5.9.4). Today, many general-purpose IPv6 hosts are configured with three or more addresses per interface: a link-local address, a stable address (e.g., using EUI-64 or <xref target="RFC7217">Opaque Interface Identifiers</xref>), one or more privacy addresses <xref target="RFC4941"/>, and possibly one or more temporary or non-temporary addresses assigned using DHCPv6 <xref target="RFC3315"/>.</t>
<t>In most general-purpose IPv6 networks, including all 3GPP networks (<xref target="RFC6459"/> section 5.2) and Ethernet and Wi-Fi networks using SLAAC <xref target="RFC4862"/>, IPv6 hosts have the ability to configure additional IPv6 addresses from the link prefix(es) without explicit requests to the network.</t>
</section>
<section anchor="benefits" title="Benefits of multiple addresses">
<t>Today, there are many host functions that require more than one IP address to be available to the host:</t>
<t><list style="symbols">
<t>Privacy addressing to prevent tracking by off-network hosts <xref target="RFC4941"/>.</t>
<t>Multiple processors inside the same device. For example, in many mobile devices both the application processor and baseband processor need to communicate with the network, particularly for recent technologies like ePDG.</t>
<t>Extending the network (e.g., "tethering").</t>
<t>Running virtual machines on hosts.</t>
<t>Translation-based transition technologies such as 464XLAT <xref target="RFC6877"/> that provide IPv4 over IPv6. Some of these require the availability of a dedicated IPv6 address in order to determine whether inbound packets are translated or native (<xref target="RFC6877"/> section 6.3).</t>
<t>ILA ("Identifier-locator addressing") <xref target="I-D.herbert-nvo3-ila"/>.</t>
<t>Future applications (e.g., per-application IPv6 addresses <xref target="TARP"/>).</t>
</list></t>
<t>Examples of how the availability of multiple addresses per host has already allowed substantial deployment of new applications without explicit requests to the network are:</t>
<t><list style="symbols">
<t>464XLAT. 464XLAT is usually deployed within a particular network, and in this model the operator can ensure that the network is appropriately configured to provide the CLAT with the additional IPv6 address it needs to implement 464XLAT. However, there are deployments where the PLAT (i.e., NAT64) is provided as a service by a different network, without the knowledge or cooperation of the residential ISP (e.g., the IPv6v4 Exchange Service <eref target="http://www.jpix.ad.jp/en/service/ipv6v4.html"/>). This type of deployment is only possible because those residential ISPs provide multiple IP addresses to their users, and thus those users can freely obtain the extra IPv6 address required to run 464XLAT.</t>
<t>/64 sharing <xref target="RFC7278"/>. When the topology supports it, this is a way to provide IPv6 tethering without needing to wait for network operators to deploy DHCPv6 PD, which is only available in 3GPP release 10 (<xref target="RFC6459"/> section 5.3).</t>
</list></t>
</section>
<section title="Problems with assigning a restricted number of addresses per host" anchor="section_problems">
<t>Assigning a restricted number of addresses per host implies that functions that require multiple addresses will either be unavailable (e.g., if the network provides only one IPv6 address per host, or if the host has reached the limit of the number of addresses available), or that the functions will only be available after an explicit request to the network is granted. The necessity of explicit requests has the following drawbacks:</t>
<t><list style="symbols">
<t>Increased latency, because a provisioning operation, and possibly human intervention with an update to the service level agreement, must complete before the functionality is available.</t>
<t>Uncertainty, because it is not known in advance if a particular operation function will be available.</t>
<t>Complexity, because implementations need to deal with failures and somehow present them to the user. Failures may manifest as timeouts, which may be slow and frustrating to users.</t>
<t>Increased load on the network's provisioning servers.</t>
</list></t>
<t>Some operators may desire to configure their networks to limit the number of IPv6 addresses per host. Reasons might include hardware limitations (e.g., TCAM or neighbor cache table size constraints), business models (e.g., a desire to charge the network's users on a per-device basis), or operational consistency with IPv4 (e.g., an IP address management system that only supports one address per host). However, hardware limitations are expected to ease over time, and an attempt to generate additional revenue by charging per device may prove counterproductive if customers respond (as they did with IPv4) by using NAT, which results in no additional revenue, but leads to more operational problems and higher support costs.</t>
</section>
<section title="Overcoming limits using Network Address Translation">
<t>These limits can mostly be overcome by end hosts by using NAT, and indeed in IPv4 most of these functions are provided by using NAT on the host. Thus, the limits could be overcome in IPv6 as well by implementing NAT66 on the host.</t>
<t>Unfortunately NAT has well-known drawbacks. For example, it causes application complexity due to the need to implement NAT traversal. It hinders development of new applications. On mobile devices, it reduces battery life due to the necessity of frequent keepalives, particularly for UDP. Applications using UDP that need to work on most of the Internet are forced to send keepalives at least every 30 seconds <eref target="http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf"/>. For example, the QUIC protocol uses a 15-second keepalive <xref target="I-D.tsvwg-quic-protocol"/>. Other drawbacks of NAT are well known and documented <xref target="RFC2993"/>. While IPv4 NAT is inevitable due to the limited amount of IPv4 space available, that argument does not apply to IPv6. Guidance from the IAB is that deployment of IPv6 NAT is not desirable <xref target="RFC5902"/>.</t>
<t>The desire to overcome the problems listed in <xref target="section_problems" /> without disabling any features has resulted in developers implementing IPv6 NAT. There are fully-stateful address+port NAT66 implementations in client operating systems today: for example, Linux has supported NAT66 since late 2012 <eref target="http://kernelnewbies.org/Linux_3.7#head-103e14959eeb974bbd4e862df8afe7c118ba2beb"/>. A popular software hypervisor also recently implemented NAT66 to work around these issues <eref target="https://communities.vmware.com/docs/DOC-29954"/>. Wide deployment of networks that provide a restricted number of addresses will cause proliferation of NAT66 implementations.</t>
<t>This is not a desirable outcome. It is not desirable for users because they may experience application brittleness. It is likely not desirable for network operators either, as they may suffer higher support costs, and even when the decision to assign only one IPv6 address per device is dictated by the network's business model, there may be little in the way of incremental revenue, because devices can share their IPv6 address with other devices. Finally, it is not desirable for operating system manufacturers and application developers, who will have to build more complexity, lengthening development time and/or reducing the time spent on other features.</t>
<t>Indeed, it could be argued that the main reason for deploying IPv6, instead of continuing to scale the Internet using only IPv4 and large-scale NAT44, is because doing so can provide all the hosts on the planet with end-to-end connectivity that is constrained not by accidental technical limitations, but only by intentional security policies.</t>
</section>
<section title="Options for obtaining more than one address">
<t>Multiple IPv6 addresses can be obtained in the following ways:</t>
<t><list style="symbols">
<t>Using Stateless Address Autoconfiguration <xref target="RFC4862"/>. SLAAC allows hosts to create global IPv6 addresses on demand by simply forming new addresses from the global prefix assigned to the link.</t>
<t>Using stateful DHCPv6 address assignment <xref target="RFC3315"/>. Most DHCPv6 clients only ask for one non-temporary address, but the protocol allows requesting multiple temporary and even multiple non-temporary addresses, and the server could choose to assign the client multiple addresses. It is also technically possible for a client to request additional addresses using a different DUID, though the DHCPv6 specification implies that this is not expected behavior (<xref target="RFC3315"/> section 9). The DHCPv6 server will decide whether to grant or reject the request based on information about the client, including its DUID, MAC address, and so on.</t>
<t>DHCPv6 prefix delegation <xref target="RFC3633"/>. DHCPv6 PD allows the client to request and be delegated a prefix, from which it can autonomously form other addresses. If the prefix is shorter than /64, it can be divided into multiple subnets which can be further delegated to downstream clients. If the prefix is a /64, it can be extended via L2 bridging, ND proxying <xref target="RFC4389"/> or /64 sharing <xref target="RFC7278"/>, but it cannot be further subdivided, as a prefix longer than /64 is outside the current IPv6 specifications <xref target="RFC7421"/>.</t>
</list></t>
<texttable anchor="option_comparison"
title="Comparison of multiple address assignment options">
<ttcol align="left"></ttcol>
<ttcol align="center">SLAAC</ttcol>
<ttcol align="center">DHCPv6 IA_NA / IA_TA</ttcol>
<ttcol align="center">DHCPv6 PD</ttcol>
<ttcol align="center">DHCPv4</ttcol>
<c>Extend network</c>
<c>Yes</c>
<c>No</c>
<c>Yes</c>
<c>Yes (NAT44)</c>
<c>"Unlimited" endpoints</c>
<c>Yes*</c>
<c>Yes*</c>
<c>No</c>
<c>No</c>
<c>Stateful, request-based</c>
<c>No</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>Immune to layer 3 on-link resource exhaustion attacks</c>
<c>No</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<postamble>[*] Subject to network limitations, e.g., ND cache entry size limits.</postamble>
</texttable>
</section>
<section title="Number of addresses required">
<t>If we itemize the use cases from section <xref target="benefits" />, we can estimate the number of addresses currently used in normal operations. In typical implementations, privacy addresses use up to 8 addresses - one per day (<xref target="RFC4941"/> section 3.5). Current mobile devices may typically support 8 clients, with each one requiring one or more addresses. A client might choose to run several virtual machines. Current implementations of 464XLAT require use of a separate address. Some devices require another address for their baseband chip. Even a host performing just a few of these functions simultaneously might need on the order of 20 addresses at the same time. Future applications designed to use an address per application or even per resource will require many more. These will not function on networks that enforce a hard limit on the number of addresses provided to hosts.</t>
</section>
<section title="Recommendations">
<t>In order to avoid the problems described above, and preserve the Internet's ability to support new applications that use more than one IPv6 address, it is RECOMMENDED that IPv6 network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts when they connect to the network. To support future use cases, it is RECOMMENDED to not impose a hard limit on the size of the address pool assigned to a host. If the network requires explicit requests for address space (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses (e.g. 32) would accommodate current clients but sets a limit on the number of addresses available to hosts when they attach and would limit the development of future applications. Assigning prefixes longer than a /64 will limit the flexibility of the host to further assign addresses to any internal functions, virtual machines, or downstream clients that require address space - for example, by not allowing the use of SLAAC.</t>
</section>
<section title="Operational considerations">
<section title="Stateful addressing and host tracking">
<t>Some network operators - often operators of networks that provide services to third parties such as university campus networks - are required to track which IP addresses are assigned to which hosts on their network. Maintaining persistent logs that map user IP addresses and timestamps to hardware identifiers such as MAC addresses may be used to avoid liability for copyright infringement or other illegal activity.</t>
<t>It is worth noting that this requirement can be met without using stateful addressing mechanisms such as DHCPv6. For example, it is possible to maintain these mappings by scraping IPv6 neighbor tables, as routers typically allow periodic dumps of the neighbor cache via SNMP or other means, and many can be configured to log every change to the neighbor cache.</t>
<t>It is also worth noting that without L2 edge port security, hosts are still able to choose their own addresses - DHCPv6 does not offer any enforcement of what addresses a host is allowed to use. Such guarantees can only be provided by link-layer security mechanisms that enforce that particular IPv6 addresses are used by particular link-layer addresses (for example, <xref target="RFC7039">SAVI</xref>). If those mechanisms are available, it is possible to use them to provide tracking. This form of tracking is much more secure and reliable than DHCP server logs because it operates independently of how addresses are allocated. Additionally, attempts to track this sort of information via DHCPv6 are likely to become decreasingly viable due to ongoing efforts to improve the privacy of DHCP <xref target="I-D.ietf-dhc-anonymity-profile"/>.</t>
<t>Thus, host tracking does not necessarily require the use of stateful address assignment mechanisms such as DHCPv6. Indeed, many large enterprise networks, including the enterprise networks of the authors' employers, are fully dual-stack but do not currently use or support DHCPv6. The authors are directly aware of several networks that operate in this way, including Universities of Loughborough, Minnesota, Reading, Southampton, Wisconsin and Imperial College London.</t>
</section>
<section title="Address space management">
<t>In IPv4, all but the world's largest networks can be addressed using private space <xref target="RFC1918"/>, with each host receiving one IPv4 address. Many networks can be numbered in 192.168.0.0/16 which has roughly 64k addresses. In IPv6, that is equivalent to a /48, with each of 64k hosts receiving a /64 prefix. Under current RIR policies, a /48 is easy to obtain for an enterprise network.</t>
<t>Networks that need a bigger block of private space use 10.0.0.0/8, which has roughly 16 million addresses. In IPv6, that is equivalent to a /40, with each host receiving /64 prefix. Enterprises of such size can easily obtain a /40 under current RIR policies.</t>
<t>Currently, residential users typically receive one IPv4 address and a /48, /56 or /60 IPv6 prefix. While such networks do not provide enough space to assign a /64 per host, such networks almost universally use SLAAC, and thus do not pose any particular limit to the number of addresses hosts can use.</t>
<t>Unlike IPv4 where addresses came at a premium, in all these networks, there is enough IPv6 address space to supply clients with multiple IPv6 addresses.</t>
</section>
<section title="Addressing link layer scalability issues via IP routing">
<t>The number of IPv6 addresses on a link has direct impact for networking infrastructure nodes (routers, switches) and other nodes on the link. Setting aside exhaustion attacks via Layer 2 address spoofing, every (Layer 2, IP) address pair impacts networking hardware requirements in terms of memory, MLD snooping, solicited node multicast groups, etc. Many of these costs are incurred by neighboring hosts. Switching to a DHCPv6 PD model means there are only forwarding decisions, with only one routing entry and one ND cache entry per device on the network.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors thank Tore Anderson, Brian Carpenter, Wesley George, Erik Kline, Shucheng (Will) Liu, Dieter Siegmund, Mark Smith, Sander Steffann and James Woodyatt for their input and contributions.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>None so far.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC1918;
&RFC2993;
&RFC3315;
&RFC3633;
&RFC4291;
&RFC4389;
&RFC4862;
&RFC4941;
&RFC5902;
&RFC6434;
&RFC6459;
&RFC6877;
&RFC7039;
&RFC7217;
&RFC7278;
&RFC7421;
&I-D.ietf-dhc-anonymity-profile;
&I-D.tsvwg-quic-protocol;
&I-D.herbert-nvo3-ila;
<reference anchor="TARP" target="">
<front>
<title>Transient Addressing for Related Processes: Improved Firewalling by Using IPv6 and Multiple Addresses per Host</title>
<author initials="PM" surname="Gleitz" fullname="Peter M. Gleitz" />
<author initials="SM" surname="Bellovin" fullname="Steven M. Bellovin" />
<date month="August" year="2001"/>
</front>
</reference>
<!-- A reference written by by an organization not a person.
<reference anchor="DOMINATION"
target="http://www.example.com/dominator.html">
<front>
<title>Ultimate Plan for Taking Over the World</title>
<author>
<organization>Mad, Inc.</organization>
</author>
<date year="1984" />
</front>
</reference>
-->
</references>
<!--
<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 19:30:59 |