idnits 2.17.1 draft-troan-6man-p2p-ethernet-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (6 October 2020) is 1297 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-thubert-6man-ipv6-over-wireless-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Troan 3 Internet-Draft cisco 4 Intended status: Informational 6 October 2020 5 Expires: 9 April 2021 7 IP Point to Point Ethernet subnet model 8 draft-troan-6man-p2p-ethernet-00 10 Abstract 12 Ethernet topology is no longer a shared medium. It is a long time 13 since Ethernet has been a thick yellow cable snaking its way from 14 station to station. Ethernet is now effectively deployed in a hub 15 and spoke topology. With a point to point link between a host and 16 the network device. This memo describes a set of simplications for 17 how to run IP over such links, where the physical topology is exposed 18 in the network layer topology. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 9 April 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Implications for Neighbor Discovery . . . . . . . . . . . . . 5 58 5. TODO/Open issues . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 62 9. Informative References . . . . . . . . . . . . . . . . . . . 6 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 This memo describes a way of connecting network layer devices across 69 Ethernet, where the physical topology is exposed to the network 70 layer. With 10BASE-T [IEEE.802-3.1990], Ethernet is a hub and spoke 71 network topology with the Ethernet switch as the hub and stations as 72 spokes. While the techniques described in this document in part 73 applies to a bridged or switched network, for the sake of simplicty 74 of explanation only a network where all devices are IP nodes is 75 considered. Most modern Ethernet switches are also IP routers, and 76 of course all Ethernet stations are IP hosts. 78 | Suspension of disbelief. This note assumes the reader accepts 79 | that Ethernet switches can do IP routing, and for the purpose 80 | of this memo the reader should think of anything that is a 81 | "hub" in an Ethernet network as an IP router. 83 This mechanism delivers complete host isolation at the network layer. 84 A host only shares the same network layer link with the default 85 router, and the shared subnet is only the link-local prefix. 87 The simplest example of this topology is an IP router with a set of 88 Ethernet interfaces (i.e. an Ethernet L3 switch) with one port 89 connecting one IP host. Lets call this network device an "Ethernet 90 Router". 92 While there are many ways P2P Ethernet could be implemented, the 93 simplest to explain is one where there the router has a (virtual) 94 interface per station. 96 If an address prefix is configured on a router's typical network 97 layer Ethernet interface, it results in the prefix in the FIB 98 pointing to a glean adjacency. Packets being forwarded against the 99 glean adjacency will undergo address resolution. If address 100 resolution is successful a host route is installed in the FIB with an 101 adjacency containing the required encap-string (known as a complete 102 adjacency). The encap string contains the full Ethernet header with 103 the source and destination MAC addresses. An IP multicast packet 104 forwarded out the interface would undergo address multicast address 105 mapping as described in [RFC2464]. With this technique no broadcast 106 or multicast Ethernet packet will be sent out an P2P Ethernet 107 interface from the network side. A legacy host might of course. 109 A P2P Ethernet interface connects to a single host and skips the 110 above address resolution step. Each (virtual) P2P Ethernet interface 111 will have the associated complete adjacency with a full encap-string. 112 I.e. the full Ethernet header, including the destination MAC address. 113 This encap string is also used for multicast packets. That is, no 114 address mapping is required for multicast packets and no address 115 resolution is required for unicast packets. 117 Now, the avid reader might wonder how this virtual interface is 118 spawned in the first place? It clearly has to be dynamic as hosts 119 connect to the network. Well, the answer is that it depends. In the 120 simple topology of hosts directly connected to an Ethernet router, 121 the physical interface is configured in p2p mode and the host's MAC 122 address can be learnt with a simple mechanism like first sign of life 123 (FSOL). If 802.1x is used, then successful 802.1x authentication can 124 be used to spawn the creation of the P2P Ethernet interface. On 125 wireless networks, a tight integration between access point and 126 router would allow the AP to signal station attachment to the router 127 for interface spawning. Otherwise the same could be done in a 128 wireless LAN controller setup. 130 The changes described here can be deployed purely on the network 131 side. Although it could also be extended with host support, with a 132 marginal saving in the number of packets sent on the link. A legacy 133 host will behave as if it was connected to a normal multi-access 134 link, and would do address resolution to it's router, perform DAD 135 etc. 137 Is a wireless network a hub and spoke network? You can make that 138 assertion. All traffic from station to access point goes to the AP, 139 and with different encryption keys per station, it's essentially 140 behaving like a set of point to point link between station and AP. 142 This provides an alternative (and a much simpler solution) to the 143 proposal in [I-D.thubert-6man-ipv6-over-wireless]. 145 1.1. Conventions and Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "*SHALL NOT*", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", 152 "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU 153 WON'T)*" in this document are to interpreted as described in RFC 6919 154 [RFC6919]. 156 2. Terminology 158 ethernet router: An Ethernet switch with IP routing enabled. 160 3. Addressing 162 P2P Ethernet simplifies addressing. A node at one end of the point 163 to point link does not need to share a subnet with the other end. 165 If DHCP address assignment is used, then a host route can be 166 installed in the FIB pointing out the given virtual P2P Ethernet 167 interface. 169 2001:db8::1/128 -> Virtual-P2PEthernet0 171 For SLAAC a /64 route can be pointed at the interface and a PIO 172 configured to be sent in RA. Note that in the case of SLAAC, 173 regardless of how many addresses a host would use, no more state is 174 required on the router. Which in contrast with the classical 175 Ethernet deployment, where each address uses a slot in the neighbour 176 cache. 178 4. Implications for Neighbor Discovery 180 Neighbor Discovery [RFC4861] solves a set of problems related to the 181 interaction between nodes attached to the same link. The following 182 details of these functions apply, do not apply or can be simplified 183 on a point to point link. 185 Router Discovery: On a point to point link it is still useful to 186 discover an attached router. Although in theory the host can just 187 send the packet on the link. The RA is required if SLAAC is used. 188 The RA could also be extended to convey to the host that it's 189 connected to a point to point link. 191 Prefix Discovery: Prefix discovery for the purposes of address 192 assignment [RFC4862] is done like on a multi-access link. If 193 SLAAC is not used prefix discovery is not strictly required. The 194 link-model assumes that only the link-local prefix is shared among 195 the two nodes on the link. On-link discovery is not performed on 196 a p2p link. 198 Parameter Discovery: 200 Unchanged. 202 Address Autoconfiguration: SLAAC can be simplified, e.g. DAD is not 203 necessary. 205 Address resolution: 207 Address resolution is not needed on a point to point link. A> 208 Discuss consequences for detection of bidirectional connectivity** 210 Next-hop determination: On a point to point link next-hop 211 determination is not required. There is only one choice. 213 Neighbor Unreachability Detection: 215 NUD might still provide some usefulness in cases where data-link 216 layer notifications are masked. 218 Duplicate Address Detection: Duplicate Address Detection is only 219 required for the link-local address. 221 Redirect: Redirects are not needed. There is no-one to redirect to 222 on a point to point link. 224 5. TODO/Open issues 226 * The consequences of random MAC addresses Appear as a completely 227 new host? 229 * Tethering 231 * Mobility 233 * Describe that the mDNS domain is restricted to a single host / 234 require homenet solution / mDNS proxy 236 * New P2P bit in Router Advertisement 238 * IPv4 support. A legacy IPv4 host would typically require that the 239 default gateway is in the same subnet as the host's IPv4 address. 241 6. Security Considerations 243 A shared network using ND, without SEND assumes that all other nodes 244 on the link are trust-worthy. The mechanism proposed here isolates 245 all hosts, so that most of the ND functions are no longer needed. 246 The host still needs to trust it's connected router. 248 7. IANA Considerations 250 8. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, 254 DOI 10.17487/RFC2119, March 1997, 255 . 257 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 258 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 259 DOI 10.17487/RFC4861, September 2007, 260 . 262 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 263 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 264 DOI 10.17487/RFC6919, April 2013, 265 . 267 9. Informative References 269 [I-D.thubert-6man-ipv6-over-wireless] 270 Thubert, P., "IPv6 Neighbor Discovery on Wireless 271 Networks", Work in Progress, Internet-Draft, draft- 272 thubert-6man-ipv6-over-wireless-06, 1 June 2020, 273 . 276 [IEEE.802-3.1990] 277 "Information Processing Systems - Local Area Networks - 278 Part 3: Carrier sense multiple access with collision 279 detection (CSMA/CD) access method and physical layer 280 specifications, 2nd edition", September 1990. 282 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 283 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 284 . 286 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 287 Address Autoconfiguration", RFC 4862, 288 DOI 10.17487/RFC4862, September 2007, 289 . 291 Appendix A. Acknowledgements 293 Thanks to lots of people. 295 Author's Address 297 O. Troan 298 cisco 300 Email: ot@cisco.com