Network Working Group T. Lemon
Internet-Draft Nominum, Inc.
Intended status: Standards Track April 14, 2017
Expires: October 16, 2017

The Smear64 Mechanism
draft-lemon-smear64-00

Abstract

This document describes a way of sharing a /64 prefix among multiple links in a leaf network scenario, such as a home network or small office network. This provides a way to provide global addressing to all nodes on such a network, allowing for end-to-end communication without address translation.

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 October 16, 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

The smear64 protocol provides a means for addressing the use case where an ISP provides only a single /64 to a CE router. In this case, if the network behind the router has more than one link, there are only two ways to provide addressing on the local network:

The NAT66 solution feels attractive in this case because it seems simple, but in practice the two solutions are not really very different. The requirements for the NAT66 solution are as follows:

To solve the problem of sharing a /64 across multiple links, the following need to be done:

The difference between these two solutions is that one requires a protocol for maintaining the global neighbor table. This can be done using HNCP [RFC7788]. HNCP can also be used to elect the router responsible for doing node discovery on that link.

2. Normative References

[RFC7788] Stenberg, M., Barth, S. and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016.
[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.
[RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007.

Author's Address

Ted Lemon Nominum, Inc. 800 Bridge Parkway Redwood City, California 94065 United States of America Phone: +1 650 381 6000 EMail: ted.lemon@nominum.com