Host Address Availability Recommendations
RFC 7934

Document Type RFC - Best Current Practice (July 2016; Errata)
Also known as BCP 204
Last updated 2016-09-20
Replaces draft-colitti-v6ops-host-addr-availability
Stream IETF
Formats plain text pdf html bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Fred Baker
Shepherd write-up Show (last changed 2016-02-15)
IESG IESG state RFC 7934 (Best Current Practice)
Consensus Boilerplate Yes
Telechat date
Responsible AD Joel Jaeggli
Send notices to draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org
IANA IANA review state Version Changed - Review Needed
IANA action state No IC
Internet Engineering Task Force (IETF)                        L. Colitti
Request for Comments: 7934                                       V. Cerf
BCP: 204                                                          Google
Category: Best Current Practice                              S. Cheshire
ISSN: 2070-1721                                              D. Schinazi
                                                              Apple Inc.
                                                               July 2016

               Host Address Availability Recommendations

Abstract

   This document recommends that networks provide general-purpose end
   hosts with multiple global IPv6 addresses when they attach, and it
   describes the benefits of and the options for doing so.

Status of This Memo

   This memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7934.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Colitti, et al.           Best Current Practice                 [Page 1]
RFC 7934        Host Address Availability Recommendations      July 2016

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Common IPv6 Deployment Model  . . . . . . . . . . . . . . . .   3
   3.  Benefits of Providing Multiple Addresses  . . . . . . . . . .   3
   4.  Problems with Restricting the Number of Addresses per Host  .   4
   5.  Overcoming Limits Using Network Address Translation . . . . .   5
   6.  Options for Providing More Than One Address . . . . . . . . .   6
   7.  Number of Addresses Required  . . . . . . . . . . . . . . . .   8
   8.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
     9.1.  Host Tracking . . . . . . . . . . . . . . . . . . . . . .   9
     9.2.  Address Space Management  . . . . . . . . . . . . . . . .  10
     9.3.  Addressing Link-Layer Scalability Issues via IP Routing .  10
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   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 design and
   operational areas, it can lead to carrying over IPv4 practices that
   are limiting or not appropriate in IPv6 due to differences between
   the protocols.

   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, a single link provides
   over four billion times more address space than the whole IPv4
   Internet [RFC7421].  Thus, unlike IPv4, IPv6 networks are not forced
   by address scarcity concerns to provide only one address per host.
   Furthermore, providing multiple addresses has many benefits,
   including application functionality and simplicity, privacy, and
   flexibility to accommodate future applications.  Another significant
   benefit is the ability to provide Internet access without the use of
   Network Address Translation (NAT).  Providing only one IPv6 address
   per host negates these benefits.
Show full document text