idnits 2.17.00 (12 Aug 2021) /tmp/idnits62246/draft-lemon-smear64-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2017) is 1856 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4862' is defined on line 145, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nominum, Inc. 4 Intended status: Standards Track April 14, 2017 5 Expires: October 16, 2017 7 The Smear64 Mechanism 8 draft-lemon-smear64-00 10 Abstract 12 This document describes a way of sharing a /64 prefix among multiple 13 links in a leaf network scenario, such as a home network or small 14 office network. This provides a way to provide global addressing to 15 all nodes on such a network, allowing for end-to-end communication 16 without address translation. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 16, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Normative References . . . . . . . . . . . . . . . . . . . . 3 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1. Introduction 58 The smear64 protocol provides a means for addressing the use case 59 where an ISP provides only a single /64 to a CE router. In this 60 case, if the network behind the router has more than one link, there 61 are only two ways to provide addressing on the local network: 63 o Advertise the /64 on every link and provide a means for preventing 64 duplicate addresses across links, and a means for routing between 65 hosts on the same prefix but on different links. 67 o Number the local network with a ULA and use NAT66 to provide 68 addressing. 70 The NAT66 solution feels attractive in this case because it seems 71 simple, but in practice the two solutions are not really very 72 different. The requirements for the NAT66 solution are as follows: 74 Generate and maintain a ULA for the CP network. 76 Provide a means for allocating prefixes for each link on the CP 77 network. 79 Discover devices that wish to communicate externally by noticing 80 packets from those devices routed to global addresses. 82 Maintain a table of such devices, mapping between ULAs and 83 addresses allocated from the ISP-provided /64. 85 Maintain an in-kernel translator on the router to translate 86 between ULAs and GUAs. 88 To solve the problem of sharing a /64 across multiple links, the 89 following need to be done: 91 Announce the shared /64 on all links, with the L bit (See section 92 4.6.2 of [RFC4861]) clear. 94 Each link has a single router responsible for advertising the 95 shared /64 on that link, so that if two routers are connected to 96 the same link, only one announces the prefix. That router will 97 also be responsible for detecting nodes using addresses on the /64 98 on that link, and maintaining state in the global neighbor table 99 for that link. 101 Every router must listen for router solicitation messages. When a 102 router solicitation message comes from an address on the 103 advertised /64 that has not been seen before, that address, and 104 the link on which it was received, is recorded in a global 105 neighbor table, which is quickly propagated amongs all routers on 106 the CP network. 108 Every router must listen for neighbor solicitation messages. When 109 a neighbor solicitation message is received for an address which 110 appears in the global neighbor table, the router checks to see if 111 the two addresses are on the same link. If they are not, the 112 router responds to the neighbor solicitation message. 114 In addition, when a neighbor solicitation comes from a source 115 address on the shared /64 that is not in the global neighbor 116 table, it is added to the global neighbor table. 118 Addresses in the global neighbor table are maintained as described 119 in section 7.3 of [RFC4861]. Unreachability detection is 120 performed by the router responsible for doing unreachability 121 detection on the link to which the node had been communicating. 123 When a router receives a message with a destination address on the 124 shared /64, it consults the global neighbor table to deliver it. 125 If the source and destination addresses are on the same link, the 126 router sends a redirect to the source of the message, as well as 127 [instead of?] forwarding it. 129 The difference between these two solutions is that one requires a 130 protocol for maintaining the global neighbor table. This can be done 131 using HNCP [RFC7788]. HNCP can also be used to elect the router 132 responsible for doing node discovery on that link. 134 2. Normative References 136 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 137 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 138 2016, . 140 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 141 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 142 DOI 10.17487/RFC4861, September 2007, 143 . 145 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 146 Address Autoconfiguration", RFC 4862, 147 DOI 10.17487/RFC4862, September 2007, 148 . 150 Author's Address 152 Ted Lemon 153 Nominum, Inc. 154 800 Bridge Parkway 155 Redwood City, California 94065 156 United States of America 158 Phone: +1 650 381 6000 159 Email: ted.lemon@nominum.com