Host address availability recommendations
draft-ietf-v6ops-host-addr-availability-04

The information below is for an old version of the document
Document Type Active Internet-Draft (v6ops WG)
Last updated 2016-01-03
Replaces draft-colitti-v6ops-host-addr-availability
Stream IETF
Intended RFC status Best Current Practice
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd Fred Baker
Shepherd write-up Show (last changed 2015-12-10)
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org
IPv6 Operations                                               L. Colitti
Internet-Draft                                                   V. Cerf
Intended status: Best Current Practice                            Google
Expires: July 6, 2016                                        S. Cheshire
                                                             D. Schinazi
                                                              Apple Inc.
                                                         January 3, 2016

               Host address availability recommendations
               draft-ietf-v6ops-host-addr-availability-04

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 6, 2016.

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

Colitti, et al.           Expires July 6, 2016                  [Page 1]
Internet-Draft  Host address availability recommendations   January 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

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  . . . . . . . . . . . . . . . .   7
   8.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Operational considerations  . . . . . . . . . . . . . . . . .   8
     9.1.  Stateful addressing and host tracking . . . . . . . . . .   8
     9.2.  Address space management  . . . . . . . . . . . . . . . .   9
     9.3.  Addressing link layer scalability issues via IP routing .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     13.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

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 areas it can lead
   to carrying over IPv4 practices that are not appropriate in IPv6 due
   to significant 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, each link has a
   virtually unlimited amount of address space [RFC7421].  Thus, unlike
   IPv4, IPv6 networks are not forced by address availability
   considerations to provide only one address per host.  On the other
   hand, providing multiple addresses has many benefits including
   application functionality and simplicity, privacy, future
   applications, and the ability to deploy the Internet without the use
Show full document text