RFC 5309

Bestie, here's the paperwork up top 🎀 This is RFC 5309, called Point-to-Point Operation over LAN in Link State Routing Protocols. N. Shen, Ed. from Cisco Systems and A. Zinin, Ed. from Alcatel-Lucent wrote it in October 2008. It's Informational 📚 and the title block doesn't list anything it obsoletes or updates.

Status of This Memo 📜

This memo is here to give info to the Internet community 💅 It is NOT an Internet standard of any kind, and anyone can distribute it freely ✨

Abstract 🫶

Link state routing protocols mostly deal with two circuit types, point-to-point and broadcast 🦋 Picking the right one matters when forming adjacencies, flooding link state database packets, and drawing the circuit in the topology. This doc describes a simple trick that lets you treat a broadcast network like a point-to-point connection, at least from the IP routing point of view 🌈

1. Introduction ✨

Point-to-point and broadcast are the two main circuit types for link state protocols like IS-IS [ISO10589] [RFC1195] and OSPF [RFC2328] [RFC5340] 🍓 They get handled differently for neighbor adjacencies, flooding, topology, and SPF and protocol packets. The biggest difference is that broadcast circuits use a designated router and show up as virtual nodes in the topology graph 👑

Point-to-point circuits are just simpler to run. There's no designated router, and no pseudonode or network LSA in the link state database. IS-IS also skips periodic database sync on them 🫶 On the flip side, if there are more than two routers on a LAN, the usual broadcast view will reduce the routing information in the network 🤔

When only two routers sit on a LAN, it makes way more sense to treat that link as point-to-point 💖 This doc explains how link state protocols can run point-to-point over a LAN in that situation, and it also covers some stuff about forwarding IP packets on this kind of circuit. We're calling it a p2p-over-lan circuit in here 🧚

1.1. Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 🎀

2. Motivation 💖

A broadcast circuit is built to handle more than two devices, but there are cases where only two routers are connected over a physical or logical LAN segment 🌸

1. The media is being used for point-to-point operation between two routers. This is mostly for long-haul stuff 🛰️
2. There are only two routers on the physical LAN.
3. There are only two routers on a virtual LAN (vLAN).

In any of those cases, link state protocols will still treat the media as a broadcast circuit by default. So they end up with all the overhead of LAN operation but none of the perks, like less routing info and optimized flooding 😭

Treating a LAN as a point-to-point circuit cuts down on how much info routing protocols have to carry and manage ✨ DR/DIS (Designated Router / Designated Intermediate System) election can be skipped entirely 🙈 Flooding can work like it does on p2p links, with no "LSA reflection" by the DR in OSPF and no periodic Complete Sequence Number Packets (CSNPs) in IS-IS 💅

Also, if a broadcast segment is wired as a point-to-point link, it can be treated like one, so only the connection between the two routers gets advertised as a topological entity 🦋

Even with several routers on a LAN, an ISP might want to split them into multiple vLANs, since that lets them give different costs to IGP neighbors 💜 When only two routers are in some of those vLANs, the IGP can view that LAN as a mesh of point-to-point connections 🕸️

IP unnumbered configuration is super popular in networks 🌈 It lets you run IP processing on a point-to-point interface without an explicit IP address. The unnumbered interface can "borrow" the IP address of another interface on the node. The perks of unnumbered p2p links are obvious when addresses are scarce, which they totally are right now 😤 The unnumbered interface can be used over p2p-over-lan circuits too. Splitting the concept of network type from media type means LANs, like ethernet, can be unnumbered and save IP address space 💖 It also makes network management and configuration simpler ✨ For IPv6, a link-local address used in IS-IS [RFC5308] and OSPFv3 [RFC5340] does the same job 🧚

3. IP Multi-Access Subnets 🌸

When an IP network has multi-access segments, each segment usually gets its own subnet, and each router on it gets a distinct IP address inside that subnet 🍓 The IP address on a multi-access interface does three jobs:

1. Source IP address. The router can use the interface address as the source IP address in locally originated IP packets that are headed for that subnet or have a best path next hop on that subnet.
2. Destination IP address. Other devices can use the interface address as the destination for packets aimed at router applications (like telnet, SMTP, TFTP, OSPF, BGP, etc).
3. Next-hop identifier. If other routers on the same segment need to forward traffic through this router, their routing tables will include the router's interface IP address. That address gets used to find the router's MAC (Media Access Control) address via ARP/ND (Address Resolution Protocol / Neighbor Discovery) 🔍 So the interface IPs basically help other routers find the data-link layer details they need to address the encapsulating frame when it goes out on the segment 💌

