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


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.

Table of Contents

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 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 themselves using information in a Router Advertisement, and that there may exist systems that require address assignment using DHCPv6. 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.

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

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 on it.
  2. If it receives a Router Advertisement, verify its contents. These may include:
  3. If it has not already done so, the router should request an IA_PD 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

4. Prefix Delegation

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

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.

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.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998.
[RFC3315] Droms, R., 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.
[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.
[RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, DOI 10.17487/RFC4339, February 2006.
[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.

10.2. Informative References

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006.
[RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007.
[RFC4941] Narten, T., Draves, R. and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007.
[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.
[RFC7421] Carpenter, B., 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.
[RFC7788] Stenberg, M., Barth, S. and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016.

Appendix A. Change Log

Initial Version:
Jun 13 2017

Author's Address

Fred Baker Santa Barbara, California 93117 USA EMail: FredBaker.IETF@gmail.com