idnits 2.17.1 draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt: 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-04-25) 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: ---------------------------------------------------------------------------- ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 180 lines 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 ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 81: '... SHOULD be used if the router ID ...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2858 (ref. '2') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2796 (ref. '4') (Obsoleted by RFC 4456) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Francis Dupont 3 INTERNET DRAFT ENST Bretagne 4 Expires in July 2002 Alain Durand 5 January 2. 2002 7 BGP4 router ID for IPv6 only routers 9 11 Status of this Memo 13 This document is an Internet Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Distribution of this memo is unlimited. 35 Abstract 37 BGP4 [1] uses a 32 bit field to identify router (the so called 38 "router-IDs"). In IPv4 domain, an IPv4 address of the router 39 is typically used in this field. 40 In an IPv6 routing domain, routers may very well not have any IPv4 41 Addresses. This document provides a simple way to form a globally 42 Unique ID in such a case. 44 1. Introduction 46 BGP4 [1] extension for IPv6 are defined in [2] and [3]. 47 However, BGP4 uses a 32 bit field known as the router ID. 48 This router ID is used in: 50 BGP4 [1] uses the router ID as an identifier in: 51 - BGP Identifier in OPEN messages (local use) 52 - AGGREGATOR (optional transitive) attributes 53 - ORIGINATOR_ID (optional non-transitive) attributes [4] 54 - CLUSTER_LIST (optional non-transitive) attributes [4] 56 The AGGREGATOR attributes contain an Autonomous 57 System (AS) number with the IP address of the BGP speaker 58 that formed the aggregate route. It is the only transitive, 59 (i.e. non local) use of the router ID. 61 The router ID should be somehow unique and BGP implementations 62 should provide a way to manually set it. This field typically 63 contains one of the IPv4 addresses of the BGP4 speaker. 64 In an IPv6 domain, some router may have IPv4 addresses, 65 and some other may very well not have any. On those routers, 66 one can not assigned random values to the router ID, as it could 67 conflict with the router ID derived from an IPv4 addresses on 68 another dual stack router. 70 This document specifies a simple way to construct a somehow 71 globally unique 32 bit router ID. 73 2. Recommended practice 75 In the absence of a globally unique IPv4 address on the router, 76 the 32 bit routing ID may be constructed with: 78 - 4 bits set to one (as for an old reserved class E IPv4 address), 80 - 16 bits set to the AS number (a global AS number 81 SHOULD be used if the router ID can be seen outside the routing 82 domain). 84 - 12 bits manually allocated within the domain. This allows for 4096 85 different router IDs in each routing domain. 87 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 88 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 89 +-------+-------------------------------+-----------------------+ 90 | | | | 91 | 0xF | AS Number | Locally allocated | 92 | | | | 93 +-------+-------------------------------+-----------------------+ 95 Note: 32 bit AS numbers could be introduced in the future. 96 This recommended solution would then have to be adapted. 98 3. Security Considerations 100 The usage of fake IPv4 address of this form minimizes accidental 101 or deliberate confusions (ie. same router ID for two different 102 BGP speakers). 104 4. References 106 [1] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", 107 RFC 1771, March 1995. 109 [2] T. Bates, Y. Rekhter, R. Chandra, D. Katz, "Multiprotocol 110 Extensions for BGP-4", RFC 2858, June 2000. 112 [3] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol Extensions 113 for IPv6 Inter-Domain Routing", RFC 2545, March 1999. 115 [4] T. Bates, R. Chandra, E. Chen, "BGP Route Reflection - 116 An Alternative to Full Mesh IBGP", RFC 2796, April 2000. 118 5. Author's Address 120 Francis Dupont 121 ENST Bretagne 122 Campus de Rennes 123 2, rue de la Chataigneraie 124 BP 78 125 35512 Cesson-Sevigne Cedex 126 FRANCE 127 Fax: +33 2 99 12 70 30 128 EMail: Francis.Dupont@enst-bretagne.fr 130 Alain Durand 131 SUN Microsystems, Inc 132 901 San Antonio Road 133 MPK17-202 134 Palo Alto, CA 94303-4900 135 USA 136 EMail: Alain.Durand@sun.com 138 Expire in 6 months (July 3, 2002)