The IP addressing scheme has an option that lets admins skip assigning subnets to point-to-point links 🎀 Those are links that only connect two devices and use protocols like PPP, SLIP, or HDLC for IP encapsulation. It works because routers don't need next-hop identifiers on point-to-point links (there's only one destination for any transmission), so an interface-independent IP address can serve as both the source and the destination 👑 Using the unnumbered option on a point-to-point link turns it into a purely topological entity that's only used to reach other destinations 🦋

4. Point-to-Point Connection over LAN Media 🫶

The idea is super simple ✨ You provide a config mechanism that tells the IGP the circuit is type point-to-point, no matter what the physical media is. From the IGP's side, it sends protocol packets with the right point-to-point info and expects to receive protocol packets the same way it would on a point-to-point circuit 🧚 Over LAN media, the MAC header must contain the correct multicast MAC address so the other side of the connection receives it. For vLAN environments, the MAC header must also contain the proper vLAN ID 💅

To let LAN links that only connect two routers be treated as unnumbered point-to-point interfaces, the MAC address resolution and nexthop IP address issues need to be handled 🌈

4.1. Operation of IS-IS 🍓

This p2p-over-lan circuit extension for IS-IS only cares about pure IP routing and forwarding operation 💖

Physically the circuit is broadcast, so IS-IS protocol packets need MAC addresses for this p2p-over-lan circuit 😤 From a link-layer point of view, those packets are IS-IS LAN packets. The multi-destination addresses AllISs, AllL1ISs, and AllL2ISs, defined in [ISO10589], can be used for link-layer encapsulation, and the use of AllISs is recommended 💜

The circuit needs IP address(es). The p2p IS-IS Hello (IIH) over this circuit MUST include the IP interface address(es) as defined in [RFC1195] 🎀 The IPv4 address(es) in the IIHs is either the IP address assigned to the interface for a numbered interface, or the interface-independent IP address for an unnumbered interface. The IPv6 addresses are link-local IPv6 address(es) [RFC5308] ✨

4.2. Operation of OSPF and OSPFv3 🦋

OSPF and OSPFv3 [RFC5340] routers that support the capabilities described here should support an extra interface config parameter that specifies the interface topology type 🌸 For a LAN (i.e., broadcast-capable) interface, the interface may be viewed as a point-to-point interface. Both routers on the LAN just join the AllSPFRouters multicast group and send all OSPF packets with AllSPFRouters as the destination address 🧚 AllSPFRouters is 224.0.0.5 for OSPF and FF02::5 for OSPFv3 💅 This matches how it works over a physical point-to-point link, as described in Sections 8.1 and 8.2 of [RFC2328] 👑

4.3. ARP and ND 🔍

Unlike a normal point-to-point IGP circuit, the IP nexthop for routes using this p2p-over-lan circuit as an outbound interface is not optional 😭 The IP nexthop address has to be a valid interface or internal address on the adjacent router. The local router uses that address to get the MAC address for IP packet forwarding 💌 The ARP process has to be able to resolve the internal IPv4 address used for unnumbered p2p-over-lan circuits. The ARP implementation checks that the subnet of the source address of the ARP request matches the local interface address, and for unnumbered p2p-over-lan circuits that check needs to be relaxed 🙈 Misconfiguration detection is handled by the IGPs and is described in Section 4.5 ✨ In the IPv6 case, ND resolves the MAC for the link-local address on the p2p-over-lan circuit, which is part of the IPv6 neighbor discovery process [RFC4861] 🫶

---

4.4. Other MAC Address Resolution Mechanisms 🦋

okay so this bit covers the times when the p2p-over-lan circuit is running as an unnumbered link but you still need other ways to get MAC addresses for forwarding IP packets 💅. like, if link state IGP isn't configured over this p2p-over-lan link, or if the mechanism in Section 4.3 just isn't possible, you need a backup plan 😭. these techniques can help you grab the MAC address and/or the next-hop IP address of the remote device on an unnumbered point-to-point LAN link:

1. Static configuration. A router can be statically configured with the MAC address that should be used as the destination MAC address when sending data out of the interface. hard-coding it, bestie 🫶
2. MAC address gleaning. If a dynamic routing protocol is running between the routers connected to the link, the MAC address of the remote device can be taken from a data-link frame carrying a packet of the corresponding routing protocol. ✨ the routing traffic is doing double duty here, iykyk 🧚

4.5. Detection of Misconfiguration 🙈

