Internet DRAFT - draft-lemon-smear64
draft-lemon-smear64
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.
Lemon Expires October 16, 2017 [Page 1]
Internet-Draft Smear64 April 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative References . . . . . . . . . . . . . . . . . . . . 3
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
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:
o Advertise the /64 on every link and provide a means for preventing
duplicate addresses across links, and a means for routing between
hosts on the same prefix but on different links.
o Number the local network with a ULA and use NAT66 to provide
addressing.
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:
Generate and maintain a ULA for the CP network.
Provide a means for allocating prefixes for each link on the CP
network.
Discover devices that wish to communicate externally by noticing
packets from those devices routed to global addresses.
Maintain a table of such devices, mapping between ULAs and
addresses allocated from the ISP-provided /64.
Maintain an in-kernel translator on the router to translate
between ULAs and GUAs.
To solve the problem of sharing a /64 across multiple links, the
following need to be done:
Announce the shared /64 on all links, with the L bit (See section
4.6.2 of [RFC4861]) clear.
Each link has a single router responsible for advertising the
shared /64 on that link, so that if two routers are connected to
the same link, only one announces the prefix. That router will
also be responsible for detecting nodes using addresses on the /64
Lemon Expires October 16, 2017 [Page 2]
Internet-Draft Smear64 April 2017
on that link, and maintaining state in the global neighbor table
for that link.
Every router must listen for router solicitation messages. When a
router solicitation message comes from an address on the
advertised /64 that has not been seen before, that address, and
the link on which it was received, is recorded in a global
neighbor table, which is quickly propagated amongs all routers on
the CP network.
Every router must listen for neighbor solicitation messages. When
a neighbor solicitation message is received for an address which
appears in the global neighbor table, the router checks to see if
the two addresses are on the same link. If they are not, the
router responds to the neighbor solicitation message.
In addition, when a neighbor solicitation comes from a source
address on the shared /64 that is not in the global neighbor
table, it is added to the global neighbor table.
Addresses in the global neighbor table are maintained as described
in section 7.3 of [RFC4861]. Unreachability detection is
performed by the router responsible for doing unreachability
detection on the link to which the node had been communicating.
When a router receives a message with a destination address on the
shared /64, it consults the global neighbor table to deliver it.
If the source and destination addresses are on the same link, the
router sends a redirect to the source of the message, as well as
[instead of?] forwarding it.
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, <http://www.rfc-editor.org/info/rfc7788>.
[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>.
Lemon Expires October 16, 2017 [Page 3]
Internet-Draft Smear64 April 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>.
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
Lemon Expires October 16, 2017 [Page 4]
