idnits 2.17.1 draft-ietf-isis-igp-p2p-over-lan-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 186: '... circuit MUST include the IP interfa...' RFC 2119 keyword, line 261: '...kets, the router MUST discard the inco...' RFC 2119 keyword, line 263: '... it MUST discard the incoming packet...' RFC 2119 keyword, line 266: '... circuit, it MUST discard the packet...' RFC 2119 keyword, line 273: '...eration. Both routers MAY also support...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 2001) is 8287 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: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Naiming Shen 2 Internet Draft Acee Lindem 3 Expiration Date: February 2002 Jenny Yuan 4 File name: draft-ietf-isis-igp-p2p-over-lan-00.txt Redback Networks 5 Alex Zinin 6 Nexsi Systems 7 Russ White 8 Stefano Previdi 9 Cisco Systems 10 August 2001 12 Point-to-point operation over LAN 13 in link-state routing protocols 15 draft-ietf-isis-igp-p2p-over-lan-00.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as 31 "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 The two predominant circuit types used by link state routing 42 protocols are point-to-point and broadcast. It is important to 43 identify the correct circuit type when forming adjacencies, 44 flooding link state database packets, and representing the circuit 45 topologically. This document describes a simple mechanism to treat 46 the broadcast network as a point-to-point connection from the 47 standpoint of IP routing. 49 1. Introduction 51 Point-to-point and broadcast are the two predominant circuit 52 types used by link state routing protocols such as IS-IS [ref1] 53 [ref2] and OSPF [ref3]. They are treated differently with respect 54 to establishing neighbor adjacencies, flooding of link-state 55 information, representation of the topology, SPF calculation and 56 protocol packets. The most important differences are that broadcast 57 circuits utilize the concept of a designated router and are 58 represented topologically as virtual nodes in the network topology 59 graph. 61 Compared with broadcast circuits, point-to-point circuits 62 afford more straightforward IGP operation. There is no designated 63 router involved and there is no representation of the pseudo-node 64 or network LSA in the link state database. For ISIS, there also is 65 no periodic database synchronization. Conversely, if there are more 66 than two routers on the LAN media, the traditional view of the 67 broadcast circuit will reduce the routing information in the network. 69 When there are only two routers on the LAN, it makes more sense to 70 treat the connection between the two routers as a point-to-point 71 circuit. This document describes the mechanism to allow link state 72 routing protocols to operate using point-to-point connections over 73 a LAN under this condition. Some implications related to forwarding 74 IP packets on this type of circuit are also discussed. We will refer 75 to this as a p2p-over-lan circuit in this document. 77 2. Motivation 79 Even though a broadcast circuit is meant to handle more than two 80 devices, there are cases where only two routers are connected 81 over either the physical or logical LAN segment: 83 1. The media itself is being used for point-to-point 84 operation between two routers. This is mainly for 85 long-haul operation. 86 2. There are only two routers on the physical LAN. 87 3. There are only two routers on a virtual LAN (vLAN). 89 In any of the above cases, the link state routing protocols will 90 normally still treat the media as a broadcast circuit. Hence, they 91 will have the overhead involved with protocol LAN operation without 92 the benefits of reducing routing information and optimized flooding. 94 Being able to treat a LAN as a point-to-point circuit provides the 95 benefit of reduction in the amount of information routing 96 protocols must carry and manage. DR/DIS election can be omitted. 97 Flooding can be done as in p2p links without the need of using 98 "LSA reflection" by the DR in OSPF or periodic CSNPs in ISIS. 100 Also, if a broadcast segment wired as a point-to-point link 101 can be treated as a point-to-point link, only the connection between 102 the two routers would need to be advertised as a topological entity. 104 Even when there are multiple routers on the LAN an ISP may want 105 to sub-group the routers into multiple vLANs since this allows 106 them to assign different costs to IGP neighbors. When there are 107 only two routers in some of the vLANs, this LAN can be viewed by 108 the IGP as a mesh of point-to-point connections. 110 As a side benefit, unnumbered interface can also be applied over 111 p2p-over-lan circuits. The advantages of unnumbered point-to-point 112 links are obvious in the current IP addressing environment where 113 addresses are a scarce resource. Separating the concept of network 114 type from media type will allow LANs, e.g. ethernet, to be 115 unnumbered and realize the IP address space savings. Another 116 advantage is in simpler network management and configuration. 118 3. IP multi-access subnets 120 When an IP network includes multi-access segments, each segment is 121 usually assigned a separate subnet and each router connected to it is 122 assigned a distinct IP address within that subnet. The role of the 123 IP address assigned to a multi-access interface can be outlined as 124 follows: 126 1. Source IP address - The interface address can be used by 127 the router as the source IP address in locally originated 128 IP packets destined for that subnet or having a best path 129 next hop on that subnet. 131 2. Destination IP address - The interface address can be used by 132 other devices in the network as a destination address for 133 packets to router applications (examples include telnet, SMTP, 134 TFTP, OSPF, BGP, etc). 136 3. Next-hop identifier - If other routers connected to the same 137 segment need to forward traffic through the router, the 138 corresponding routes in their routing tables will include the 139 router's interface IP address. This address will be used to 140 find the router's MAC address using the ARP protocol. 141 Effectively, the interface IP addresses help other routers 142 find the data-link layer details that are required to specify 143 the destination of the encapsulating data-link frame when it 144 is sent on the segment. 146 The IP addressing scheme includes an option that allows the 147 administrators to not assign any subnets to point-to-point links 148 (links connecting only two devices and using protocols like PPP, SLIP 149 or HDLC for IP encapsulation). This is possible, because the routers 150 do not need next-hop identifiers on point-to-point links (there is 151 only one destination for any transmission), and an interface 152 independent IP address can be used as the source and destination. 153 Using the unnumbered option for a point-to-point link essentially 154 makes it a purely topological entity used only to reach other 155 destinations. 157 4. Point-to-point connection over LAN media 159 The idea is very simple: provide a configuration mechanism to 160 inform the IGP that the circuit is type point-to-point 161 irrespective of the physical media type. For the IGP, this implies 162 that it will send protocol packets with the appropriate 163 point-to-point information and expects to receive protocol packets 164 as they would be received on a point-to-point circuit. Over LAN 165 media, the MAC header must contain the correct multicast MAC address 166 to be received by the other side of the connection. For vLAN 167 environments, the MAC header must also contain the proper vLAN ID. 169 In order to allow LAN links used to connect only two routers to be 170 treated as unnumbered point-to-point interfaces, the MAC address 171 resolution and nexthop IP address issues need to be addressed. 173 4.1 Operation of IS-IS 175 This p2p-over-lan circuit extension for IS-IS is only concerned 176 in pure IP routing and forwarding operation. 178 Since the physically circuit is a broadcast one, the IS-IS protocol 179 packets need to have MAC addresses for this p2p-over-lan circuit. 180 From link layer point of view, those packets are IS-IS LAN packets. 181 The Multi-destination address including AllISs, AllL1ISs and AllL2ISs 182 defined in [ref1] can be used for link layer encapsulation, the 183 use of AllISs is recommended. 185 The circuit needs to have IP address(es) and the p2p IIH over this 186 circuit MUST include the IP interface address(es) as defined in 187 [ref2]. The IP address(es) can be numbered or unnumbered. 189 4.2 Operation of OSPF 191 OSPF routers supporting the capabilities described herein should 192 support an additional interface configuration parameter specifying 193 the interface topology type. For a LAN (i.e., broadcast capable) 194 interface, the interface may be viewed as a point-to-point interface. 195 Both routers on the LAN will simply join the AllSPFRouters 196 (224.0.0.5) multicast group and send all OSPF packets to 224.0.0.5. 197 This is identical to operation over a physical point-to-point link 198 as described in sections 8.1 and 8.2 of [ref3]. 200 4.3 IP forwarding and ARP 202 Unlike normal point-to-point IGP circuit, the IP nexthop for the 203 routes using this p2p-over-lan circuit as an outbound interface is 204 not optional. The IP nexthop address has to be a valid interface 205 or internal address on the adjacent router. This address is used by 206 local router to obtain the MAC address for IP packet forwarding. 207 Proxy ARP has to be enabled if the address is not the adjacent 208 interface IP address. 210 In the case where unnumbered IP addresses are used for p2p-over-lan 211 circuit, the source IP address of ARP request and the target 212 interface IP address are usually on different subnets. The ARP 213 should reply only if this is a p2p-over-lan circuit and the source 214 IP address of the ARP request is the same as the neighbor's 215 interface IP address at the other end. The neighbor's address is 216 learned from IGP hello exchanges over this circuit. 218 4.4 Other MAC address resolution mechanisms 220 In more general cases while p2p-over-lan circuit is used as an 221 unnumbered link, other MAC address resolution mechanisms are needed 222 for IP packet forwarding. For example, if link-state IGP is not 223 configured over this p2p-over-lan link, or Proxy ARP is not enabled 224 on the circuit. The following techniques can be used to acquire the 225 MAC address and/or the next-hop IP address of the remote device on 226 an unnumbered point-to-point LAN link. 228 1. Static configuration. A router can be statically configured 229 with the MAC address that should be used as the destination 230 MAC address when sending data out of the interface. 232 2. MAC address gleaning. If a dynamic routing protocol is running 233 between the routers connected to the link, the MAC address of 234 the remote device can be taken from a data-link frame carrying 235 a packet of the corresponding routing protocol. 237 3. ARP for reference IP address. When a point-to-point link is 238 configured as unnumbered, the router usually associates with 239 it a "reference IP address", that is used as the source IP 240 address in the packets originated for the unnumbered 241 interface. When such an address is known to a router, the 242 router may announce its MAC address by sending a gratuitous 243 ARP message. This solution will also help in the situations 244 where routers calculate the next-hop addresses for the routes 245 through point-to-point interfaces. Since the source IP address 246 in the received routing protocol packet is used as the next- 247 hop address in the route, forwarding an IP packet along such 248 a route will lead to an ARP request submission on the LAN 249 link that will be answered by the remote device. 251 4. Broadcast/multicast/proprietary. 253 4.5 Detection of mis-configuration 255 With this p2p-over-lan extension, the difference between a LAN and 256 a point-to-point circuit can be made purely by configuration. It is 257 important to implement the mechanisms for early detection of 258 mis-configuration. 260 If the circuit is configured as point-to-point type and receives 261 LAN hello packets, the router MUST discard the incoming packets; If 262 the circuit is a LAN type and receive point-to-point hello packets, 263 it MUST discard the incoming packets. If the system ID or the 264 router ID of incoming hello packet does not match the system ID or 265 the router ID of already established adjacency over this p2p-over-lan 266 circuit, it MUST discard the packet. The implementation should offer 267 logging and debugging information of the above events. 269 5. Compatibility considerations 271 Both routers on a LAN must support the p2p-over-lan extension 272 and both must have the LAN segment configured as a p2p-over-lan 273 circuit for successful operation. Both routers MAY also support 274 one of the above listed methods for mapping ip addresses on the 275 link to MAC address, and MUST support proxy ARP on the link. If 276 a proprietary method of IP address to MAC address resolution is 277 used by one router, both routers must be capable of using the 278 same method. Otherwise, the link should be configured as a 279 standard LAN link, with traditional IGP LAN models used. 281 6. Scalability and deployment considerations 283 There is obvious advantage to use this extension on the LANs 284 that are connected back-to-back or only contain two routers. 285 However, there are tradeoffs when modeling a LAN as multiple vLANs 286 and using this extension since one does sacrifice the inherent 287 scalability benefits of multi-access networks. In general, 288 it will increase the link-state database size, the amount of 289 packets flooded and the route calculation overhead. Network design 290 engineers should carefully balance between the associated 291 overhead. The scalability impact is less of a concern if all the 292 vLANs are within a single OSPF area or ISIS level. 294 Deployment of the described technique brings noticeable benefits from 295 the perspective of IP address usage, the network management and the 296 router configuration. Note, however, that use of the IP unnumbered 297 option for point-to-point LAN links inherits the same problems as 298 those present for serial links, i.e., not being able to ping or 299 monitor a specific interface between routers. 301 7. Security Issues 303 This document does not introduce any new security issues to ISIS or 304 OSPF. For ARP to support unnumbered IP interface addresses, it needs 305 to verify the p2p-over-lan circuit type described in this document 306 and to verify the ARP packet source interface address to match the 307 IGP adjacency interface IP address. This is due to normal ARP sanity 308 check for common subnet can not be applied in this case. 310 8. Acknowledgments 312 The authors would like to acknowledge the following individuals: 313 (in last name alphabetical order) Pedro Marques, Christian Martin, 314 Danny McPherson, Ajay Patel, Tony Przygienda and Alvaro Retana. 316 9. References 318 [ref1] ISO. Information Technology - Telecommunications and 319 Information Exchange between Systems - Intermediate System 320 to Intermediate System Routing Exchange Protocol for 321 Use in Conjunction with the Protocol for Providing the 322 Connectionless-Mode Network Service. ISO, 1990. 324 [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 325 Environments. INTERNET-RFC, Internet Engineering Task Force, 326 December 1990. 328 [ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet 329 Engineering Task Force, 1998. 331 10. Authors' Addresses 333 Naiming Shen 334 Redback Networks 335 350 Holger Way 336 San Jose, CA, 95134 USA 337 naiming@redback.com 339 Acee Lindem 340 Redback Networks 341 102 Carric Bend Court 342 Apex, NC 27502 USA 343 acee@redback.com 344 Jenny Yuan 345 Redback Networks 346 350 Holger Way 347 San Jose, CA, 95134 USA 348 jenny@redback.com 350 Alex Zinin 351 Nexsi Systems 352 1959 Concourse Drive 353 San Jose, CA 95131 354 azinin@nexsi.com 356 Russ White 357 Cisco Systems, Inc. 358 7025 Kit Creek Rd. 359 Research Triangle Park, NC 27709 360 e-mail: riw@cisco.com 362 Stefano Previdi 363 Cisco Systems, Inc. 364 De Kleetlaan 6A 365 1831 Diegem - Belgium 366 email: sprevidi@cisco.com