< draft-ietf-isis-igp-p2p-over-lan-04.txt   draft-ietf-isis-igp-p2p-over-lan-05.txt >
Network Working Group Naiming Shen, Ed (Redback Networks) Network Working Group Naiming Shen, Ed (Redback Networks)
Internet Draft Alex Zinin, Ed (Alcatel) Internet Draft Alex Zinin, Ed (Alcatel)
Expiration Date: January 2005 Expiration Date: January 2005
July 2004 July 2004
Point-to-point operation over LAN Point-to-point operation over LAN
in link-state routing protocols in link-state routing protocols
draft-ietf-isis-igp-p2p-over-lan-04.txt draft-ietf-isis-igp-p2p-over-lan-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 7 skipping to change at page 2, line 7
The two predominant circuit types used by link state routing The two predominant circuit types used by link state routing
protocols are point-to-point and broadcast. It is important to protocols are point-to-point and broadcast. It is important to
identify the correct circuit type when forming adjacencies, identify the correct circuit type when forming adjacencies,
flooding link state database packets, and representing the circuit flooding link state database packets, and representing the circuit
topologically. This document describes a simple mechanism to treat topologically. This document describes a simple mechanism to treat
the broadcast network as a point-to-point connection from the the broadcast network as a point-to-point connection from the
standpoint of IP routing. standpoint of IP routing.
Contributors Contributors
The following individuals are the authers that contributed to the The following individuals are the authors that contributed to the
contents of this document. contents of this document.
Acee Lindem Acee Lindem
Redback Networks Redback Networks
102 Carric Bend Court 102 Carric Bend Court
Cary, NC 27519 USA Cary, NC 27519 USA
acee@redback.com acee@redback.com
Jenny Yuan Jenny Yuan
Redback Networks Redback Networks
skipping to change at page 2, line 34 skipping to change at page 2, line 34
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
e-mail: riw@cisco.com e-mail: riw@cisco.com
Stefano Previdi Stefano Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6A De Kleetlaan 6A
1831 Diegem - Belgium 1831 Diegem - Belgium
email: sprevidi@cisco.com 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 1. Introduction
Point-to-point and broadcast are the two predominant circuit Point-to-point and broadcast are the two predominant circuit
types used by link state routing protocols such as ISIS [ref1] types used by link state routing protocols such as ISIS [ref1]
[ref2] and OSPF [ref3, ref5]. They are treated differently with [ref2] and OSPF [ref3, ref5]. They are treated differently with
respect to establishing neighbor adjacencies, flooding link-state respect to establishing neighbor adjacencies, flooding link-state
information, representation of the topology, SPF calculation and information, representation of the topology, SPF calculation and
protocol packets. The most important differences are that broadcast protocol packets. The most important differences are that broadcast
circuits utilize the concept of a designated router and are circuits utilize the concept of a designated router and are
represented topologically as virtual nodes in the network topology represented topologically as virtual nodes in the network topology
skipping to change at page 4, line 29 skipping to change at page 4, line 36
2. Destination IP address - The interface address can be used by 2. Destination IP address - The interface address can be used by
other devices in the network as a destination address for other devices in the network as a destination address for
packets to router applications (examples include telnet, SMTP, packets to router applications (examples include telnet, SMTP,
TFTP, OSPF, BGP, etc). TFTP, OSPF, BGP, etc).
3. Next-hop identifier - If other routers connected to the same 3. Next-hop identifier - If other routers connected to the same
segment need to forward traffic through the router, the segment need to forward traffic through the router, the
corresponding routes in their routing tables will include the corresponding routes in their routing tables will include the
router's interface IP address. This address will be used to router's interface IP address. This address will be used to
find the router's MAC address using the ARP protocol. find the router's MAC address using the ARP/ND protocol.
Effectively, the interface IP addresses help other routers Effectively, the interface IP addresses help other routers
find the data-link layer details that are required to specify find the data-link layer details that are required to specify
the destination of the encapsulating data-link frame when it the destination of the encapsulating data-link frame when it
is sent on the segment. is sent on the segment.
The IP addressing scheme includes an option that allows the The IP addressing scheme includes an option that allows the
administrators to not assign any subnets to point-to-point links administrators to not assign any subnets to point-to-point links
(links connecting only two devices and using protocols like PPP, SLIP (links connecting only two devices and using protocols like PPP, SLIP
or HDLC for IP encapsulation). This is possible, because the routers or HDLC for IP encapsulation). This is possible, because the routers
do not need next-hop identifiers on point-to-point links (there is do not need next-hop identifiers on point-to-point links (there is
skipping to change at page 5, line 53 skipping to change at page 6, line 12
This is identical to operation over a physical point-to-point This is identical to operation over a physical point-to-point
link as described in sections 8.1 and 8.2 of [ref3]. link as described in sections 8.1 and 8.2 of [ref3].
4.3 ARP and ND 4.3 ARP and ND
Unlike normal point-to-point IGP circuit, the IP nexthop for the Unlike normal point-to-point IGP circuit, the IP nexthop for the
routes using this p2p-over-lan circuit as an outbound interface is routes using this p2p-over-lan circuit as an outbound interface is
not optional. The IP nexthop address has to be a valid interface not optional. The IP nexthop address has to be a valid interface
or internal address on the adjacent router. This address is used by or internal address on the adjacent router. This address is used by
local router to obtain the MAC address for IP packet forwarding. local router to obtain the MAC address for IP packet forwarding.
The ARP process has to be able to resolve the internal IP address The ARP process has to be able to resolve the internal IPv4 address
used for the unnumbered p2p-over-lan circuits. In IPv6 case, used for the unnumbered p2p-over-lan circuits. For the ARP
the ND resolves the MAC for the link-local address on the implementation which checks subnet of the source address of the
p2p-over-lan circuit, which is part of the IPv6 neighbor ARP request to match the local interface address, this check needs
discovering process [ref6]. 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 4.4 Other MAC address resolution mechanisms
In more general cases while p2p-over-lan circuit is used as an In more general cases while p2p-over-lan circuit is used as an
unnumbered link, other MAC address resolution mechanisms are needed unnumbered link, other MAC address resolution mechanisms are needed
for IP packet forwarding. For example, if link-state IGP is not for IP packet forwarding. For example, if link-state IGP is not
configured over this p2p-over-lan link, or if the mechanism described 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 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 to acquire the MAC address and/or the next-hop IP address of the
remote device on an unnumbered point-to-point LAN link. remote device on an unnumbered point-to-point LAN link.
skipping to change at page 7, line 26 skipping to change at page 7, line 38
Deployment of the described technique brings noticeable benefits from Deployment of the described technique brings noticeable benefits from
the perspective of IP address usage, the network management and the the perspective of IP address usage, the network management and the
router configuration. Note, however, that use of the IP unnumbered router configuration. Note, however, that use of the IP unnumbered
option for point-to-point LAN links inherits the same problems as 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 those present for serial links, i.e., not being able to ping or
monitor a specific interface between routers. monitor a specific interface between routers.
7. Security Considerations 7. Security Considerations
This document does not introduce any new security issues to ISIS or This document does not introduce any new security issues to ISIS,
OSPF. For ARP to support unnumbered IP interface addresses, it needs OSPF, ARP or ND. Implementations may have 'source address subnet
to verify the p2p-over-lan circuit type described in this document checks' which need to be relaxed as described in section 4.3.
and to verify the ARP or ND packet source interface address to match These are used to manage misconfigurations, not so much to secure
the IGP adjacency interface IP address. 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 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 broadcast or p2p-over-lan, and the other router has a different
opinion, the adjacencies will never form, as specified in opinion, the adjacencies will never form, as specified in
Section 4.5. There are no fallbacks at either end to resolve Section 4.5. There are no fallbacks at either end to resolve
the situation, except by a manual configuration change. the situation, except by a manual configuration change.
8. Acknowledgments 8. Acknowledgments
The authors would like to acknowledge the following individuals: The authors would like to acknowledge the following individuals:
skipping to change at page 7, line 41 skipping to change at page 8, line 4
If one router on a link thinks that a LAN should be either 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 broadcast or p2p-over-lan, and the other router has a different
opinion, the adjacencies will never form, as specified in opinion, the adjacencies will never form, as specified in
Section 4.5. There are no fallbacks at either end to resolve Section 4.5. There are no fallbacks at either end to resolve
the situation, except by a manual configuration change. the situation, except by a manual configuration change.
8. Acknowledgments 8. Acknowledgments
The authors would like to acknowledge the following individuals: The authors would like to acknowledge the following individuals:
(in last name alphabetical order) Pedro Marques, Christian Martin, (in last name alphabetical order) Pedro Marques, Christian Martin,
Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda and Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda,
Alvaro Retana. Alvaro Retana and Pekka Savola.
9. References 9. Normative References
[ref1] ISO. Information Technology - Telecommunications and [ref1] ISO. Information Technology - Telecommunications and
Information Exchange between Systems - Intermediate System Information Exchange between Systems - Intermediate System
to Intermediate System Routing Exchange Protocol for to Intermediate System Routing Exchange Protocol for
Use in Conjunction with the Protocol for Providing the Use in Conjunction with the Protocol for Providing the
Connectionless-Mode Network Service. ISO, 1990. Connectionless-Mode Network Service. ISO, 1990.
[ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual
Environments. INTERNET-RFC, Internet Engineering Task Force, Environments. INTERNET-RFC, Internet Engineering Task Force,
December 1990. December 1990.
skipping to change at page 8, line 21 skipping to change at page 8, line 33
[ref4] Hopps, C., "Routing IPv6 with IS-IS", [ref4] Hopps, C., "Routing IPv6 with IS-IS",
draft-ietf-isis-ipv6-05.txt, work in progress. draft-ietf-isis-ipv6-05.txt, work in progress.
[ref5] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", [ref5] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999. RFC 2740, December 1999.
[ref6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [ref6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
10. Editor Information [ref7] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10. Editors' Addresses
Naiming Shen Naiming Shen
Redback Networks Redback Networks
350 Holger Way 350 Holger Way
San Jose, CA, 95134 USA San Jose, CA, 95134 USA
naiming@redback.com naiming@redback.com
Alex Zinin Alex Zinin
Alcatel Alcatel
Sunnyvale, CA, USA Sunnyvale, CA, USA
skipping to change at line 409 skipping to change at page 9, line 37
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
- Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 11 change blocks. 
17 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/