with this p2p-over-lan extension, the difference between a LAN and a point-to-point circuit can be made purely by configuration. wild, right? 🌈 so it's super important to implement the mechanisms for early detection of misconfiguration 🚨

if the circuit is configured as the point-to-point type and receives LAN hello packets, the router MUST discard the incoming packets. if the circuit is a LAN type and receives point-to-point hello packets, it MUST discard the incoming packets. if the system ID or the router ID of an incoming hello packet doesn't match the system ID or the router ID for an established adjacency over a p2p-over-lan circuit, the packet MUST be discarded. and if OSPF hello suppression (as described in [RFC1793]) is active for the adjacency, the hello suppression MUST be terminated for a period of RouterIntervalSeconds. 💀

after that interval passes, either the neighbor adjacency times out and an adjacency may be formed with a neighbor with a different router ID, or hello suppression may be renegotiated. the implementation should offer logging and debugging information of the above events 📝 receipts, please 💅

5. Compatibility Considerations 🤝

both routers on a LAN must support the p2p-over-lan extension, and both must have the LAN segment configured as a p2p-over-lan circuit for successful operation. both routers SHOULD support at least one of the above listed methods for mapping IP addresses on the link to MAC address. if a proprietary method of IP address to MAC address resolution is used by one router, both routers must be capable of using the same method. otherwise, the link should be configured as a standard LAN link, with traditional IGP LAN models used. no mismatched vibes allowed 🙅‍♀️

6. Scalability and Deployment Considerations 📈

there is an advantage to using this extension on LANs that are connected back to back or only contain two routers 🍓 but there are trade-offs when modeling a LAN as multiple vLANs and using this extension, since you do sacrifice the inherent scalability benefits of multi-access networks. in general, it will increase the link state database size, the amount of packets flooded, and the route calculation overhead. more stuff, more work 😮‍💨

deploying the described technique brings noticeable benefits from the perspective of IP address usage: the network management and the router configuration. 🎀 note, however, that use of the IP unnumbered option for point-to-point LAN links inherits the same problems as those present for serial links, i.e., not being able to ping or monitor a specific interface between routers. the tradeoff is real, bestie 😔

7. Security Considerations 🔐

this document does not introduce any new security issues to IS-IS, OSPF, ARP, or ND. implementations may have 'source address subnet checks' that need to be relaxed as described in Section 4.3. these are used to manage misconfigurations, not so much to secure ARP -- if an attacker would be attached to the LAN, (s)he could pick a subnet-wise correct address as well. so don't get it twisted, this is about config sanity, not a security shield 🛡️

if one router on a link thinks that a LAN should be either broadcast or p2p-over-lan, and the other router has a different opinion, the adjacencies will never form, as specified in Section 4.5. there are no fallbacks at either end to resolve the situation, except by a manual configuration change. the adjacencies will literally never form, so you're gonna have to fix it by hand 😤💔

8. Acknowledgments 🫶

the authors would like to thank these amazing people (in alphabetical order by last name): Pedro Marques, Christian Martin, Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda, Alvaro Retana, and Pekka Savola. you're all iconic ✨👑

9. Normative References 📚

[ISO10589] ISO, "Intermediate System to Intermediate System intra-
           domain routeing information exchange protocol for use in
           conjunction with the protocol for providing the
           connectionless-mode network service (ISO 8473)",
           International Standard 10589:2002, Second Edition, 2002.

[RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
           dual environments", RFC 1195, December 1990.

[RFC1793]  Moy, J., "Extending OSPF to Support Demand Circuits", RFC
           1793, April 1995.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
           "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
           September 2007.

[RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
           2008.

[RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
           for IPv6", RFC 5340, July 2008.

Contributors 💜

the following individuals are the authors who contributed to the contents of this document. the squad 🧚‍♀️

Acee Lindem
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC  27709
USA
EMail: acee@cisco.com

Jenny Yuan
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
EMail: jenny@cisco.com

Russ White
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
EMail: riw@cisco.com

Stefano Previdi
Cisco Systems, Inc.
De Kleetlaan 6A
1831 Diegem - Belgium
EMail: sprevidi@cisco.com

Editors' Addresses 🖊️

Naiming Shen
Cisco Systems
225 West Tasman Drive
San Jose, CA  95134
USA
EMail: naiming@cisco.com

Alex Zinin
Alcatel-Lucent
750D Chai Chee Rd, #06-06
Technopark@ChaiChee
Singapore 469004

EMail: alex.zinin@alcatel-lucent.com

Full Copyright Statement ⚖️

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
ietf-ipr@ietf.org.