Unique IPv6 Prefix per Host
RFC 8273

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10
• 11
• 12
• 13

Internet Engineering Task Force (IETF)                     J. Brzozowski
Request for Comments: 8273                                 Comcast Cable
Category: Informational                                  G. Van de Velde
ISSN: 2070-1721                                                    Nokia
                                                           December 2017

                      Unique IPv6 Prefix per Host

Abstract

   This document outlines an approach utilizing existing IPv6 protocols
   to allow hosts to be assigned a unique IPv6 prefix (instead of a
   unique IPv6 address from a shared IPv6 prefix).  Benefits of using a
   unique IPv6 prefix over a unique service-provider IPv6 address
   include improved host isolation and enhanced subscriber management on
   shared network segments.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   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).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see 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
   https://www.rfc-editor.org/info/rfc8273.

Copyright Notice

   Copyright (c) 2017 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
   (https://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.

Brzozowski & Van de Velde     Informational                     [Page 1]
RFC 8273               Unique IPv6 Prefix per Host         December 2017

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Motivation and Scope of Applicability . . . . . . . . . . . .   3
   3.  Design Principles . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Assignment of IPv6 Unique Prefixes  . . . . . . . . . . . . .   4
   5.  Best Practices for IPv6 Neighbor Discovery  . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The concepts in this document were originally developed as part of a
   large-scale production deployment of IPv6 support for a provider-
   managed shared-access network service.

   A shared-access network service is a service offering in which a
   particular Layer 2 (L2) access network (e.g., Wi-Fi) is shared and
   used by multiple visiting devices (i.e., subscribers).  Many service
   providers offering shared-access network services have legal
   requirements, or find it good practice, to provide isolation between
   the connected visitor devices to control potential abuse of the
   shared-access network.

   A network implementing a unique IPv6 prefix per host can simply
   ensure that devices cannot send packets to each other except through
   the first-hop router.  This will automatically provide robust
   protection against attacks between devices that rely on link-local
   ICMPv6 packets, such as Duplicate Address Detection (DAD) reply
   spoofing, Neighbor Discovery (ND) cache exhaustion, malicious
   redirects, and rogue Router Advertisements (RAs).  This form of
   protection is much more scalable and robust than alternative
   mechanisms such as DAD proxying, forced forwarding, or ND snooping.

   In this document IPv6 support does not preclude support for IPv4;
   however, the primary objective for this work was to make it so that
   user equipment (UE) were capable of an IPv6-only experience from a
   network operator's perspective.  In the context of this document, UE
   can be 'regular' end-user equipment as well as a server in a data
   center, assuming a shared network (wired or wireless) exists.

   Details of IPv4 support are out of scope for this document.  This
   document will also, in general, outline the requirements that must be
   satisfied by UE to allow for an IPv6-only experience.