idnits 2.17.1 draft-ietf-isis-igp-p2p-over-lan-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7217 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 80 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Naiming Shen, Ed (Redback Networks) 3 Internet Draft Alex Zinin, Ed (Alcatel) 4 Expiration Date: January 2005 5 July 2004 7 Point-to-point operation over LAN 8 in link-state routing protocols 10 draft-ietf-isis-igp-p2p-over-lan-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as 28 "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 The two predominant circuit types used by link state routing 39 protocols are point-to-point and broadcast. It is important to 40 identify the correct circuit type when forming adjacencies, 41 flooding link state database packets, and representing the circuit 42 topologically. This document describes a simple mechanism to treat 43 the broadcast network as a point-to-point connection from the 44 standpoint of IP routing. 46 Contributors 48 The following individuals are the authors that contributed to the 49 contents of this document. 51 Acee Lindem 52 Redback Networks 53 102 Carric Bend Court 54 Cary, NC 27519 USA 55 acee@redback.com 57 Jenny Yuan 58 Redback Networks 59 350 Holger Way 60 San Jose, CA, 95134 USA 61 jenny@redback.com 63 Russ White 64 Cisco Systems, Inc. 65 7025 Kit Creek Rd. 66 Research Triangle Park, NC 27709 67 e-mail: riw@cisco.com 69 Stefano Previdi 70 Cisco Systems, Inc. 71 De Kleetlaan 6A 72 1831 Diegem - Belgium 73 email: sprevidi@cisco.com 75 Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [3]. 81 1. Introduction 83 Point-to-point and broadcast are the two predominant circuit 84 types used by link state routing protocols such as ISIS [ref1] 85 [ref2] and OSPF [ref3, ref5]. They are treated differently with 86 respect to establishing neighbor adjacencies, flooding link-state 87 information, representation of the topology, SPF calculation and 88 protocol packets. The most important differences are that broadcast 89 circuits utilize the concept of a designated router and are 90 represented topologically as virtual nodes in the network topology 91 graph. 93 Compared with broadcast circuits, point-to-point circuits 94 afford more straightforward IGP operation. There is no designated 95 router involved and there is no representation of the pseudo-node 96 or network LSA in the link state database. For ISIS, there also is 97 no periodic database synchronization. Conversely, if there are more 98 than two routers on the LAN media, the traditional view of the 99 broadcast circuit will reduce the routing information in the network. 101 When there are only two routers on the LAN, it makes more sense to 102 treat the connection between the two routers as a point-to-point 103 circuit. This document describes the mechanism to allow link state 104 routing protocols to operate using point-to-point connections over 105 a LAN under this condition. Some implications related to forwarding 106 IP packets on this type of circuit are also discussed. We will refer 107 to this as a p2p-over-lan circuit in this document. 109 2. Motivation 111 Even though a broadcast circuit is meant to handle more than two 112 devices, there are cases where only two routers are connected 113 over either the physical or logical LAN segment: 115 1. The media itself is being used for point-to-point 116 operation between two routers. This is mainly for 117 long-haul operation. 118 2. There are only two routers on the physical LAN. 119 3. There are only two routers on a virtual LAN (vLAN). 121 In any of the above cases, the link state routing protocols will 122 normally still treat the media as a broadcast circuit. Hence, they 123 will have the overhead involved with protocol LAN operation without 124 the benefits of reducing routing information and optimized flooding. 126 Being able to treat a LAN as a point-to-point circuit provides the 127 benefit of reduction in the amount of information routing 128 protocols must carry and manage. DR/DIS election can be omitted. 129 Flooding can be done as in p2p links without the need of using 130 "LSA reflection" by the DR in OSPF or periodic CSNPs in ISIS. 132 Also, if a broadcast segment wired as a point-to-point link 133 can be treated as a point-to-point link, only the connection between 134 the two routers would need to be advertised as a topological entity. 136 Even when there are multiple routers on the LAN an ISP may want 137 to sub-group the routers into multiple vLANs since this allows 138 them to assign different costs to IGP neighbors. When there are 139 only two routers in some of the vLANs, this LAN can be viewed by 140 the IGP as a mesh of point-to-point connections. 142 IP unnumbered configuration is widely used in networks. It enables 143 IP processing on a point-to-point interface without an explicit 144 IP address. The IP unnumbered interface can "borrow" the IP 145 address of another interface on the node. The advantages of 146 unnumbered point-to-point links are obvious in the current IP 147 addressing environment where addresses are a scarce resource. The 148 unnumbered interface can also be applied over p2p-over-lan circuits. 149 Separating the concept of network type from media type will allow 150 LANs, e.g. ethernet, to be unnumbered and realize the IP address 151 space savings. Another advantage is in simpler network management 152 and configuration. In the case of IPv6 network, link-local address 153 used in ISIS [ref4] and OSPFv3 [ref5] serves the same purpose. 155 3. IP multi-access subnets 157 When an IP network includes multi-access segments, each segment is 158 usually assigned a separate subnet and each router connected to it is 159 assigned a distinct IP address within that subnet. The role of the 160 IP address assigned to a multi-access interface can be outlined as 161 follows: 163 1. Source IP address - The interface address can be used by 164 the router as the source IP address in locally originated 165 IP packets destined for that subnet or having a best path 166 next hop on that subnet. 168 2. Destination IP address - The interface address can be used by 169 other devices in the network as a destination address for 170 packets to router applications (examples include telnet, SMTP, 171 TFTP, OSPF, BGP, etc). 173 3. Next-hop identifier - If other routers connected to the same 174 segment need to forward traffic through the router, the 175 corresponding routes in their routing tables will include the 176 router's interface IP address. This address will be used to 177 find the router's MAC address using the ARP/ND protocol. 178 Effectively, the interface IP addresses help other routers 179 find the data-link layer details that are required to specify 180 the destination of the encapsulating data-link frame when it 181 is sent on the segment. 183 The IP addressing scheme includes an option that allows the 184 administrators to not assign any subnets to point-to-point links 185 (links connecting only two devices and using protocols like PPP, SLIP 186 or HDLC for IP encapsulation). This is possible, because the routers 187 do not need next-hop identifiers on point-to-point links (there is 188 only one destination for any transmission), and an interface 189 independent IP address can be used as the source and destination. 190 Using the unnumbered option for a point-to-point link essentially 191 makes it a purely topological entity used only to reach other 192 destinations. 194 4. Point-to-point connection over LAN media 196 The idea is very simple: provide a configuration mechanism to 197 inform the IGP that the circuit is type point-to-point 198 irrespective of the physical media type. For the IGP, this implies 199 that it will send protocol packets with the appropriate 200 point-to-point information and expects to receive protocol packets 201 as they would be received on a point-to-point circuit. Over LAN 202 media, the MAC header must contain the correct multicast MAC address 203 to be received by the other side of the connection. For vLAN 204 environments, the MAC header must also contain the proper vLAN ID. 206 In order to allow LAN links used to connect only two routers to be 207 treated as unnumbered point-to-point interfaces, the MAC address 208 resolution and nexthop IP address issues need to be addressed. 210 4.1 Operation of ISIS 212 This p2p-over-lan circuit extension for ISIS is only concerned 213 in pure IP routing and forwarding operation. 215 Since physically the circuit is a broadcast one, the ISIS protocol 216 packets need to have MAC addresses for this p2p-over-lan circuit. 217 From link layer point of view, those packets are ISIS LAN packets. 218 The Multi-destination address including AllISs, AllL1ISs and AllL2ISs 219 defined in [ref1] can be used for link layer encapsulation, the 220 use of AllISs is recommended. 222 The circuit needs to have IP address(es) and the p2p IIH over this 223 circuit MUST include the IP interface address(es) as defined in 224 [ref2]. The IPv4 address(es) included in the IIHs is either the 225 IP address assigned to the interface in the case of a numbered 226 interface or the interface-independent IP address in the case of 227 an unnumbered interface. The IPv6 addresses are link-local IPv6 228 address(es) [ref4]. 230 4.2 Operation of OSPF and OSPFv3 232 OSPF and OSPFv3 [ref5] routers supporting the capabilities 233 described herein should support an additional interface 234 configuration parameter specifying the interface topology type. 235 For a LAN (i.e., broadcast capable) interface, the interface may 236 be viewed as a point-to-point interface. Both routers on the LAN 237 will simply join the AllSPFRouters multicast group and send all 238 OSPF packets with a destination address of AllSPFRouters. 239 AllSPFRouters is 224.0.0.5 for OSPF and FF02::5 for OSPFv3. 240 This is identical to operation over a physical point-to-point 241 link as described in sections 8.1 and 8.2 of [ref3]. 243 4.3 ARP and ND 245 Unlike normal point-to-point IGP circuit, the IP nexthop for the 246 routes using this p2p-over-lan circuit as an outbound interface is 247 not optional. The IP nexthop address has to be a valid interface 248 or internal address on the adjacent router. This address is used by 249 local router to obtain the MAC address for IP packet forwarding. 250 The ARP process has to be able to resolve the internal IPv4 address 251 used for the unnumbered p2p-over-lan circuits. For the ARP 252 implementation which checks subnet of the source address of the 253 ARP request to match the local interface address, this check needs 254 to be relaxed for the unnumbered p2p-over-lan circuits. The 255 mis-configuration detection is handled by the IGPs and is described 256 in section 4.5. In IPv6 case, the ND resolves the MAC for the 257 link-local address on the p2p-over-lan circuit, which is part of 258 the IPv6 neighbor discovery process [ref6]. 260 4.4 Other MAC address resolution mechanisms 262 In more general cases while p2p-over-lan circuit is used as an 263 unnumbered link, other MAC address resolution mechanisms are needed 264 for IP packet forwarding. For example, if link-state IGP is not 265 configured over this p2p-over-lan link, or if the mechanism described 266 in section 4.3 is not possible. The following techniques can be used 267 to acquire the MAC address and/or the next-hop IP address of the 268 remote device on an unnumbered point-to-point LAN link. 270 1. Static configuration. A router can be statically configured 271 with the MAC address that should be used as the destination 272 MAC address when sending data out of the interface. 274 2. MAC address gleaning. If a dynamic routing protocol is running 275 between the routers connected to the link, the MAC address of 276 the remote device can be taken from a data-link frame carrying 277 a packet of the corresponding routing protocol. 279 4.5 Detection of mis-configuration 281 With this p2p-over-lan extension, the difference between a LAN and 282 a point-to-point circuit can be made purely by configuration. It is 283 important to implement the mechanisms for early detection of 284 mis-configuration. 286 If the circuit is configured as point-to-point type and receives 287 LAN hello packets, the router MUST discard the incoming packets; If 288 the circuit is a LAN type and receive point-to-point hello packets, 289 it MUST discard the incoming packets. If the system ID or the 290 router ID of incoming hello packet does not match the system ID or 291 the router ID of already established adjacency over this p2p-over-lan 292 circuit, it MUST discard the packet. The implementation should offer 293 logging and debugging information of the above events. 295 5. Compatibility considerations 297 Both routers on a LAN must support the p2p-over-lan extension 298 and both must have the LAN segment configured as a p2p-over-lan 299 circuit for successful operation. Both routers SHOULD support at 300 least one of the above listed methods for mapping ip addresses on 301 the link to MAC address. If a proprietary method of IP address to 302 MAC address resolution is used by one router, both routers must 303 be capable of using the same method. Otherwise, the link should 304 be configured as a standard LAN link, with traditional IGP LAN 305 models used. 307 6. Scalability and deployment considerations 309 While there is advantage to use this extension on the LANs 310 that are connected back-to-back or only contain two routers, 311 however there are tradeoffs when modeling a LAN as multiple vLANs 312 and using this extension since one does sacrifice the inherent 313 scalability benefits of multi-access networks. In general, 314 it will increase the link-state database size, the amount of 315 packets flooded and the route calculation overhead. Network design 316 engineers should carefully balance between the associated 317 overhead. 319 Deployment of the described technique brings noticeable benefits from 320 the perspective of IP address usage, the network management and the 321 router configuration. Note, however, that use of the IP unnumbered 322 option for point-to-point LAN links inherits the same problems as 323 those present for serial links, i.e., not being able to ping or 324 monitor a specific interface between routers. 326 7. Security Considerations 328 This document does not introduce any new security issues to ISIS, 329 OSPF, ARP or ND. Implementations may have 'source address subnet 330 checks' which need to be relaxed as described in section 4.3. 331 These are used to manage misconfigurations, not so much to secure 332 ARP -- if an attacker would be attached to the LAN, (s)he could 333 pick a subnet-wise correct address as well. 335 If one router on a link thinks that a LAN should be either 336 broadcast or p2p-over-lan, and the other router has a different 337 opinion, the adjacencies will never form, as specified in 338 Section 4.5. There are no fallbacks at either end to resolve 339 the situation, except by a manual configuration change. 341 8. Acknowledgments 343 The authors would like to acknowledge the following individuals: 345 (in last name alphabetical order) Pedro Marques, Christian Martin, 346 Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda, 347 Alvaro Retana and Pekka Savola. 349 9. Normative References 351 [ref1] ISO. Information Technology - Telecommunications and 352 Information Exchange between Systems - Intermediate System 353 to Intermediate System Routing Exchange Protocol for 354 Use in Conjunction with the Protocol for Providing the 355 Connectionless-Mode Network Service. ISO, 1990. 357 [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 358 Environments. INTERNET-RFC, Internet Engineering Task Force, 359 December 1990. 361 [ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet 362 Engineering Task Force, 1998. 364 [ref4] Hopps, C., "Routing IPv6 with IS-IS", 365 draft-ietf-isis-ipv6-05.txt, work in progress. 367 [ref5] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", 368 RFC 2740, December 1999. 370 [ref6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 371 for IP Version 6 (IPv6)", RFC 2461, December 1998. 373 [ref7] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 10. Editors' Addresses 378 Naiming Shen 379 Redback Networks 380 350 Holger Way 381 San Jose, CA, 95134 USA 382 naiming@redback.com 384 Alex Zinin 385 Alcatel 386 Sunnyvale, CA, USA 387 e-mail: zinin@psg.com 389 Intellectual Property Considerations 390 The IETF takes no position regarding the validity or scope of any 391 intellectual property or other rights that might be claimed to 392 pertain to the implementation or use of the technology described in 393 this document or the extent to which any license under such rights 394 might or might not be available; neither does it represent that it 395 has made any effort to identify any such rights. Information on the 396 IETF's procedures with respect to rights in standards-track and 397 standards-related documentation can be found in BCP-11. Copies of 398 claims of rights made available for publication and any assurances of 399 licenses to be made available, or the result of an attempt made to 400 obtain a general license or permission for the use of such 401 proprietary rights by implementors or users of this specification can 402 be obtained from the IETF Secretariat. 404 The IETF invites any interested party to bring to its attention any 405 copyrights, patents or patent applications, or other proprietary 406 rights which may cover technology that may be required to practice 407 this standard. Please address the information to the IETF Executive 408 Director. 410 Full Copyright Notice 412 Copyright (C) The Internet Society (2004). This document is subject 413 to the rights, licenses and restrictions contained in BCP 78, and 414 except as set forth therein, the authors retain all their rights. 416 This document and the information contained herein is provided on an 417 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 418 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 419 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 420 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 421 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 423 Acknowledgment 425 Funding for the RFC Editor function is currently provided by the 426 Internet Society.