idnits 2.17.1 draft-ietf-idr-bgp4-ipv6-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([BGP-MP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (February 1998) is 9529 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) == Unused Reference: 'IPv6' is defined on line 168, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDR-ARCH' ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-MP' ** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'ND' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pedro R. Marques 3 Internet Draft cisco Systems, Inc. 4 Expiration Date: August 1998 5 Francis Dupont 6 Inria 8 February 1998 10 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing 12 draft-ietf-idr-bgp4-ipv6-01.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 1. Abstract 34 BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP 35 attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to 36 announce and withdraw the announcement of reachability information. 37 This document defines how compliant systems should make use of those 38 attributes for the purpose of conveying IPv6 routing information. 40 2. Introduction 42 The BGP-4 protocol [BGP-4] in particular, and path vector routing 43 protocols in general, are mostly independent of the particular 44 Address Family for which the protocol is being used. 46 IPv6 falls under the generic category of protocols for which BGP-4 is 47 suitable and, unless stated otherwise in this document, the BGP-4 48 procedures to apply when using BGP-4 to carry IPv6 reachability 49 information are those defined in [BGP-4] and in subsequent documents 50 that extend or update the BGP-4 specification. 52 In terms of routing information, the most significant difference 53 between IPv6 and IPv4 (for which BGP was originally designed) is the 54 fact that IPv6 introduces scoped unicast addresses and defines 55 particular situations when a particular address scope must be used. 56 This document concerns itself essentially with the necessary rules to 57 accommodate IPv6 address scope requirements. 59 3. IPv6 Address Scopes 61 IPv6 defines 3 unicast address scopes [ADDR-ARCH]: global, site-local 62 and link-local. Site-local addresses are non-link-local address which 63 are valid within the scope of a "site" and cannot be exported beyond 64 it. As this document makes no assumption on the characteristics of a 65 particular routing realm where BGP-4 is used, it makes no distinction 66 between global and site-local addresses and refers to both as 67 "global" or "non-link-local". Network administrators must however 68 respect address scope restrictions and should be aware that the 69 concepts of a BGP-4 routing domain and "site" are orthogonal notions 70 and that they may or may not coincide in a given situation. 72 Companion IPv6 specifications further define that only link-local 73 address can be used when generating ICMP Redirect Messages [ND] and 74 as next hop addresses in some routing protocols (eg. RIPng [RIP]). 76 This restrictions does imply that an IPv6 router must have a link- 77 local next hop address for all directly connected routes (routes for 78 which the given router and the next hop router share a common subnet 79 prefix). 81 Link-local addresses are not, however, well suited to be used as next 82 hop attributes in BGP-4 given the rules defined for this attribute in 83 the protocol specification [BGP-4]. 85 For the above reasons, when BGP-4 is used to convey IPv6 reachability 86 information it is sometimes necessary to announce a next hop 87 attribute that consists of a global address and a link-local address. 88 The following section describes the rules that should be followed 89 when constructing the Network Address of Next Hop field of an 90 MP_REACH_NLRI attribute. 92 4. Constructing the Next Hop field 94 A BGP speaker shall advertise to its peer in the Network Address of 95 Next Hop field the global IPv6 address of the next hop, potentially 96 followed by the link-local IPv6 address of the next hop. 98 The value of the Length of Next Hop Network Address field on a 99 MP_REACH_NLRI attribute shall be set to 16, when only a global 100 address is present, or 32 if a link-local address is also included in 101 the Next Hop field. 103 The link-local address shall be included in the Next Hop field if and 104 only if the BGP speaker shares a common subnet with the entity 105 identified by the global IPv6 address carried in the Network Address 106 of Next Hop field and the peer the route is being advertised to. 108 In all other cases a BGP speaker shall advertise to its peer in the 109 Network Address field only the global IPv6 address of the next hop 110 (the value of the Length of Network Address of Next Hop field shall 111 be set to 16). 113 As a consequence, a BGP speaker that advertises a route to an 114 internal peer may modify the Network Address of Next Hop field by 115 removing the link-local IPv6 address of the next hop. 117 5. Transport 119 TCP connections, on top of which BGP-4 messages are exchanged, can be 120 established either over IPv4 or IPv6. While BGP-4 itself is 121 independent of the particular transport used it derives implicit 122 configuration information from the address used to establish the 123 peering session. This information (the network address of a peer) is 124 taken in account in the route dissemination procedure. Thus, when 125 using TCP over IPv4 as a transport for IPv6 reachability information, 126 additional explicit configuration of the peer's network address is 127 required. 129 Note that the information referred above is distinct from the BGP 130 Identifier used in the BGP-4 tie breaking procedure. The BGP 131 Identifier is a 32 bit unsigned integer exchanged between two peers 132 at session establishment time, within an OPEN message. This is a 133 system wide value determined at startup which must be unique in the 134 network and should be derived from an IPv4 address regardless of the 135 network protocol(s) a particular BGP-4 instance is configured to 136 convey at a given moment. 138 The use of TCP over IPv6 as transport protocol for IPv6 reachability 139 information also has the advantage of providing explicit confirmation 140 of IPv6 network reachability between two peers. 142 6. Security Considerations 144 The extensions defined in this document allow BGP to propagate 145 reachability information about IPv6 routes. As such, no new security 146 issues are raised beyond those that already exist in BGP-4 and its 147 use with IPv4. 149 7. Acknowledgments 151 This document derives from the work on BGP-4 Multiprotocol Extensions 152 by Tony Bates, Ravi Chandra, Dave Katz and Yakov Rekhter. 154 8. References 156 [ADDR-ARCH] "IP Version 6 Addressing Architecture", 157 S. Deering and R. Hiden, Internet Draft, January 1998. 158 160 [BGP-4] "A Border Gateway Protocol 4 (BGP-4)", 161 Y. Rekhter and T. Li, RFC1771, March 1995. 163 [BGP-MP] "Multiprotocol Extensions for BGP-4", 164 T. Bates, R. Chandra, D. Katz, and Y. Rekhter, 165 Internet Draft, January 1998. 166 168 [IPv6] "Internet Protocol, Version 6 (IPv6) Specification", 169 S. Deering and R. Hiden, RFC1883, December 1995. 171 [ND] "Neighbor Discovery for IP Version 6 (IPv6)", 172 T. Narten, E. Nordmark and W. Simpson, 173 Internet Draft, November 1997. 174 176 [RIP] "RIPng for IPv6", 177 G. Malkin and R. Minnear, RFC 2080, January 1997. 179 9. Author Information 181 Pedro R. Marques 182 cisco Systems, Inc. 183 170 W. Tasman Dr. 184 San Jose, CA 95134 186 email: roque@cisco.com 188 Francis Dupont 189 INRIA Rocquencourt 190 Domaine de Voluceau 191 BP 105 192 78153 Le Chesnay CEDEX 193 France 195 email: Francis.Dupont@inria.fr