Network Working Group O. Troan Internet-Draft cisco Intended status: Informational 6 October 2020 Expires: 9 April 2021 IP Point to Point Ethernet subnet model draft-troan-6man-p2p-ethernet-00 Abstract Ethernet topology is no longer a shared medium. It is a long time since Ethernet has been a thick yellow cable snaking its way from station to station. Ethernet is now effectively deployed in a hub and spoke topology. With a point to point link between a host and the network device. This memo describes a set of simplications for how to run IP over such links, where the physical topology is exposed in the network layer topology. 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 https://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 9 April 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Troan Expires 9 April 2021 [Page 1] Internet-Draft IP Point to Point Ethernet subnet model October 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Implications for Neighbor Discovery . . . . . . . . . . . . . 5 5. TODO/Open issues . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 9. Informative References . . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This memo describes a way of connecting network layer devices across Ethernet, where the physical topology is exposed to the network layer. With 10BASE-T [IEEE.802-3.1990], Ethernet is a hub and spoke network topology with the Ethernet switch as the hub and stations as spokes. While the techniques described in this document in part applies to a bridged or switched network, for the sake of simplicty of explanation only a network where all devices are IP nodes is considered. Most modern Ethernet switches are also IP routers, and of course all Ethernet stations are IP hosts. | Suspension of disbelief. This note assumes the reader accepts | that Ethernet switches can do IP routing, and for the purpose | of this memo the reader should think of anything that is a | "hub" in an Ethernet network as an IP router. This mechanism delivers complete host isolation at the network layer. A host only shares the same network layer link with the default router, and the shared subnet is only the link-local prefix. Troan Expires 9 April 2021 [Page 2] Internet-Draft IP Point to Point Ethernet subnet model October 2020 The simplest example of this topology is an IP router with a set of Ethernet interfaces (i.e. an Ethernet L3 switch) with one port connecting one IP host. Lets call this network device an "Ethernet Router". While there are many ways P2P Ethernet could be implemented, the simplest to explain is one where there the router has a (virtual) interface per station. If an address prefix is configured on a router's typical network layer Ethernet interface, it results in the prefix in the FIB pointing to a glean adjacency. Packets being forwarded against the glean adjacency will undergo address resolution. If address resolution is successful a host route is installed in the FIB with an adjacency containing the required encap-string (known as a complete adjacency). The encap string contains the full Ethernet header with the source and destination MAC addresses. An IP multicast packet forwarded out the interface would undergo address multicast address mapping as described in [RFC2464]. With this technique no broadcast or multicast Ethernet packet will be sent out an P2P Ethernet interface from the network side. A legacy host might of course. A P2P Ethernet interface connects to a single host and skips the above address resolution step. Each (virtual) P2P Ethernet interface will have the associated complete adjacency with a full encap-string. I.e. the full Ethernet header, including the destination MAC address. This encap string is also used for multicast packets. That is, no address mapping is required for multicast packets and no address resolution is required for unicast packets. Now, the avid reader might wonder how this virtual interface is spawned in the first place? It clearly has to be dynamic as hosts connect to the network. Well, the answer is that it depends. In the simple topology of hosts directly connected to an Ethernet router, the physical interface is configured in p2p mode and the host's MAC address can be learnt with a simple mechanism like first sign of life (FSOL). If 802.1x is used, then successful 802.1x authentication can be used to spawn the creation of the P2P Ethernet interface. On wireless networks, a tight integration between access point and router would allow the AP to signal station attachment to the router for interface spawning. Otherwise the same could be done in a wireless LAN controller setup. Troan Expires 9 April 2021 [Page 3] Internet-Draft IP Point to Point Ethernet subnet model October 2020 The changes described here can be deployed purely on the network side. Although it could also be extended with host support, with a marginal saving in the number of packets sent on the link. A legacy host will behave as if it was connected to a normal multi-access link, and would do address resolution to it's router, perform DAD etc. Is a wireless network a hub and spoke network? You can make that assertion. All traffic from station to access point goes to the AP, and with different encryption keys per station, it's essentially behaving like a set of point to point link between station and AP. This provides an alternative (and a much simpler solution) to the proposal in [I-D.thubert-6man-ipv6-over-wireless]. 1.1. Conventions and Terminology 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 RFC 2119 [RFC2119]. Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*", "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU WON'T)*" in this document are to interpreted as described in RFC 6919 [RFC6919]. 2. Terminology ethernet router: An Ethernet switch with IP routing enabled. 3. Addressing P2P Ethernet simplifies addressing. A node at one end of the point to point link does not need to share a subnet with the other end. If DHCP address assignment is used, then a host route can be installed in the FIB pointing out the given virtual P2P Ethernet interface. 2001:db8::1/128 -> Virtual-P2PEthernet0 For SLAAC a /64 route can be pointed at the interface and a PIO configured to be sent in RA. Note that in the case of SLAAC, regardless of how many addresses a host would use, no more state is required on the router. Which in contrast with the classical Ethernet deployment, where each address uses a slot in the neighbour cache. Troan Expires 9 April 2021 [Page 4] Internet-Draft IP Point to Point Ethernet subnet model October 2020 4. Implications for Neighbor Discovery Neighbor Discovery [RFC4861] solves a set of problems related to the interaction between nodes attached to the same link. The following details of these functions apply, do not apply or can be simplified on a point to point link. Router Discovery: On a point to point link it is still useful to discover an attached router. Although in theory the host can just send the packet on the link. The RA is required if SLAAC is used. The RA could also be extended to convey to the host that it's connected to a point to point link. Prefix Discovery: Prefix discovery for the purposes of address assignment [RFC4862] is done like on a multi-access link. If SLAAC is not used prefix discovery is not strictly required. The link-model assumes that only the link-local prefix is shared among the two nodes on the link. On-link discovery is not performed on a p2p link. Parameter Discovery: Unchanged. Address Autoconfiguration: SLAAC can be simplified, e.g. DAD is not necessary. Address resolution: Address resolution is not needed on a point to point link. A> Discuss consequences for detection of bidirectional connectivity** Next-hop determination: On a point to point link next-hop determination is not required. There is only one choice. Neighbor Unreachability Detection: NUD might still provide some usefulness in cases where data-link layer notifications are masked. Duplicate Address Detection: Duplicate Address Detection is only required for the link-local address. Redirect: Redirects are not needed. There is no-one to redirect to on a point to point link. Troan Expires 9 April 2021 [Page 5] Internet-Draft IP Point to Point Ethernet subnet model October 2020 5. TODO/Open issues * The consequences of random MAC addresses Appear as a completely new host? * Tethering * Mobility * Describe that the mDNS domain is restricted to a single host / require homenet solution / mDNS proxy * New P2P bit in Router Advertisement * IPv4 support. A legacy IPv4 host would typically require that the default gateway is in the same subnet as the host's IPv4 address. 6. Security Considerations A shared network using ND, without SEND assumes that all other nodes on the link are trust-worthy. The mechanism proposed here isolates all hosts, so that most of the ND functions are no longer needed. The host still needs to trust it's connected router. 7. IANA Considerations 8. 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, . [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, . [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words for Use in RFCs to Indicate Requirement Levels", RFC 6919, DOI 10.17487/RFC6919, April 2013, . 9. Informative References [I-D.thubert-6man-ipv6-over-wireless] Thubert, P., "IPv6 Neighbor Discovery on Wireless Networks", Work in Progress, Internet-Draft, draft- Troan Expires 9 April 2021 [Page 6] Internet-Draft IP Point to Point Ethernet subnet model October 2020 thubert-6man-ipv6-over-wireless-06, 1 June 2020, . [IEEE.802-3.1990] "Information Processing Systems - Local Area Networks - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 2nd edition", September 1990. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . Appendix A. Acknowledgements Thanks to lots of people. Author's Address O. Troan cisco Email: ot@cisco.com Troan Expires 9 April 2021 [Page 7]