Internet Engineering Task Force Akira Kato, USC/ISI--WIDE INTERNET-DRAFT Bill Manning, USC/ISI Expires: April 20, 2002 September 20, 2001 BGP4+ Peering Using IPv6 Link-local Address draft-kato-bgp-ipv6-link-local-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be April 20, 2002. Abstract In IPv6 it is possible to use link-local addresses to specify a E-BGP connection. In this case, no global address space is necessary on a link between two Autonomous systems or on an Internet Exchange point. This memo proposes changes of the protocol defined in RFC2545, and some guidelines of implementation and operation to enable E-BGP sessions using IPv6 link-local addresses. 1. Introduction RFC2858 [Bates, 2000] defines multiprotocol extension framework to BGP-4 [Rekhter, 1995] and IPv6 specific definition is described in RFC2545 [Marques, 1999] . RFC2545 also describes that the transport of BGP-4 can be either over IPv4 or IPv6. KATO, MANNING Expires: April 20, 2002 [Page 1] DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 It is intuitive that a E-BGP session is specified by a couple of global addresses because only that style has been feasible solution in IPv4. In IPv4, it is possible to use a private address [Rekhter, 1996] , however, the private address and the global address have syntactically no difference. In IPv4, it is necessary to allocate an address space to a link which connects more than one Autonomous Systems. Such address space is offered by one of the Autonomous Systems on the link or by a third party such as ep.net [Manning, EP.NET] project. In IPv6, notion of address scope has been introduced [Hinden, 1998] . A link-local address has a scope which is only valid within a single link. It is independent from a global address and it remain unchanged in the event of global address renumbering. Due to this property, several ICMP messages are defined so that their source addresses are selected from link-local addresses [Conta, 1998] . RIPng [Malkin, 1997] also uses link-local address for the routing information exchanges. While this memo describes BGP peering with link-local addresses, it does not describe that it must not use a global prefix on each IX. It encourages every implementation support it. We may introduce further guidelines for the global prefix assignment on each IX after we have enough experience on BGP peering with link-local addresses. 2. Link-local E-BGP Session Because an E-BGP session, which connects different ASes, is assumed to span over a single link, it is possible to use a pair of link-local addresses to specify the E-BGP session. We call such an E-BGP session as a link-local E-BGP session. In this case, it is not necessary to assign global IPv6 addresses to the link. As IPv6 has a huge address space, address conservation may not be necessary. However, routing space is limited under current routing architecture and wasting routing table entries should be avoided as much as possible. Note: It is possible to specify an BGP session by a combination of a link-local address and a global address. This is no benefit in this configuration and such configuration is out of scope of this memo. Note: It is possible to specify I-BGP session by a couple of link-local addresses. However, I-BGP sessions generally span multiple hops, and the number of subnets internal to an AS can grow up to 65,536, it is natural to use global address. So the following discussions do not apply to I-BGP sessions. In some cases, an E-BGP session may span multiple hops, which is known as ebgp-multihop. In this case, it must to use global or site-local addresses rather than link-local addresses. So the following discussions do not apply. It is possible to exchange IPv6 reachability information in BGP4+ connection using IPv4 transport. If the outbound interface of the E-BGP session has no IPv6 address, it is almost identical to a link-local E- KATO, MANNING Expires: April 20, 2002 [Page 2] DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 BGP session in a sense that no global IPv6 address is specified. With a few exception, following discussions will also apply to this case. By using link-local addresses to specify E-BGP sessions, there are following merits: o It is possible to make DMZ (demilitarized zone) more neutral. None of the ASes connecting to a DMZ has to offer global address space. o The announcement of the DMZ prefix is not recommended. However, if some AS advertises the prefix accidentally, the next-hop calculation in other ASes might be interfered with this announcement and might result in unexpected routing and congestion. By link-local E-BGP sessions, this kind of trouble is inherently avoidable. Note: When an IPv6 node originates packets with global IPv6 destination addresses, including ICMP echo reply and Time Exceed, through an interface without any global IPv6 address, it will pick one of the global address attached to it [Draves, 2001] . 3. Protocol Issues According to RFC2545, the next hop field in the MP_REACH_NLRI attribute is defined so that either of the following are acceptable: o One global IPv6 address (Length of the next hop network address is 16) o One global IPv6 address and one link-local IPv6 address (Length of the next hop Network Address is 32) Based on the definition in RFC2545, an global IPv6 address should be specified in the next hop field regardless of the transport of the E-BGP session. When a link-local address is specified in the next hop field, it must be valid on the shared link so that the other end of E-BGP session can forward the traffic to that link-local address. RFC2545 requires that an IPv6 global address must be specified in a part of the next hop field. However, in a link-local E-BGP session, the global IPv6 address is not necessary. It is possible to propose a modification to RFC2545 to relax a rule in the next hop field, however, it may cause a serious interoperability problem. Therefore, this memo proposes the following changes in the behavior of each BGP speaker without changing the packet format on the wire: A) BGP-4 speakers should ignore the IPv6 global address specified in the next hop field in a MP_REACH_NLRI attribute learned over a link-local E-BGP session, provided if it does not match with one of the IPv6 global prefixes assigned to the link. (It is possible to assign an IPv6 global prefix to an IX and have a link-local E-BGP session.) B) BGP-4 speakers should not cease the link-local E-BGP session by receiving a MP_REACH_NLRI information with a next hop field including KATO, MANNING Expires: April 20, 2002 [Page 3] DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 only a link-local IPv6 address. 4. Implementation Issues Any BGP-4 implementations which are capable to handle IPv6 reachability information should be able to use IPv6 transport for BGP sessions. Furthermore, those implementations should also be able to establish link-local E-BGP sessions. A link-local address has a scope which is limited on a single link. So an IPv6 node with more than one interfaces may see the same link-local address on each interface. There are two such cases: 1) The node has more than one interfaces attached to the link. 2) Different hosts which happen to have the same link-local address. A +--- N ---+ C +--- N ---+ D | | | | | | | ---+----+---------+--- ---+---+--- ---+----+--- Case 1 Case 2: if C's link-local address is the same as D's link-local address As these configurations are not exceptional, all IPv6 nodes (especially routers and IPv6 hosts which have more than one interfaces) should be able to handle such cases: A) Configuration language is properly designed so that different peers with the same link-local address can be distinguishable. Specifying the link-local address destination including is a good idea [Deering, 2001] . B) BGP-4 implementations should be able to configure, at least per session basis, which IPv6 link-local address is to be filled in the next hop field of MP_REACH_NLRI attributes. This also helps when more than one interfaces are attached to the same link for the purpose of manual load distribution. C) BGP-4 implementations should be able to configure, at least per session basis, which IPv6 global address is to be filled in the next hop field of MP_REACH_NLRI attributes. In the case of link-local E- BGP sessions, arbitrary IPv6 address can be specified while in a typical case an IPv6 global address attached to the node (other interface or loopback) will be specified. D) If more than one interfaces are attached to the same link, the router must not be confused in terms of neighbor discovery context. This also applies a case where the peer node has multiple link-local addresses on the same interface (they share the same layer-2 destination address). KATO, MANNING Expires: April 20, 2002 [Page 4] DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 Note that D) should not be written in here but to IPv6 host/router requirement documents. Until they are established, it remain here not to be forgotten. 5. Operational Hints 5.1. Example at NSPIXP-6 In IPv6, a link-local address derived from the EUI-64 address of the interface is used in most cases. It is not recommended to use this EUI-64 derived link-local address in BGP because extensive BGP reconfiguration will be necessary when the hardware is replaced due to failure or to upgrade. In a E-BGP speaker, large amount of configuration is necessary including routing protocols configuration, prefix filters, and packet filters. So there is no reason to persist auto configuration of the link-local address in BGP speakers. In NSPIXP-6 [Kato, NSPIXP-6] , it is suggested to use link-local addresses of the following format: fe80::ASN:ID where ASN is the AS number, and ID is arbitrary 16bit number defined by the AS and it identifies more than one routers from single AS attached to the IX. This technique is similar to the Net39 experiment in 1995 [IANA, 1995] . For example, one of the router of AS2500 may use fe80::9c4:12 When 32bit AS number is in use, it can naturally be extended to fe80::ASN-high:ASN-low:ID Not all of the implementations support IPv6 link-local E-BGP, the above form of E-BGP configurations are used among a limited set of the routers on NSPIXP-6 as of writing. 5.2. Network administration issue By using link-local addresses at an IX, it might introduce some difficulty on troubleshooting that it is not possible to ping the router's interface on the IX from remote locations. As announcing router advertisement is highly discouraged on an IX, every router may have IPv6 arbitrary (different) global address. So each AS may independently allocate a /64 prefix on the IX from the AS's available address space and assign the interfaces of the routers of the the AS. Because BGP4+ peering is specified by link-local addresses, assignment of independent global prefixes does not affect the peering. KATO, MANNING Expires: April 20, 2002 [Page 5] DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 6. Address Allocation Guidelines There are discussions regarding global address assignment to an IX. Recent discussions in APNIC and RIPE/NCC communities converge to assign a small global address space (in the case of APNIC a /64) to an IX. ep.net assigns a /64 to participating IXes. With this memo, the authors are not immediately against the assignment of global IPv6 addresses to the link shared by more than one E-BGP speakers. This is because there isn't enough experience of the link- local E-BGP sessions and because not all of the implementations support this functionality at the present time. It is suggested to review this particular guideline in future, when there is more experience with this technique. 7. Security Consideration Security issues are not discussed in this memo. 8. IANA Consideration There is no IANA consideration in this memo. 9. Acknowledgement The authors would like to thank Jun-ichiro itojun Hagino, Tatsuya Jinmei, Chris Fletcher, Jake Khuon, Barbara Roseman for valuable comments and suggestions. Authors' addresses Akira Kato USC/ISI & WIDE Project 4676 Admiralty Way Marina del Rey, CA 90292, USA Tel: +1 310-448-9327 Email: kato@wide.ad.jp Bill Manning USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292, USA Tel: +1 310-822-1511 Email: bmanning@isi.edu References Bates, 2000. T. Bates, Y. Rekhter, R. Chandra, and D. Katz, "Multiprotocol Extensions for BGP-4" in RFC2858 (June 2000). ftp://ftp.isi.edu/in- KATO, MANNING Expires: April 20, 2002 [Page 6] DRAFT BGP4+ Peering Using IPv6 Link-local AddresseSeptember 2001 notes/rfc2858.txt. Rekhter, 1995. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)" in RFC1771 (March 1995). ftp://ftp.isi.edu/in-notes/rfc1771.txt. Marques, 1999. P. Marques and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing" in RFC2545 (March 1999). ftp://ftp.isi.edu/in-notes/rfc2545.txt. Rekhter, 1996. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, Address Allocation for Private Internets (February 1996). ftp://ftp.isi.edu/in-notes/rfc1918.txt. Manning, EP.NET. Bill Manning, EP.NET (EP.NET). http://www.ep.net/. Hinden, 1998. R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. Conta, 1998. A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" in RFC2463 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2463.txt. Malkin, 1997. G. Malkin and R. Minnear, "RIPng for IPv6" in RFC2080 (January 1997). ftp://ftp.isi.edu/in-notes/rfc2080.txt. Draves, 2001. R. Draves, "Default Address Selection for IPv6" in draft-ietf-ipngwg- default-addr-select-05.txt (June 2001). work in progress material. Deering, 2001. S. Deering, B. Haberman, T. Jinmei, E. Nordmark, A. Onoe, and B. Zill, "IPv6 Scoped Address Architecture" in draft-ietf-ipngwg-scoping- arch-02.txt (March 2001). work in progress material. Kato, NSPIXP-6. Akira Kato, NSPIXP-6 (NSPIXP-6). http://www.wide.ad.jp/nspixp6/. IANA, 1995. IANA, "Class A Subnet Experiment" in RFC1797 (April 1995). ftp://ftp.isi.edu/inotes/rfc1797.txt. KATO, MANNING Expires: April 20, 2002 [Page 7]