[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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


   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

   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

   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*",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*",
   WON'T)*" in this document are to interpreted as described in RFC 6919

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

   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

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:


   Address Autoconfiguration:  SLAAC can be simplified, e.g.  DAD is not

   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

              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,

              "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

   Email: ot@cisco.com

Troan                     Expires 9 April 2021                  [Page 7]