Network Working Group Naiming Shen, Ed (Redback Networks)
Internet Draft Alex Zinin, Ed (Alcatel)
Expiration Date: January 2005
July 2004
Point-to-point operation over LAN
in link-state routing protocols
draft-ietf-isis-igp-p2p-over-lan-05.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The 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.
Shen, Zinin, et al Expires January 2005 [Page 1]
INTERNET DRAFT P2P OVER LAN July 2004
Contributors
The following individuals are the authors that contributed to the
contents of this document.
Acee Lindem
Redback Networks
102 Carric Bend Court
Cary, NC 27519 USA
acee@redback.com
Jenny Yuan
Redback Networks
350 Holger Way
San Jose, CA, 95134 USA
jenny@redback.com
Russ White
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
e-mail: riw@cisco.com
Stefano Previdi
Cisco Systems, Inc.
De Kleetlaan 6A
1831 Diegem - Belgium
email: sprevidi@cisco.com
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 [3].
1. Introduction
Point-to-point and broadcast are the two predominant circuit
types used by link state routing protocols such as ISIS [ref1]
[ref2] and OSPF [ref3, ref5]. They are treated differently with
respect to establishing neighbor adjacencies, flooding link-state
information, representation of the topology, SPF calculation 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
Shen, Zinin, et al Expires January 2005 [Page 2]
INTERNET DRAFT P2P OVER LAN July 2004
router involved and there is no representation of the pseudo-node
or network LSA in the link state database. For ISIS, 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.
2. Motivation
Even though a broadcast circuit is meant to handle more than two
devices, there are cases where only two routers are connected
over either the physical or logical LAN segment:
1. The media itself is being used for point-to-point
operation between two routers. This is mainly for
long-haul operation.
2. There are only two routers on the physical LAN.
3. There are only two routers on a virtual LAN (vLAN).
In any of the above cases, the link state routing protocols will
normally still treat the media as a broadcast circuit. Hence, they
will have the overhead involved with protocol LAN operation without
the benefits of reducing routing information and optimized flooding.
Being able to treat a LAN as a point-to-point circuit provides the
benefit of reduction in the amount of information routing
protocols must carry and manage. DR/DIS election can be omitted.
Flooding can be done as in p2p links without the need of using
"LSA reflection" by the DR in OSPF or periodic CSNPs in ISIS.
Also, if a broadcast segment wired as a point-to-point link
can be treated as a point-to-point link, only the connection between
the two routers would need to be advertised as a topological entity.
Even when there are multiple routers on the LAN an ISP may want
to sub-group the routers into multiple vLANs since this allows
them to assign different costs to IGP neighbors. When there are
only two routers in some of the vLANs, this LAN can be viewed by
the IGP as a mesh of point-to-point connections.
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
Shen, Zinin, et al Expires January 2005 [Page 3]
INTERNET DRAFT P2P OVER LAN July 2004
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 IPv6 network, link-local address
used in ISIS [ref4] and OSPFv3 [ref5] serves the same purpose.
3. IP multi-access subnets
When an IP network includes multi-access segments, each segment is
usually assigned a separate subnet and each router connected to it is
assigned a distinct IP address within that subnet. The role of the
IP address assigned to a multi-access interface can be outlined as
follows:
1. Source IP address - The interface address can be used by
the router as the source IP address in locally originated
IP packets destined for that subnet or having a best path
next hop on that subnet.
2. Destination IP address - The interface address can be used by
other devices in the network as a destination address for
packets to router applications (examples include telnet, SMTP,
TFTP, OSPF, BGP, etc).
3. Next-hop identifier - If other routers connected to the same
segment need to forward traffic through the router, the
corresponding routes in their routing tables will include the
router's interface IP address. This address will be used to
find the router's MAC address using the ARP/ND protocol.
Effectively, the interface IP addresses help other routers
find the data-link layer details that are required to specify
the destination of the encapsulating data-link frame when it
is sent on the segment.
The IP addressing scheme includes an option that allows the
administrators to not assign any subnets to point-to-point links
(links connecting only two devices and using protocols like PPP, SLIP
or HDLC for IP encapsulation). This is possible, because the routers
do not need next-hop identifiers on point-to-point links (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.
Shen, Zinin, et al Expires January 2005 [Page 4]
INTERNET DRAFT P2P OVER LAN July 2004
4. Point-to-point connection over LAN media
The idea is very simple: provide a configuration mechanism to
inform the IGP that the circuit is type point-to-point
irrespective of the physical media type. For the IGP, this implies
that it will send protocol packets with the appropriate
point-to-point information and expects to receive protocol packets
as they would be received on a point-to-point circuit. Over LAN
media, the MAC header must contain the correct multicast MAC address
to be received by the other side of the connection. For vLAN
environments, the MAC header must also contain the proper vLAN ID.
In order to allow LAN links used to connect only two routers to be
treated as unnumbered point-to-point interfaces, the MAC address
resolution and nexthop IP address issues need to be addressed.
4.1 Operation of ISIS
This p2p-over-lan circuit extension for ISIS is only concerned
in pure IP routing and forwarding operation.
Since physically the circuit is a broadcast one, the ISIS protocol
packets need to have MAC addresses for this p2p-over-lan circuit.
From link layer point of view, those packets are ISIS LAN packets.
The Multi-destination address including AllISs, AllL1ISs and AllL2ISs
defined in [ref1] can be used for link layer encapsulation, the
use of AllISs is recommended.
The circuit needs to have IP address(es) and the p2p IIH over this
circuit MUST include the IP interface address(es) as defined in
[ref2]. 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) [ref4].
4.2 Operation of OSPF and OSPFv3
OSPF and OSPFv3 [ref5] 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 224.0.0.5 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 [ref3].
Shen, Zinin, et al Expires January 2005 [Page 5]
INTERNET DRAFT P2P OVER LAN July 2004
4.3 ARP and ND
Unlike normal point-to-point IGP circuit, the IP nexthop for the
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. This address is used by
local router to obtain the MAC address for IP packet forwarding.
The ARP process has to be able to resolve the internal IPv4 address
used for the unnumbered p2p-over-lan circuits. For the ARP
implementation which checks subnet of the source address of the
ARP request to match the local interface address, this check needs
to be relaxed for the unnumbered p2p-over-lan circuits. The
mis-configuration detection is handled by the IGPs and is described
in section 4.5. In 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 [ref6].
4.4 Other MAC address resolution mechanisms
In more general cases while p2p-over-lan circuit is used as an
unnumbered link, other MAC address resolution mechanisms are needed
for IP packet forwarding. For example, if link-state IGP is not
configured over this p2p-over-lan link, or if the mechanism described
in 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.
4.5 Detection of mis-configuration
With this p2p-over-lan extension, the difference between a LAN and
a point-to-point circuit can be made purely by configuration. It is
important to implement the mechanisms for early detection of
mis-configuration.
If the circuit is configured as point-to-point type and receives
LAN hello packets, the router MUST discard the incoming packets; If
the circuit is a LAN type and receive point-to-point hello packets,
it MUST discard the incoming packets. If the system ID or the
router ID of incoming hello packet does not match the system ID or
the router ID of already established adjacency over this p2p-over-lan
circuit, it MUST discard the packet. The implementation should offer
logging and debugging information of the above events.
Shen, Zinin, et al Expires January 2005 [Page 6]
INTERNET DRAFT P2P OVER LAN July 2004
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.
6. Scalability and deployment considerations
While there is advantage to use this extension on the LANs
that are connected back-to-back or only contain two routers,
however there are tradeoffs when modeling a LAN as multiple vLANs
and using this extension since one does 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. Network design
engineers should carefully balance between the associated
overhead.
Deployment of 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.
7. Security Considerations
This document does not introduce any new security issues to ISIS,
OSPF, ARP or ND. Implementations may have 'source address subnet
checks' which 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.
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.
8. Acknowledgments
The authors would like to acknowledge the following individuals:
Shen, Zinin, et al Expires January 2005 [Page 7]
INTERNET DRAFT P2P OVER LAN July 2004
(in last name alphabetical order) Pedro Marques, Christian Martin,
Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda,
Alvaro Retana and Pekka Savola.
9. Normative References
[ref1] ISO. Information Technology - Telecommunications and
Information Exchange between Systems - Intermediate System
to Intermediate System Routing Exchange Protocol for
Use in Conjunction with the Protocol for Providing the
Connectionless-Mode Network Service. ISO, 1990.
[ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual
Environments. INTERNET-RFC, Internet Engineering Task Force,
December 1990.
[ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet
Engineering Task Force, 1998.
[ref4] Hopps, C., "Routing IPv6 with IS-IS",
draft-ietf-isis-ipv6-05.txt, work in progress.
[ref5] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[ref6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[ref7] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10. Editors' Addresses
Naiming Shen
Redback Networks
350 Holger Way
San Jose, CA, 95134 USA
naiming@redback.com
Alex Zinin
Alcatel
Sunnyvale, CA, USA
e-mail: zinin@psg.com
Intellectual Property Considerations
Shen, Zinin, et al Expires January 2005 [Page 8]
INTERNET DRAFT P2P OVER LAN July 2004
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Notice
Copyright (C) The Internet Society (2004). 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 is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shen, Zinin, et al Expires January 2005 [Page 9]
