idnits 2.17.1 draft-ietf-isis-igp-p2p-over-lan-06.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 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 434. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- == 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 (April 2006) is 6548 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Naiming Shen (Ed) 2 Internet Draft Cisco Systems 3 Expiration Date: October 2006 Alex Zinin (Ed) 4 Alcatel 5 April 2006 7 Point-to-point operation over LAN 8 in link-state routing protocols 10 draft-ietf-isis-igp-p2p-over-lan-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 10, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The two predominant circuit types used by link state routing 44 protocols are point-to-point and broadcast. It is important to 45 identify the correct circuit type when forming adjacencies, 46 flooding link state database packets, and representing the circuit 47 topologically. This document describes a simple mechanism to treat 48 the broadcast network as a point-to-point connection from the 49 standpoint of IP routing. 51 Contributors 53 The following individuals are the authors that contributed to the 54 contents of this document. 56 Acee Lindem 57 Cisco Systems 58 7025 Kit Creek Road 59 Research Triangle Park, NC 27709 60 USA 61 Email: acee@cisco.com 63 Jenny Yuan 64 Cisco Systems 65 225 West Tasman Drive 66 San Jose, CA 95134 67 USA 68 Email: jenny@cisco.com 70 Russ White 71 Cisco Systems, Inc. 72 7025 Kit Creek Rd. 73 Research Triangle Park, NC 27709 74 e-mail: riw@cisco.com 76 Stefano Previdi 77 Cisco Systems, Inc. 78 De Kleetlaan 6A 79 1831 Diegem - Belgium 80 email: sprevidi@cisco.com 82 Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [ref8]. 88 1. Introduction 90 Point-to-point and broadcast are the two predominant circuit 91 types used by link state routing protocols such as ISIS [ref1] 92 [ref2] and OSPF [ref3, ref5]. They are treated differently with 93 respect to establishing neighbor adjacencies, flooding link-state 94 information, representation of the topology, SPF calculation and 95 protocol packets. The most important differences are that broadcast 96 circuits utilize the concept of a designated router and are 97 represented topologically as virtual nodes in the network topology 98 graph. 100 Compared with broadcast circuits, point-to-point circuits 101 afford more straightforward IGP operation. There is no designated 102 router involved and there is no representation of the pseudo-node 103 or network LSA in the link state database. For ISIS, there also is 104 no periodic database synchronization. Conversely, if there are more 105 than two routers on the LAN media, the traditional view of the 106 broadcast circuit will reduce the routing information in the network. 108 When there are only two routers on the LAN, it makes more sense to 109 treat the connection between the two routers as a point-to-point 110 circuit. This document describes the mechanism to allow link state 111 routing protocols to operate using point-to-point connections over 112 a LAN under this condition. Some implications related to forwarding 113 IP packets on this type of circuit are also discussed. We will refer 114 to this as a p2p-over-lan circuit in this document. 116 2. Motivation 118 Even though a broadcast circuit is meant to handle more than two 119 devices, there are cases where only two routers are connected 120 over either the physical or logical LAN segment: 122 1. The media itself is being used for point-to-point 123 operation between two routers. This is mainly for 124 long-haul operation. 125 2. There are only two routers on the physical LAN. 126 3. There are only two routers on a virtual LAN (vLAN). 128 In any of the above cases, the link state routing protocols will 129 normally still treat the media as a broadcast circuit. Hence, they 130 will have the overhead involved with protocol LAN operation without 131 the benefits of reducing routing information and optimized flooding. 133 Being able to treat a LAN as a point-to-point circuit provides the 134 benefit of reduction in the amount of information routing 135 protocols must carry and manage. DR/DIS election can be omitted. 136 Flooding can be done as in p2p links without the need of using 137 "LSA reflection" by the DR in OSPF or periodic CSNPs in ISIS. 139 Also, if a broadcast segment wired as a point-to-point link 140 can be treated as a point-to-point link, only the connection between 141 the two routers would need to be advertised as a topological entity. 143 Even when there are multiple routers on the LAN an ISP may want 144 to sub-group the routers into multiple vLANs since this allows 145 them to assign different costs to IGP neighbors. When there are 146 only two routers in some of the vLANs, this LAN can be viewed by 147 the IGP as a mesh of point-to-point connections. 149 IP unnumbered configuration is widely used in networks. It enables 150 IP processing on a point-to-point interface without an explicit 151 IP address. The IP unnumbered interface can "borrow" the IP 152 address of another interface on the node. The advantages of 153 unnumbered point-to-point links are obvious in the current IP 154 addressing environment where addresses are a scarce resource. The 155 unnumbered interface can also be applied over p2p-over-lan circuits. 156 Separating the concept of network type from media type will allow 157 LANs, e.g. ethernet, to be unnumbered and realize the IP address 158 space savings. Another advantage is in simpler network management 159 and configuration. In the case of IPv6 network, link-local address 160 used in ISIS [ref4] and OSPFv3 [ref5] serves the same purpose. 162 3. IP multi-access subnets 164 When an IP network includes multi-access segments, each segment is 165 usually assigned a separate subnet and each router connected to it is 166 assigned a distinct IP address within that subnet. The role of the 167 IP address assigned to a multi-access interface can be outlined as 168 follows: 170 1. Source IP address - The interface address can be used by 171 the router as the source IP address in locally originated 172 IP packets destined for that subnet or having a best path 173 next hop on that subnet. 175 2. Destination IP address - The interface address can be used by 176 other devices in the network as a destination address for 177 packets to router applications (examples include telnet, SMTP, 178 TFTP, OSPF, BGP, etc). 180 3. Next-hop identifier - If other routers connected to the same 181 segment need to forward traffic through the router, the 182 corresponding routes in their routing tables will include the 183 router's interface IP address. This address will be used to 184 find the router's MAC address using the ARP/ND protocol. 185 Effectively, the interface IP addresses help other routers 186 find the data-link layer details that are required to specify 187 the destination of the encapsulating data-link frame when it 188 is sent on the segment. 190 The IP addressing scheme includes an option that allows the 191 administrators to not assign any subnets to point-to-point links 192 (links connecting only two devices and using protocols like PPP, SLIP 193 or HDLC for IP encapsulation). This is possible, because the routers 194 do not need next-hop identifiers on point-to-point links (there is 195 only one destination for any transmission), and an interface 196 independent IP address can be used as the source and destination. 197 Using the unnumbered option for a point-to-point link essentially 198 makes it a purely topological entity used only to reach other 199 destinations. 201 4. Point-to-point connection over LAN media 203 The idea is very simple: provide a configuration mechanism to 204 inform the IGP that the circuit is type point-to-point 205 irrespective of the physical media type. For the IGP, this implies 206 that it will send protocol packets with the appropriate 207 point-to-point information and expects to receive protocol packets 208 as they would be received on a point-to-point circuit. Over LAN 209 media, the MAC header must contain the correct multicast MAC address 210 to be received by the other side of the connection. For vLAN 211 environments, the MAC header must also contain the proper vLAN ID. 213 In order to allow LAN links used to connect only two routers to be 214 treated as unnumbered point-to-point interfaces, the MAC address 215 resolution and nexthop IP address issues need to be addressed. 217 4.1 Operation of ISIS 219 This p2p-over-lan circuit extension for ISIS is only concerned 220 in pure IP routing and forwarding operation. 222 Since physically the circuit is a broadcast one, the ISIS protocol 223 packets need to have MAC addresses for this p2p-over-lan circuit. 224 From link layer point of view, those packets are ISIS LAN packets. 225 The Multi-destination address including AllISs, AllL1ISs and AllL2ISs 226 defined in [ref1] can be used for link layer encapsulation, the 227 use of AllISs is recommended. 229 The circuit needs to have IP address(es) and the p2p IIH over this 230 circuit MUST include the IP interface address(es) as defined in 231 [ref2]. The IPv4 address(es) included in the IIHs is either the 232 IP address assigned to the interface in the case of a numbered 233 interface or the interface-independent IP address in the case of 234 an unnumbered interface. The IPv6 addresses are link-local IPv6 235 address(es) [ref4]. 237 4.2 Operation of OSPF and OSPFv3 239 OSPF and OSPFv3 [ref5] routers supporting the capabilities 240 described herein should support an additional interface 241 configuration parameter specifying the interface topology type. 242 For a LAN (i.e., broadcast capable) interface, the interface may 243 be viewed as a point-to-point interface. Both routers on the LAN 244 will simply join the AllSPFRouters multicast group and send all 245 OSPF packets with a destination address of AllSPFRouters. 246 AllSPFRouters is 224.0.0.5 for OSPF and FF02::5 for OSPFv3. 247 This is identical to operation over a physical point-to-point 248 link as described in sections 8.1 and 8.2 of [ref3]. 250 4.3 ARP and ND 252 Unlike normal point-to-point IGP circuit, the IP nexthop for the 253 routes using this p2p-over-lan circuit as an outbound interface is 254 not optional. The IP nexthop address has to be a valid interface 255 or internal address on the adjacent router. This address is used by 256 local router to obtain the MAC address for IP packet forwarding. 257 The ARP process has to be able to resolve the internal IPv4 address 258 used for the unnumbered p2p-over-lan circuits. For the ARP 259 implementation which checks subnet of the source address of the 260 ARP request to match the local interface address, this check needs 261 to be relaxed for the unnumbered p2p-over-lan circuits. The 262 mis-configuration detection is handled by the IGPs and is described 263 in section 4.5. In IPv6 case, the ND resolves the MAC for the 264 link-local address on the p2p-over-lan circuit, which is part of 265 the IPv6 neighbor discovery process [ref6]. 267 4.4 Other MAC address resolution mechanisms 269 In more general cases while p2p-over-lan circuit is used as an 270 unnumbered link, other MAC address resolution mechanisms are needed 271 for IP packet forwarding. For example, if link-state IGP is not 272 configured over this p2p-over-lan link, or if the mechanism described 273 in section 4.3 is not possible. The following techniques can be used 274 to acquire the MAC address and/or the next-hop IP address of the 275 remote device on an unnumbered point-to-point LAN link. 277 1. Static configuration. A router can be statically configured 278 with the MAC address that should be used as the destination 279 MAC address when sending data out of the interface. 281 2. MAC address gleaning. If a dynamic routing protocol is running 282 between the routers connected to the link, the MAC address of 283 the remote device can be taken from a data-link frame carrying 284 a packet of the corresponding routing protocol. 286 4.5 Detection of mis-configuration 288 With this p2p-over-lan extension, the difference between a LAN and 289 a point-to-point circuit can be made purely by configuration. It is 290 important to implement the mechanisms for early detection of 291 mis-configuration. 293 If the circuit is configured as point-to-point type and receives 294 LAN hello packets, the router MUST discard the incoming packets; If 295 the circuit is a LAN type and receive point-to-point hello packets, 296 it MUST discard the incoming packets. If the system ID or the 297 router ID of incoming hello packet does not match the system ID or 298 the router ID for an established adjacency over a p2p-over-lan 299 circuit, the packet MUST discarded. Furthermore, if OSPF hello 300 suppression as described in [ref7] is active for the adjacency, 301 the hello suppression MUST be terminated for a period of 302 RouterIntervalSeconds. After this interval either the neighbor 303 adjacency will time out and an adjacency may be formed with 304 a neighbor with different router ID or hello suppression may be 305 renegotiated. The implementation should offer logging and debugging 306 information of the above events. 308 5. Compatibility considerations 310 Both routers on a LAN must support the p2p-over-lan extension 311 and both must have the LAN segment configured as a p2p-over-lan 312 circuit for successful operation. Both routers SHOULD support at 313 least one of the above listed methods for mapping ip addresses on 314 the link to MAC address. If a proprietary method of IP address to 315 MAC address resolution is used by one router, both routers must 316 be capable of using the same method. Otherwise, the link should 317 be configured as a standard LAN link, with traditional IGP LAN 318 models used. 320 6. Scalability and deployment considerations 322 While there is advantage to use this extension on the LANs 323 that are connected back-to-back or only contain two routers, 324 however there are tradeoffs when modeling a LAN as multiple vLANs 325 and using this extension since one does sacrifice the inherent 326 scalability benefits of multi-access networks. In general, 327 it will increase the link-state database size, the amount of 328 packets flooded and the route calculation overhead. Network design 329 engineers should carefully balance between the associated 330 overhead. 332 Deployment of the described technique brings noticeable benefits from 333 the perspective of IP address usage, the network management and the 334 router configuration. Note, however, that use of the IP unnumbered 335 option for point-to-point LAN links inherits the same problems as 336 those present for serial links, i.e., not being able to ping or 337 monitor a specific interface between routers. 339 7. Security Considerations 341 This document does not introduce any new security issues to ISIS, 342 OSPF, ARP or ND. Implementations may have 'source address subnet 343 checks' which need to be relaxed as described in section 4.3. 344 These are used to manage misconfigurations, not so much to secure 345 ARP -- if an attacker would be attached to the LAN, (s)he could 346 pick a subnet-wise correct address as well. 348 If one router on a link thinks that a LAN should be either 349 broadcast or p2p-over-lan, and the other router has a different 350 opinion, the adjacencies will never form, as specified in 351 Section 4.5. There are no fallbacks at either end to resolve 352 the situation, except by a manual configuration change. 354 8. Acknowledgments 356 The authors would like to acknowledge the following individuals: 357 (in last name alphabetical order) Pedro Marques, Christian Martin, 358 Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda, 359 Alvaro Retana and Pekka Savola. 361 11. IANA Considerations 363 This document has no IANA considerations. 365 This section should be removed by the RFC Editor to final 366 publication. 368 10. Normative References 370 [ref1] ISO. Information Technology - Telecommunications and 371 Information Exchange between Systems - Intermediate System 372 to Intermediate System Routing Exchange Protocol for 373 Use in Conjunction with the Protocol for Providing the 374 Connectionless-Mode Network Service. ISO, 1990. 376 [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 377 Environments. INTERNET-RFC, Internet Engineering Task Force, 378 December 1990. 380 [ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet 381 Engineering Task Force, 1998. 383 [ref4] Hopps, C., "Routing IPv6 with IS-IS", 384 draft-ietf-isis-ipv6-06.txt, work in progress. 386 [ref5] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", 387 RFC 2740, December 1999. 389 [ref6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 390 for IP Version 6 (IPv6)", RFC 2461, December 1998. 392 [ref7] Moy, J., "Extending OSPF to Support Demand Circuits", 393 RFC 1793, April 1995. 395 [ref8] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 11. Editors' Addresses 400 Naiming Shen 401 Cisco Systems 402 225 West Tasman Drive 403 San Jose, CA 95134 404 USA 405 Email: naiming@cisco.com 407 Alex Zinin 408 Alcatel 409 Sunnyvale, CA, USA 410 e-mail: zinin@psg.com 412 Intellectual Property Statement 414 The IETF takes no position regarding the validity or scope of any 415 Intellectual Property Rights or other rights that might be claimed to 416 pertain to the implementation or use of the technology described in 417 this document or the extent to which any license under such rights 418 might or might not be available; nor does it represent that it has 419 made any independent effort to identify any such rights. Information 420 on the procedures with respect to rights in RFC documents can be 421 found in BCP 78 and BCP 79. 423 Copies of IPR disclosures made to the IETF Secretariat and any 424 assurances of licenses to be made available, or the result of an 425 attempt made to obtain a general license or permission for the use of 426 such proprietary rights by implementers or users of this 427 specification can be obtained from the IETF on-line IPR repository at 428 http://www.ietf.org/ipr. 430 The IETF invites any interested party to bring to its attention any 431 copyrights, patents or patent applications, or other proprietary 432 rights that may cover technology that may be required to implement 433 this standard. Please address the information to the IETF at 434 ietf-ipr@ietf.org. 436 Disclaimer of Validity 438 This document and the information contained herein are provided on an 439 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 440 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 441 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 442 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 443 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 444 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 446 Copyright Statement 448 Copyright (C) The Internet Society (2006). This document is subject 449 to the rights, licenses and restrictions contained in BCP 78, and 450 except as set forth therein, the authors retain all their rights. 452 Acknowledgment 454 Funding for the RFC Editor function is currently provided by the 455 Internet Society.