[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

IPv6 Operations                                                 F. Baker
Internet-Draft                                             June 17, 2017
Intended status: Best Current Practice
Expires: December 19, 2017


             Requirements for a Zero-Configuration IPv6 CPE
                 draft-baker-v6ops-cpe-autoconfigure-00

Abstract

   This note is a breif exploration of what is required for a CPE to be
   auto-configurable from the perspective on an ISP or other upstream
   network.  It assumes that the CPE may also be IPv4-capable (probably
   using NAPT), but that the requirements for that are well understood
   and need no further specification.

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 December 19, 2017.

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
   (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.



Baker                   Expires December 19, 2017               [Page 1]


Internet-Draft                                                 June 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Operational Requirements  . . . . . . . . . . . . . . . . . .   2
   3.  Expected Behavior . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Prefix Delegation . . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   4
   8.  Human Rights Considerations . . . . . . . . . . . . . . . . .   5
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   5
     10.2.  Informative References . . . . . . . . . . . . . . . . .   5
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   We observe that, in today's offerings, "IPv6-capable" has many
   different meanings.  These often require specific configuration and
   are non-interoperable.

   The objective is to enable a customer to purchase a CPE router from a
   mass market store, or for an ISP to purchase CPE Routers for its
   managed service offering, that implement IPv6 [RFC2460] and can be
   attached to any residential/SOHO network and any ISP or other
   upstream network "as is out of the box", and work correctly.

1.1.  Requirements Language

   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 [RFC2119].

2.  Operational Requirements

   The goal stated in Section 1 requires that downstream, which is to
   say within the home or SOHO , the CPE must presume that there may
   exist systems that will autoconfigure [RFC4862] themselves using
   information in a Router Advertisement [RFC4861], and that there may
   exist systems that require address assignment using DHCPv6 [RFC3315].
   It may offer a DNS service using a provider such as OpenDNS, Google
   Public DNS, Amazon Route 53, or some other such service, or relay the
   address of an ISP-provided DNS server.





Baker                   Expires December 19, 2017               [Page 2]


Internet-Draft                                                 June 2017


   Similarly, the stated goal requires that upstream, the CPE must
   presume that it will be required to solicit and observe a Router
   Advertisement [RFC4861], and

   o  learn an upstream DHCPv6 server address,

   o  either autoconfigure [RFC4862] its upstream address or derive one
      using DHCPv6 [RFC3315],

   o  potentially learn an DNS server address from an RDNSS [RFC4339] or
      from DHCPv6,

   o  and allocate IPv6 /64 prefixes for each of its interior subnets
      using the IPv6 Prefix Options for DHCP [RFC3633].

   Given that, it is in a position to offer IPv6 services in the
   residential/SOHO network depending on the upstream IPv6 capabilities.

3.  Expected Behavior

   As a result, a CPE needs to perform several steps, and come out of
   the box configured to do so.  These include:

   1.  Upon detecting the upstream interface as "up", emit a Router
       Solicitation [RFC4861] on it.

   2.  If it receives a Router Advertisement [RFC4861], verify its
       contents.  These may include:

       *  If the RA contains a valid Prefix Information Option whose
          prefix is available for autoconfiguration, create an address
          in that prefix for that interface as specified in SLAAC
          [RFC4862].

       *  Failing that, use DHCPv6 [RFC3315] to request an address from
          the upstream network.

       *  In that same DHCP request, it MAY request an IA_PD [RFC3633]
          delegation of a set of prefixes as described in Section 4.

   3.  If it has not already done so, the router should request an IA_PD
       [RFC3633] delegation of a set of prefixes as described in
       Section 4.

   4.  Given an upstream interface and a delegation of prefixes to use
       downstream, it should

       *  subdelegate a /64 prefix to each downstream interface



Baker                   Expires December 19, 2017               [Page 3]


Internet-Draft                                                 June 2017


       *  allocate an address to each downstream interface using the
          relevant prefixes

       *  start announcing a periodic RA on each downstream interface.
          This RA should include, in addition to usual information
          elements, the RDNSS [RFC4339].

4.  Prefix Delegation

   When the CPE requests a set of prefixes from its upstream network,
   there are several conditions that may apply:

   o  [RFC4291] and [RFC7421] presume a /64 prefix on each IPv6 subnet.

   o  Each LAN to which the CPE connects may be presumed to require a
      subnet - if not immediately, at some point in the future.

   o  There may be LANs in the residential/SOHO network that are not
      attached to the CPE, but require subdelegation within the network
      using DHCPv6 or HNCP [RFC7788].

   The IA_PD requests a prefix, and indicates its preference for a
   "Length for this prefix in bits".  By nature, this is exponential: if
   a home requires 17 subnets, it will require the prefix to be no
   longer than 59 bits, and therefore technically requesting at least 32
   /64 prefixes.  In fact, some ISPs have stated privately that they
   actually allocate prefix lengths of 56, 60, or 64 (and therefore sets
   of 256, 16, or 1 /64) depending on the CPE's request.

   The CPE should request as many as it thinks it might need, including
   interior sub-delegation if it has an idea of what that may require.

5.  IANA Considerations

   This memo asks the IANA for no new parameters.

6.  Security Considerations

   This note describes the use of existing features, each of which has
   its own Security Considerations, and as such adds no new security
   vulnerabilities.

7.  Privacy Considerations

   This memo calls for no personally identifiable information.  The data
   conveyed may, however, be correlatable with other data that is
   personally identifiable.  Such things are beyond the scope of this
   document.



Baker                   Expires December 19, 2017               [Page 4]


Internet-Draft                                                 June 2017


8.  Human Rights Considerations

   Technologies described in this memo are not necessarily associated
   with a human being, and as such violate no human rights.

9.  Acknowledgements

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

   [RFC4339]  Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
              Information Approaches", RFC 4339, DOI 10.17487/RFC4339,
              February 2006, <http://www.rfc-editor.org/info/rfc4339>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

10.2.  Informative References

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.







Baker                   Expires December 19, 2017               [Page 5]


Internet-Draft                                                 June 2017


   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <http://www.rfc-editor.org/info/rfc4941>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <http://www.rfc-editor.org/info/rfc7217>.

   [RFC7421]  Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
              Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
              Boundary in IPv6 Addressing", RFC 7421,
              DOI 10.17487/RFC7421, January 2015,
              <http://www.rfc-editor.org/info/rfc7421>.

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <http://www.rfc-editor.org/info/rfc7788>.

Appendix A.  Change Log

   Initial Version:  Jun 13 2017

Author's Address

   Fred Baker
   Santa Barbara, California  93117
   USA

   Email: FredBaker.IETF@gmail.com














Baker                   Expires December 19, 2017               [Page 6]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/