idnits 2.17.1 draft-kato-bgp-ipv6-link-local-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (September 20, 2001) is 8246 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? 'Bates' on line 45 looks like a reference -- Missing reference section? '2000' on line 45 looks like a reference -- Missing reference section? 'Rekhter' on line 54 looks like a reference -- Missing reference section? '1995' on line 239 looks like a reference -- Missing reference section? 'Marques' on line 47 looks like a reference -- Missing reference section? '1999' on line 47 looks like a reference -- Missing reference section? '1996' on line 54 looks like a reference -- Missing reference section? 'Hinden' on line 61 looks like a reference -- Missing reference section? '1998' on line 66 looks like a reference -- Missing reference section? 'Conta' on line 66 looks like a reference -- Missing reference section? 'Malkin' on line 66 looks like a reference -- Missing reference section? '1997' on line 66 looks like a reference -- Missing reference section? 'Draves' on line 124 looks like a reference -- Missing reference section? '2001' on line 191 looks like a reference -- Missing reference section? 'Deering' on line 191 looks like a reference -- Missing reference section? 'Kato' on line 231 looks like a reference -- Missing reference section? 'NSPIXP-6' on line 231 looks like a reference -- Missing reference section? 'IANA' on line 239 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Akira Kato, USC/ISI--WIDE 3 INTERNET-DRAFT Bill Manning, USC/ISI 4 Expires: April 20, 2002 September 20, 2001 6 BGP4+ Peering Using IPv6 Link-local Address 7 draft-kato-bgp-ipv6-link-local-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 The internet-draft will expire in 6 months. The date of expiration will 32 be April 20, 2002. 34 Abstract 36 In IPv6 it is possible to use link-local addresses to specify a E-BGP 37 connection. In this case, no global address space is necessary on a 38 link between two Autonomous systems or on an Internet Exchange point. 39 This memo proposes changes of the protocol defined in RFC2545, and some 40 guidelines of implementation and operation to enable E-BGP sessions 41 using IPv6 link-local addresses. 43 1. Introduction 45 RFC2858 [Bates, 2000] defines multiprotocol extension framework to BGP-4 46 [Rekhter, 1995] and IPv6 specific definition is described in RFC2545 47 [Marques, 1999] . RFC2545 also describes that the transport of BGP-4 48 can be either over IPv4 or IPv6. 50 DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 52 It is intuitive that a E-BGP session is specified by a couple of global 53 addresses because only that style has been feasible solution in IPv4. 54 In IPv4, it is possible to use a private address [Rekhter, 1996] , 55 however, the private address and the global address have syntactically 56 no difference. In IPv4, it is necessary to allocate an address space to 57 a link which connects more than one Autonomous Systems. Such address 58 space is offered by one of the Autonomous Systems on the link or by a 59 third party such as ep.net [Manning, EP.NET] project. 61 In IPv6, notion of address scope has been introduced [Hinden, 1998] . A 62 link-local address has a scope which is only valid within a single link. 63 It is independent from a global address and it remain unchanged in the 64 event of global address renumbering. Due to this property, several ICMP 65 messages are defined so that their source addresses are selected from 66 link-local addresses [Conta, 1998] . RIPng [Malkin, 1997] also uses 67 link-local address for the routing information exchanges. 69 While this memo describes BGP peering with link-local addresses, it does 70 not describe that it must not use a global prefix on each IX. It 71 encourages every implementation support it. We may introduce further 72 guidelines for the global prefix assignment on each IX after we have 73 enough experience on BGP peering with link-local addresses. 75 2. Link-local E-BGP Session 77 Because an E-BGP session, which connects different ASes, is assumed to 78 span over a single link, it is possible to use a pair of link-local 79 addresses to specify the E-BGP session. We call such an E-BGP session 80 as a link-local E-BGP session. In this case, it is not necessary to 81 assign global IPv6 addresses to the link. As IPv6 has a huge address 82 space, address conservation may not be necessary. However, routing 83 space is limited under current routing architecture and wasting routing 84 table entries should be avoided as much as possible. 86 Note: It is possible to specify an BGP session by a combination of a 87 link-local address and a global address. This is no benefit in this 88 configuration and such configuration is out of scope of this memo. 90 Note: It is possible to specify I-BGP session by a couple of link-local 91 addresses. However, I-BGP sessions generally span multiple hops, and 92 the number of subnets internal to an AS can grow up to 65,536, it is 93 natural to use global address. So the following discussions do not 94 apply to I-BGP sessions. 96 In some cases, an E-BGP session may span multiple hops, which is known 97 as ebgp-multihop. In this case, it must to use global or site-local 98 addresses rather than link-local addresses. So the following 99 discussions do not apply. 101 It is possible to exchange IPv6 reachability information in BGP4+ 102 connection using IPv4 transport. If the outbound interface of the E-BGP 103 session has no IPv6 address, it is almost identical to a link-local E- 104 DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 106 BGP session in a sense that no global IPv6 address is specified. With a 107 few exception, following discussions will also apply to this case. 109 By using link-local addresses to specify E-BGP sessions, there are 110 following merits: 112 o It is possible to make DMZ (demilitarized zone) more neutral. None of 113 the ASes connecting to a DMZ has to offer global address space. 115 o The announcement of the DMZ prefix is not recommended. However, if 116 some AS advertises the prefix accidentally, the next-hop calculation 117 in other ASes might be interfered with this announcement and might 118 result in unexpected routing and congestion. By link-local E-BGP 119 sessions, this kind of trouble is inherently avoidable. 121 Note: When an IPv6 node originates packets with global IPv6 destination 122 addresses, including ICMP echo reply and Time Exceed, through an 123 interface without any global IPv6 address, it will pick one of the 124 global address attached to it [Draves, 2001] . 126 3. Protocol Issues 128 According to RFC2545, the next hop field in the MP_REACH_NLRI attribute 129 is defined so that either of the following are acceptable: 131 o One global IPv6 address (Length of the next hop network address is 16) 133 o One global IPv6 address and one link-local IPv6 address (Length of the 134 next hop Network Address is 32) 136 Based on the definition in RFC2545, an global IPv6 address should be 137 specified in the next hop field regardless of the transport of the E-BGP 138 session. When a link-local address is specified in the next hop field, 139 it must be valid on the shared link so that the other end of E-BGP 140 session can forward the traffic to that link-local address. 142 RFC2545 requires that an IPv6 global address must be specified in a part 143 of the next hop field. However, in a link-local E-BGP session, the 144 global IPv6 address is not necessary. It is possible to propose a 145 modification to RFC2545 to relax a rule in the next hop field, however, 146 it may cause a serious interoperability problem. Therefore, this memo 147 proposes the following changes in the behavior of each BGP speaker 148 without changing the packet format on the wire: 150 A) BGP-4 speakers should ignore the IPv6 global address specified in the 151 next hop field in a MP_REACH_NLRI attribute learned over a link-local 152 E-BGP session, provided if it does not match with one of the IPv6 153 global prefixes assigned to the link. (It is possible to assign an 154 IPv6 global prefix to an IX and have a link-local E-BGP session.) 156 B) BGP-4 speakers should not cease the link-local E-BGP session by 157 receiving a MP_REACH_NLRI information with a next hop field including 159 DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 161 only a link-local IPv6 address. 163 4. Implementation Issues 165 Any BGP-4 implementations which are capable to handle IPv6 reachability 166 information should be able to use IPv6 transport for BGP sessions. 167 Furthermore, those implementations should also be able to establish 168 link-local E-BGP sessions. 170 A link-local address has a scope which is limited on a single link. So 171 an IPv6 node with more than one interfaces may see the same link-local 172 address on each interface. There are two such cases: 174 1) The node has more than one interfaces attached to the link. 176 2) Different hosts which happen to have the same link-local address. 178 A +--- N ---+ C +--- N ---+ D 179 | | | | | | | 180 ---+----+---------+--- ---+---+--- ---+----+--- 181 Case 1 Case 2: if C's link-local address is 182 the same as D's link-local address 184 As these configurations are not exceptional, all IPv6 nodes (especially 185 routers and IPv6 hosts which have more than one interfaces) should be 186 able to handle such cases: 188 A) Configuration language is properly designed so that different peers 189 with the same link-local address can be distinguishable. Specifying 190 the link-local address destination including is a good idea 191 [Deering, 2001] . 193 B) BGP-4 implementations should be able to configure, at least per 194 session basis, which IPv6 link-local address is to be filled in the 195 next hop field of MP_REACH_NLRI attributes. This also helps when 196 more than one interfaces are attached to the same link for the 197 purpose of manual load distribution. 199 C) BGP-4 implementations should be able to configure, at least per 200 session basis, which IPv6 global address is to be filled in the next 201 hop field of MP_REACH_NLRI attributes. In the case of link-local E- 202 BGP sessions, arbitrary IPv6 address can be specified while in a 203 typical case an IPv6 global address attached to the node (other 204 interface or loopback) will be specified. 206 D) If more than one interfaces are attached to the same link, the router 207 must not be confused in terms of neighbor discovery context. This 208 also applies a case where the peer node has multiple link-local 209 addresses on the same interface (they share the same layer-2 210 destination address). 212 DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 214 Note that D) should not be written in here but to IPv6 host/router 215 requirement documents. Until they are established, it remain here not 216 to be forgotten. 218 5. Operational Hints 220 5.1. Example at NSPIXP-6 222 In IPv6, a link-local address derived from the EUI-64 address of the 223 interface is used in most cases. It is not recommended to use this 224 EUI-64 derived link-local address in BGP because extensive BGP 225 reconfiguration will be necessary when the hardware is replaced due to 226 failure or to upgrade. In a E-BGP speaker, large amount of 227 configuration is necessary including routing protocols configuration, 228 prefix filters, and packet filters. So there is no reason to persist 229 auto configuration of the link-local address in BGP speakers. 231 In NSPIXP-6 [Kato, NSPIXP-6] , it is suggested to use link-local 232 addresses of the following format: 234 fe80::ASN:ID 236 where ASN is the AS number, and ID is arbitrary 16bit number defined by 237 the AS and it identifies more than one routers from single AS attached 238 to the IX. This technique is similar to the Net39 experiment in 1995 239 [IANA, 1995] . For example, one of the router of AS2500 may use 241 fe80::9c4:12 243 When 32bit AS number is in use, it can naturally be extended to 245 fe80::ASN-high:ASN-low:ID 247 Not all of the implementations support IPv6 link-local E-BGP, the above 248 form of E-BGP configurations are used among a limited set of the routers 249 on NSPIXP-6 as of writing. 251 5.2. Network administration issue 253 By using link-local addresses at an IX, it might introduce some 254 difficulty on troubleshooting that it is not possible to ping the 255 router's interface on the IX from remote locations. As announcing 256 router advertisement is highly discouraged on an IX, every router may 257 have IPv6 arbitrary (different) global address. So each AS may 258 independently allocate a /64 prefix on the IX from the AS's available 259 address space and assign the interfaces of the routers of the the AS. 260 Because BGP4+ peering is specified by link-local addresses, assignment 261 of independent global prefixes does not affect the peering. 263 DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 265 6. Address Allocation Guidelines 267 There are discussions regarding global address assignment to an IX. 268 Recent discussions in APNIC and RIPE/NCC communities converge to assign 269 a small global address space (in the case of APNIC a /64) to an IX. 270 ep.net assigns a /64 to participating IXes. 272 With this memo, the authors are not immediately against the assignment 273 of global IPv6 addresses to the link shared by more than one E-BGP 274 speakers. This is because there isn't enough experience of the link- 275 local E-BGP sessions and because not all of the implementations support 276 this functionality at the present time. It is suggested to review this 277 particular guideline in future, when there is more experience with this 278 technique. 280 7. Security Consideration 282 Security issues are not discussed in this memo. 284 8. IANA Consideration 286 There is no IANA consideration in this memo. 288 9. Acknowledgement 290 The authors would like to thank Jun-ichiro itojun Hagino, Tatsuya 291 Jinmei, Chris Fletcher, Jake Khuon, Barbara Roseman for valuable 292 comments and suggestions. 294 Authors' addresses 296 Akira Kato 297 USC/ISI & WIDE Project 298 4676 Admiralty Way 299 Marina del Rey, CA 90292, USA 300 Tel: +1 310-448-9327 301 Email: kato@wide.ad.jp 303 Bill Manning 304 USC/ISI 305 4676 Admiralty Way 306 Marina del Rey, CA 90292, USA 307 Tel: +1 310-822-1511 308 Email: bmanning@isi.edu 310 References 312 Bates, 2000. 313 T. Bates, Y. Rekhter, R. Chandra, and D. Katz, "Multiprotocol Extensions 314 for BGP-4" in RFC2858 (June 2000). ftp://ftp.isi.edu/in- 315 DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 317 notes/rfc2858.txt. 319 Rekhter, 1995. 320 Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)" in RFC1771 321 (March 1995). ftp://ftp.isi.edu/in-notes/rfc1771.txt. 323 Marques, 1999. 324 P. Marques and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for 325 IPv6 Inter-Domain Routing" in RFC2545 (March 1999). 326 ftp://ftp.isi.edu/in-notes/rfc2545.txt. 328 Rekhter, 1996. 329 Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, 330 Address Allocation for Private Internets (February 1996). 331 ftp://ftp.isi.edu/in-notes/rfc1918.txt. 333 Manning, EP.NET. 334 Bill Manning, EP.NET (EP.NET). http://www.ep.net/. 336 Hinden, 1998. 337 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 338 RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 340 Conta, 1998. 341 A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for 342 the Internet Protocol Version 6 (IPv6) Specification" in RFC2463 343 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2463.txt. 345 Malkin, 1997. 346 G. Malkin and R. Minnear, "RIPng for IPv6" in RFC2080 (January 1997). 347 ftp://ftp.isi.edu/in-notes/rfc2080.txt. 349 Draves, 2001. 350 R. Draves, "Default Address Selection for IPv6" in draft-ietf-ipngwg- 351 default-addr-select-05.txt (June 2001). work in progress material. 353 Deering, 2001. 354 S. Deering, B. Haberman, T. Jinmei, E. Nordmark, A. Onoe, and B. Zill, 355 "IPv6 Scoped Address Architecture" in draft-ietf-ipngwg-scoping- 356 arch-02.txt (March 2001). work in progress material. 358 Kato, NSPIXP-6. 359 Akira Kato, NSPIXP-6 (NSPIXP-6). http://www.wide.ad.jp/nspixp6/. 361 IANA, 1995. 362 IANA, "Class A Subnet Experiment" in RFC1797 (April 1995). 363 ftp://ftp.isi.edu/inotes/rfc1797.txt.