Network Working Group N. Shen, Ed. Request for Comments: 5309 Cisco Systems Category: Informational A. Zinin, Ed. Alcatel-Lucent October 2008 Point-to-Point Operation over LAN in Link State Routing Protocols Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
AbstractThe two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. ISO10589] [RFC1195] and OSPF [RFC2328] [RFC5340]. They are treated differently with respect to establishing neighbor adjacencies, flooding link state information, representing the topology, and calculating the Shortest Path First (SPF) and protocol packets. The most important differences are that broadcast circuits utilize the concept of a designated router and are represented topologically as virtual nodes in the network topology graph. Compared with broadcast circuits, point-to-point circuits afford more straightforward IGP operation. There is no designated router involved, and there is no representation of the pseudonode or network Link State Advertisement (LSA) in the link state database. For IS- IS, there also is no periodic database synchronization. Conversely, if there are more than two routers on the LAN media, the traditional view of the broadcast circuit will reduce the routing information in the network.
When there are only two routers on the LAN, it makes more sense to treat the connection between the two routers as a point-to-point circuit. This document describes the mechanism to allow link state routing protocols to operate using point-to-point connections over a LAN under this condition. Some implications related to forwarding IP packets on this type of circuit are also discussed. We will refer to this as a p2p-over-lan circuit in this document. RFC2119].
The IP unnumbered configuration is widely used in networks. It enables IP processing on a point-to-point interface without an explicit IP address. The IP unnumbered interface can "borrow" the IP address of another interface on the node. The advantages of unnumbered point-to-point links are obvious in the current IP addressing environment where addresses are a scarce resource. The unnumbered interface can also be applied over p2p-over-lan circuits. Separating the concept of network type from media type will allow LANs, e.g., ethernet, to be unnumbered and realize the IP address space savings. Another advantage is in simpler network management and configuration. In the case of an IPv6 network, a link local address used in IS-IS [RFC5308] and OSPFv3 [RFC5340] serves the same purpose.
(there is only one destination for any transmission), and an interface-independent IP address can be used as the source and destination. Using the unnumbered option for a point-to-point link essentially makes it a purely topological entity used only to reach other destinations. ISO10589], can be used for link-layer encapsulation; the use of AllISs is recommended. The circuit needs to have IP address(es), and the p2p IS-IS Hello (IIH) over this circuit MUST include the IP interface address(es) as defined in [RFC1195]. The IPv4 address(es) included in the IIHs is either the IP address assigned to the interface in the case of a numbered interface or the interface-independent IP address in the case of an unnumbered interface. The IPv6 addresses are link-local IPv6 address(es) [RFC5308]. RFC5340] routers supporting the capabilities described herein should support an additional interface configuration parameter specifying 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 will simply join the AllSPFRouters multicast group and send all OSPF packets with a destination address of AllSPFRouters. AllSPFRouters is 22.214.171.124 for OSPF and FF02::5 for OSPFv3. This is identical to operation over a physical point-to-point link as described in Sections 8.1 and 8.2 of [RFC2328]. Section 4.5. In the IPv6 case, the 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]. Section 4.3 is not possible. The following techniques can be used to acquire 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. 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.
RFC1793]) is active for the adjacency, the hello suppression MUST be terminated for a period of RouterIntervalSeconds. After this interval, either the neighbor adjacency will time 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.
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. 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. 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. [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.
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 email@example.com.