idnits 2.17.1 draft-ietf-idr-idrp-v4v6-02.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-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 6 months document validity. ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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 2 instances of too long lines in the document, the longest one being 17 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 54 has weird spacing: '... This docum...' == Line 65 has weird spacing: '... This docum...' == Line 132 has weird spacing: '...ctivity betwe...' == Line 134 has weird spacing: '...ia some intra...' == Line 141 has weird spacing: '... can be easil...' == (12 more instances...) -- 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 (January 1996) is 10291 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) ** Downref: Normative reference to an Unknown state RFC: RFC 1104 (ref. '1') ** Obsolete normative reference: RFC 1519 (ref. '2') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1883 (ref. '3') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1884 (ref. '4') (Obsoleted by RFC 2373) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1655 (ref. '9') (Obsoleted by RFC 1772) ** Obsolete normative reference: RFC 1654 (ref. '10') (Obsoleted by RFC 1771) ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '11') ** Downref: Normative reference to an Informational RFC: RFC 1887 (ref. '12') Summary: 19 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Interdomain Routing Working Group Yakov Rekhter 2 Internet Draft cisco Systems 3 Paul Traina 4 cisco Systems 5 January 1996 7 IDRP for IP v4 and v6 9 Status of this memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 22 Please check the 1id-abstracts.txt listing contained in the 23 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 24 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 25 current status of any Internet Draft. 27 1 Overview 29 IDRP [5] is defined as the protocol for exchange of Inter-Domain 30 routing information between routers to support forwarding of ISO 8473 31 (Connectionless Network Layer Protocol (CLNP))[6] packets. 33 The network reachability information exchanged via IDRP provides 34 sufficient information to detect routing loops and enforce routing 35 decisions based on performance preference and policy constraints as 36 outlined in RFC 1104 [1]. In particular, IDRP exchanges routing 37 information containing full domain-level paths and enforces routing 38 policies based on configuration information. 40 IDRP may be viewed as an extension of BGP-4 ([9], [10]) that provides 41 (among other things) much better scaling with respect to support for 42 routing information aggregation based on CIDR ([2], [11]), as well as 43 stronger capabilities for policy based routing (e.g. ability to 44 impose control over transit traffic). Enhanced scaling capabilities 45 are provided via the concept of Routing Domain Confederations (RDCs), 46 that allow to express both topology and policy information in terms 47 of aggregates (confederations) rather than individual entities 48 (domains). IDRP also provides capability to carry reachability and 49 RFC DRAFT January 1996 51 forwarding information associated with multiple network layer 52 protocols (e.g. IPv6, IPv4). 54 This document contains the adaptation of the IDRP protocol 55 definition that enables it to be used as a protocol for the exchange 56 of inter-domain system routing information among routers to support 57 the forwarding of IPv6 packets across multiple domains. We refer to 58 IDRP with this adaptation as "IDRP for IPv6". While this document 59 doesn't cover use of IDRP to support routing for other network layer 60 protocols (e.g. IPv4), it is expected that IDRP for IPv6 will be able 61 to operate in a multiprotocol environment as well. 63 2 Terminology 65 This document assumes that the reader is familiar with the following 66 documents: 68 IPv6 protocol specification [3], IPv6 Addressing Architecture [4], 69 and IDRP specification (IS 10747) [5]. 71 A few definitions are in order to aid the reader: 73 BIS - a Boundary Intermediate System (or border router) 75 BISPDU - an IDRP message exchanged between a pair of BISs 77 ES - End System (host) 79 FIB - Forwarding Information Base (IP forwarding table) 81 IS - Intermediate System (router) 83 NET - Network Entity Title (a network layer address for a router) 85 NLRI - Network Layer Reachability Information (set of reachable 86 destinations) 88 NPDU - an IPv6 packet 90 NSAP - Network Service Access Point (a network layer address) 92 PDU - a packet 94 SNPA - subnetwork point of attachment (Data Link address) 96 It is expected that the above definitions should be adequate for 97 understanding of IDRP. Familiarity with any of the documents listed 98 in the normative references of the protocol specifications (section 2 99 of [5]) is not required. 101 Unless stated otherwise here, any reference to the above terms in [5] 102 RFC DRAFT January 1996 104 should be interpreted based on the above definitions. 106 3 The Adaptation Layer 108 The Inter-Domain Routing Protocol (IDRP) or, more formally, 110 "The Protocol for the Exchange of Inter-Domain Routing information 111 among Intermediate Systems to support Forwarding of ISO 8473 PDUs 112 (IDRP)" 114 is the inter-domain routing protocol defined to support the 115 forwarding of Connectionless Network Layer Protocol (CLNP) [6] 116 packets that traverse multiple routing domains. 118 IDRP document [5] covers both the protocol specifications and the 119 usage issues (which is in contrast to BGP-4 documentation that has a 120 separate document that defines the protocol [10], and a separate 121 document that describes the protocol's usage [9]). 123 While IDRP was developed within ISO, it makes few, if any, ISO- 124 specific assumptions. In particular, it does not require 125 participating domains to support any specific ISO Intra-Domain 126 protocol, such as IS-IS [7], nor does it require participating 127 routers to run ES-IS [8]. 129 The only requirements imposed by the protocol on the participating 130 routers is that the protocol information can be exchanged among them 131 over a connectionless network layer (which in the case of OSI is 132 CLNP), and that the network layer connectivity between routers 133 within a single routing domain should be provided by means outside of 134 IDRP (e.g., via some intra-domain routing protocol). IDRP does not 135 place any restrictions on the structure of reachability information, 136 as long it can be expressed as an arbitrary set of variable length 137 address prefixes. 139 Since IPv4 and IPv6 can provide connectionless service between 140 routers, and since reachable IPv4/IPv6 destinations can be expressed 141 as IP address prefixes, IDRP can be easily adapted to be an inter- 142 domain routing protocol which can be used in the IP Internet. 144 The adaptation described in this document consists of: specifying the 145 parts of the protocol that are not needed, specifying 146 modifications/clarifications to certain parts of the protocol to 147 reflect IP specifics and operational experience with BGP-4, adding 148 new features to reflect operational experience with BGP-4. 150 4 Features in IDRP which shall not be implemented 152 The following lists the functions that shall not be implemented by 153 RFC DRAFT January 1996 155 IDRP for IPv4 an IPv6 (all references are with respect to [5]): 157 Support for distinguishing path attributes according to sections 5.7, 158 7.11.2 and 7.11.3 Expense according to section 7.12.10 Security 159 according to section 7.12.14 Priority according to section 7.12.16 160 Procedures for detecting inconsistent routing decisions, according to 161 section 7.15.1 Forwarding CLNP packets according to section 8 The 162 interface to CLNP according to section 9 support of the Network 163 Management information described in the IDRP GDMO according to 164 section 11 166 All the material presented in the sections listed above may be 167 ignored. 169 5 Features in IDRP which shall be implemented 171 An implementation of IDRP for IPv4 and IPv6 shall contain all 172 mandatory features 173 of IDRP, except those mentioned in section 4 of this document. In 174 addition, a BIS for IDRP for IPv4 and IPv6 shall implement the 175 following (all references are with respect to this document): 177 an interface to the IPv4 and IPv6 protocol, as described in section 178 5.1 Modifications to the encoding of reachability and forwarding 179 information, as well as the ability to identify and extract IPv4 and 180 IPv6 reachability and forwarding information as described in sections 181 5.2 and 5.3 Modifications to the ROUTE_SEPARATOR and 182 MULTI_EXIT_DISCRIMINATOR path attributes, as described in section 5.4 183 Support for the ATOMIC_AGGREGATE path attribute, as described in 184 section 5.5 Modifications to the tie-breaking procedures, as 185 described in sections 5.6 Modifications to handling Hold Time, as 186 described in section 5.7 Constructing forwarding address (next hop), 187 as described in section 5.8 Modifications to the UPDATE PDU format, 188 as described in section 5.9 Modifications to the OPEN PDU format, as 189 described in section 5.10 Modifications to the RIB REFRESH PDU 190 format, as described in section 5.11 New Error Subcodes, as described 191 in section 5.12 193 Naming and addressing conventions discussed in sections 5.10, 5.11 194 and 7.1 of [5] do not apply to IDRP for IPv4 and IPv6, and thus 195 should be ignored. Section 6 of this document contains the material 196 that covers naming and addressing conventions for IDRP for IPv4 and 197 IPv6. 199 Deployment guidelines for IDRP for IPv4 and IPv6 are specified in 200 section 7 of this document. These guidelines supersede the material 201 presented in section 7.2 of [5]. 203 Domain configuration information for IDRP for IPv4 and IPv6 is 204 defined in section 8 of this document. The material of that section 205 supersedes the material presented in section 7.3 of [5]. 207 RFC DRAFT January 1996 209 5.1 An interface to IP 211 This sections supersedes the material in section 7.5 of [5]. 213 IDRP information is carried between a pair of BISs in the form of 214 BISPDUs. For IDRP for IPv6 these BISPDUs are carried in the data 215 field of IP packets of protocol type 45. 217 IDRP relies on IP to perform the initial processing of incoming 218 BISPDUs. The IP protocol machine shall process inbound packets 219 according to the appropriate IP functions. 221 If a fixed header of an IP packet contains a protocol type that 222 identifies IDRP, and the packet's source address identifies any 223 system listed in managed objects internalBIS or externalBISNeighbor, 224 then the packet contains a BISPDU. The BISPDU shall be passed to the 225 IDRP finite state machine defined in section 7.6.1 of [5]. 227 5.2 Encoding IP reachability information 229 The text in this section supersedes the material presented in section 230 6.3.2 of [5]. 232 The Network Layer Reachability information is a variable length field 233 that contains a list of reachable destinations encoded as zero or 234 more triples of the form
, 235 whose fields are described below: 237 +---------------------------+ 238 | Address Family (2 octets) | 239 +---------------------------+ 240 | Addr_length (2 octets) | 241 +---------------------------+ 242 | Addr_info (variable) | 243 +---------------------------+ 245 The use and meaning of these fields are as follows: 247 Address Family: 248 This field carries the identity of the protocol associated with 249 the address information that follows. Presently defined values 250 for this field are specified in RFC1700. A conformant 251 implementation of IDRP for IPv6 may ignore any address 252 information indicating other than IPv6. A conformant 253 implenetation of IDRP for IPv4 may ignore any address 254 information indicating other than IPv4. Address Family. 256 Addr_Length: 257 This field specifies the total length in octets of the address 258 information that follows. 260 RFC DRAFT January 1996 262 Addr_Info: 263 This is a variable length field that contains a list of IP 264 address prefixes for the routes that are being advertised. 265 Each IP address prefix is encoded as a 2-tuple of the form 266 , whose fields are described below: 268 +---------------------------+ 269 | Length (1 octet) | 270 +---------------------------+ 271 | Prefix (variable) | 272 +---------------------------+ 274 The use and the meaning of these fields are as follows: 276 a) Length: 278 The Length field indicates the length in bits of the IP 279 address prefix. A length of zero indicates a prefix that 280 matches all IPv4 or IPv6 (as specified by the address 281 family) addresses (with prefix, itself, of zero octets). 283 b) Prefix: 285 The Prefix field contains IP address prefixes followed by 286 enough trailing bits to make the end of the field fall on an 287 octet boundary. Note that the value of trailing bits is 288 irrelevant. 290 5.3 Encoding IP forwarding information 292 IPv6 forwarding information is carried in the NEXT_HOP path 293 attribute. As specified in [5], the attribute has a Proto_type, 294 Proto_Length and Protocol fields which indicate the protocol family 295 for the address of the NEXT_HOP (see section 6.3.1.4 of [5]). This 296 document replaces these three fields (Proto_type, Proto_Length, and 297 Protocol) with a single field -- Address Family. This 2-octets field 298 carries the identity of the protocol associated with the address 299 information that follows. Presently defined values for this field are 300 specified in RFC1700. A conformant implementation of IDRP for IPv6 301 may ignore any address information indicating other than IPv6 Address 302 Family. A conformant implementation of IDRP for IPv4 may ignore any 303 address information other than the IPv4 Address Family. 305 An implementation of IDRP for IPv4 or IPv6 shall have the following 306 values in the NEXT_HOP field: 308 IPv6: 309 Length of NET: 16 311 NET of Next Hop: an IPv6 unicast address 312 RFC DRAFT January 1996 314 SNPA information: as appropriate for the subnetwork type in use 316 IPv4: 317 Length of NET: 4 319 NET of Next Hop: an IPv4 unicast address 321 SNPA information: as appropriate for the subnetwork type in use 323 All other fields of the NEXT_HOP attribute remains as specified in 324 [5]. 326 5.4 Modification to the existing path attributes 328 To facilitate operations, IDRP for IPv6 modifies the following path 329 attributes: 331 LOCAL_PREF field in the ROUTE_SEPARATOR attribute (see section 332 6.3.1.1) is changed from 1 octet to 4 octets. The ROUTE-ID field in 333 the ROUTE_SEPARATOR attribute is eliminated. As a result the length 334 of the ROUTE_SEPARATOR attribute is changed from 5 to 4 octets. The 335 length of the MULTI_EXIT_DISCRIMINATOR attribute is changed from 1 336 octet to 4 octets. 338 Semantics, as well as handling of the modified attributes is left 339 intact. 341 5.5 New path attributes 343 IDRP for IPv6 defines the following new attribute: 345 AGGREGATOR (Type Code 17): 347 AGGREGATOR is an optional transitive attribute of length 32. 348 The attribute contains the last RDI that formed the 349 aggregate route (encoded as 16 octets), followed by the IP 350 address of the BIS that formed the aggregate route (encoded 351 as 16 octets, IPv4 addresses are prefixed with 12 octets of 352 zeros). The BIS that formed the aggregate route may decline 353 to encode its address and instead insert a value of all 354 zeros into that field. 356 The attribute may be included in routes which are formed by 357 route aggregation. A BIS that performs the aggregation may 358 add the AGGREGATOR attribute which shall contain BIS's own 359 RDI and IPv6 address. 361 ATOMIC_AGGREGATE (Type Code 18): 363 RFC DRAFT January 1996 365 ATOMIC_AGGREGATE is a well-known discretionary attribute of 366 length 0. It is used by a BIS to inform other BISs that the 367 local system selected for advertisement a less specific 368 route without selecting a more specific route which is 369 included in it. 371 If a BIS, when presented with a set of overlapping routes 372 from one of its peers, selects the less specific route 373 without selecting the more specific one, then the local 374 system shall attach the ATOMIC_AGGREGATE attribute to the 375 route when propagating it to other BISs (if that attribute 376 is not already present in the received less specific route). 377 A BIS that receives a route with the ATOMIC_AGGREGATE 378 attribute shall not remove the attribute from the route when 379 propagating it to other BISs. A BIS that receives a route 380 with the ATOMIC_AGGREGATE attribute shall not make any NLRI 381 of that route more specific when advertising this route to 382 other BISs. A BIS that receives a route with the 383 ATOMIC_AGGREGATE attribute needs to be cognizant of the fact 384 that the actual path to destinations, as specified in the 385 NLRI of the route, while having the loop-free property, may 386 traverse domains/confederations that are not listed in the 387 RD_PATH attribute. 389 5.6 Modifications to tie-breaking procedures for phase 2 391 This section supersedes the material in section 7.16.2.1 and 7.16.1.1 392 of [5]. 394 In its Adj-RIBs-In a BIS may have several routes to the same 395 destination that have the same degree of preference. The local BIS 396 can select only one of these routes for inclusion in the associated 397 Loc-RIB. The local BIS considers all equally preferable routes, both 398 those received from BISs located in adjacent RDs, and those received 399 from other BISs located in the local BIS's own RD. 401 Ties shall be broken according to the following algorithm: 403 a) If the local BIS is configured to take into account 404 MULTI_EXIT_DISC, and the candidate routes differ in their 405 MULTI_EXIT_DISC attribute, select the route that has the lowest 406 value of the MULTI_EXIT_DISC attribute. If the local BIS is 407 configured to take into account MULTI_EXIT_DISC, but that 408 attribute is not present, a locally defined "default" 409 MULTI_EXIT_DISC may be assumed as a basis for performing tie- 410 breaking. 412 b) Otherwise, if the local BIS can ascertain the cost of a path to 413 the entity depicted by the NEXT_HOP attribute of the candidate 414 route, select the route with the lowest cost (interior distance) 415 to the entity depicted by the NEXT_HOP attribute of the route. If 416 there are several routes with the same cost, then the tie-breaking 417 RFC DRAFT January 1996 419 shall be broken as follows: 421 - if at least one of the candidate routes was advertised by the 422 BIS in an adjacent RD, select the route that was advertised by 423 the BIS in an adjacent RD whose address has the lowest value 424 among all other BIS in adjacent RDs; 426 - otherwise, select the route that was advertised by the BIS 427 whose address has the lowest value. 429 5.7 Modifications to handling Hold Time 431 Upon receipt of an OPEN BISPDU, a BIS must calculate the value of the 432 Hold Timer by using the smaller of its configured Hold Time and the 433 Hold Time received in the OPEN BISPDU. 435 IDRP for IPv6 requires the value of the Hold Time field carried in 436 the OPEN BISPDU to be either zero or at least 3 seconds. An 437 implementation must reject Hold Time values of one or two seconds. 438 An implementation may reject any proposed Hold Time. An 439 implementation which accepts a Hold Time must use the negotiated 440 value for the Hold Time. If the negotiated Hold Time interval is 441 zero, then periodic KEEPALIVE messages shall not be sent. 443 In addition to the OPEN PDU error handling procedures specified in 444 section 7.20.2 of [5] this document specifies that if the Hold Time 445 field of the OPEN message is unacceptable, then the Error Subcode 446 shall be set to Unacceptable Hold Time. 448 5.8 Determining the forwarding address (Next Hop) 450 Next hop forwarding information information associated with a 451 particular route shall be derived from the NEXT_HOP attribute in the 452 UPDATE BISPDU that carries the route. If that attribute is not 453 present, the next hop (forwarding address) shall be derived from the 454 source IPv6 address of the IPv6 packet that carries the UPDATE BISPDU 455 containing the route. 457 In addition to the procedures for handling the NEXT_HOP attribute 458 specified in section 7.12.4 of [5], IDRP for IPv4 and IPv6 specifies 459 the following: 461 A BIS must never advertise an address of a peer to that peer as a 462 NEXT_HOP, for a route that the speaker is originating. A BIS must 463 never install a route with itself as the next hop. When a BIS 464 advertises the route to a BIS located in its own domain, the 465 advertising BIS should not modify the NEXT_HOP attribute associated 466 with the route. When a BIS receives the route from an internal 467 neighbor BIS, it may use the NEXT_HOP address as the forwarding 468 address, provided that the address is on a common subnet with the 469 RFC DRAFT January 1996 471 local BIS. 473 5.9 Modifications to the UPDATE PDU 475 This document specifies that NLRI of a route, rather than the Route- 476 ID of the route, shall be used to withdraw a previously advertised 477 route from service. 479 The Withdrawn Routes field in the UPDATE PDU is specified as a 480 variable length field that contains a list of NLRIs (rather than the 481 list of Route-IDs) for the routes that are being withdrawn from 482 service. Each NLRI is encoded as specified in Section 5.2 of this 483 document. An UPDATE PDU can list multiple routes to be withdrawn 484 from service. Each such route is identified by its NLRI, which 485 unambiguously identifies the route in the context of the BIS-BIS 486 connection in which it had been previously been advertised. 488 Eliminating Route-ID is also reflected in the encoding of the 489 ROUTE_SEPARATOR attribute (see Section 5.4 of this document). 491 5.10 Modifications to the OPEN PDU 493 Since IDRP for IPv6 doesn't support any Distinguishing Attrbutes, the 494 RIB-AttsSet field is eliminated from the OPEN PDU. (PST--bring back 495 DA's?) 497 The last two fields of the OPEN PDU message, Authentication Code and 498 Authentication Data, are replaced with the following two fields: 500 Optional Parameters Length: 502 This 2-octet unsigned integer indicates the total length of the 503 Optional Parameters following this field in octets. If the 504 value of this field i s zero, no Optional Parameters are 505 present. 507 Optional Parameters: 509 This field may contain a list of optional parameters, where 510 each parameter is encoded as a vector. 513 0 1 2 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 516 | Parm Flags | Parm. Type | Parm. Length | Parameter Value (variable) 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 519 (PST: grab BGP/4 flags text and talk to yakov about making 520 RFC DRAFT January 1996 522 length extensible 523 just like attribute length in BGP) 525 Parameter Flags is a one octet field that (PST: grab text from 526 BGP-4) 528 Parameter Type is a one octet field that unambiguously 529 identifies individual parameters. Parameter Length is a one 530 octet field that contains the length of the Parameter Value 531 field in octets. Parameter Value is a variable length field 532 that is interpreted according to the value of the Parameter 533 Type field. 535 This document defines the following Optional Parameters: 537 a) Authentication Information (Parameter Type 1): 539 This optional parameter may be used to authenticate a BIS 540 peer. The Parameter Value field contains a 1-octet 541 Authentication Code followed by a variable length 542 Authentication Data. 544 0 1 2 3 4 5 6 7 8 545 +-+-+-+-+-+-+-+-+ 546 | Auth. Code | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Authentication Data (variable) | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 The syntax and semantics of these two field is left 552 unchanged (as specified in section 6.2 of [5]). 554 Absence of any Authentication Information in an OPEN PDU shall be 555 treated as if the PDU carries Authentication Information with 556 Authentication Type 1 (see section 7.1.1 of [5]). 558 In addition to the OPEN PDU error handling procedures specified in 559 section 7.20.2 of [5] this document specifies that if one of the 560 Optional Parameters in the OPEN message is not recognized, then the 561 Error Subcode is set to Unsupported Optional Parameters. 563 5.11 Modifications to the RIB REFRESH PDU 565 This sections supersedes the material in section 6.7 of [5]. 567 The RIB REFRESH PDU is used to allow a BIS to send a refresh of the 568 routeing information in an Adj-RIB-Out to a neighbor BIS, or to 569 solicit a neighbor BIS to send a refresh of its Adj-RIB-Out to the 570 local BIS. The RIB REFRESH PDU contains a fixed header and also the 571 additional fields shown below: 573 RFC DRAFT January 1996 575 +---------------------------------------+ 576 | Fixed Header | 577 +---------------------------------------+ 578 | OpCode (1 octet) | 579 +---------------------------------------+ 580 | Optional Parameter Length (1 octet) | 581 +---------------------------------------+ 582 | Optional Parameters (variable) | 583 +---------------------------------------+ 585 The use and meaning of these fields is as follows: 587 There are three OpCode values defined: 589 +------------+---------------------+ 590 | Code | Operation | 591 +------------+---------------------+ 592 | 1 | RIB Refresh Request | 593 +------------+---------------------+ 594 | 2 | RIB Refresh Start | 595 +------------+---------------------+ 596 | 3 | RIB Refresh End | 597 +------------+---------------------+ 599 Optional Parameters Length: 600 This 1-octet unsigned integer indicates the total length of the 601 Optional Parameters field in octets. If the value of this field 602 is zero, no Optional Parameters are present. 604 Optional Parameters: 605 This field may contain a list of optional parameters, where 606 each parameter is encoded as a triplet. 609 0 1 610 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 612 | Parm. Type | Parm. Length | Parameter Value (variable) 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 615 Parameter Type is a one octet field that unambiguously 616 identifies individual parameters. Parameter Length is a one 617 octet field that contains the length of the Parameter Value 618 field in octets. Parameter Value is a variable length field 619 that is interpreted according to the value of the Parameter 620 Type field. 622 When a BIS receives a RIB REFRESH PDU that contains one or more 623 Optional Parameters, and the BIS doesn't support or does't recognize 624 at least one of the parameters, the BIS processes the PDU as if it 625 wouldn't have any Optional Parameters. This document doesn't specify 626 any Optional Parameters. 628 RFC DRAFT January 1996 630 Usage of RIB REFRESH PDU is defined in 7.10.3 of [5]. 632 5.12 Additional Error Subcodes 634 In addition to the Error subcodes defined in section 5.4 of [5], this 635 document defines the following OPEN PDU Error subcodes: 637 8 - Unacceptable Hold Time (see Section 5.7 of this document) 639 9 - Unsupported Optional Parameter (see Section 5.12 of this 640 document) 642 6 Naming and addressing conventions 644 This section supersedes the material of sections 5.10, 5.11 and 7.1 645 of [5]. 647 IDRP for IPv4 and IPv6 does not assume or require any particular 648 structure for IP addresses. That is, as long as the domain 649 administrator assigns addresses that are consistent with the 650 deployment constraints of section 7 of this document, the protocol 651 will operate correctly. 653 IP address prefixes provide a compact way for identifying groups of 654 systems that reside in a given domain or confederation. A prefix may 655 have a length that is either smaller than, or the same size as the IP 656 address (an IPv4 or IPv6 address is a special case of an address 657 prefix). The length of an encoded prefix is specified in bits. 659 Each routing domain and routing domain confederation whose BIS(s) 660 implement IDRP for IPv4 and IPv6 shall have an unambiguous routing 661 domain identifier (RDI), which is an IPv4 or IPv6 address prefix. In 662 the case of IPv4 address prefixes, the prefix value shall be 663 prepended with 12 octets of zeros. 665 An RDI is assigned statically and does not change based on the 666 operational status of a routing domain. An RDI identifies routing 667 domain or confederation uniquely, but does not necessarily convey any 668 information about policies or identities of its members. 670 7 Deployment guidelines 672 This section supersedes the material in section 7.2 of [5]. 674 Hosts and routers may use any IP unicast addresses, provided that 675 these addresses are globally unambiguous. However correct and 676 RFC DRAFT January 1996 678 efficient operation of this protocol can only be guaranteed if the 679 address assignment reflects the actual topology -- addresses are 680 topologically significant. One possible architecture for IPv6 address 681 assignment that satisfies this requirement is described in [12]. 683 8 Domain Configuration Information 685 Correct Operation of IDRP described in [5] assumes that a minimum 686 amount of information is available to both the inter-domain and 687 intra-domain routing protocols. This information is static in 688 nature, and is not expected to change frequently. This document 689 assumes that this information is supplied via IDRP MIB. While the 690 following in phrased in terms of MIB, this document allows 691 alternative mechanisms (e.g. configuration files) as well. 693 The information required by a BIS that implements the IDRP for IPv4 694 and IPv6 protocol is: 696 Location and identity of adjacent Intra-Domain routers: 698 The MIB table IntraIS lists the IP addresses of the routers to which 699 the local BIS may deliver an inbound NPDU whose destination lies 700 within the BIS's routing domain. These routers listed in the IntraIS 701 table support the intra-domain routing protocol of this domain, and 702 share at least one common subnet with the BIS. 704 In particular, if the local BIS participates in both the inter- 705 domain routing protocol (IDRP) and the intra-domain routing 706 protocol, then the IP address of the local BIS will be listed in the 707 IntraIS table. 709 Location and identity of BISs in the BIS's domain: 711 This information permits a BIS to identify all other BISs located 712 within its routing domain. This information is contained in the MIB 713 table InternalBIS, which contains a set of IPv6 addresses which 714 identify the BISs in the domain. 716 Location and identity of BISs in adjacent domains: 718 Each BIS needs information to identify the IP address of each BIS 719 located in an adjacent RD and reachable via a single subnetwork hop. 720 This information is contained in the IDRP MIB table 721 externalBISNeighbor, which is a table of IPv6 addresses. 723 IP network address information for all systems in the routing domain: 725 This information is used by the BIS to construct its network layer 726 reachability information. This information is contained in the MIB 727 table internalSystems, which lists NLRI (expressed as address 728 prefixes) of the systems within the routing domain. 730 RFC DRAFT January 1996 732 Local RDI: 734 This information is contained in managed object localRDI; it is the 735 RDI of the routing domain in which the BIS is located. 737 RDC-Config: 739 This information identifies all the routing domain confederations 740 (RDCs) to which the RD of the local BIS belongs, and it describes the 741 nesting relationships that are in force between them. It is contained 742 in the MIB table rdcConfig. 744 Note that since a domain is not required to belong to a confederation 745 this information is optional and needs to be present only at BISs of 746 the domains that are part of one or more of RDCs. 748 9 Multiple IDRP sessions between the same pair of routers 750 An IP router may have multiple IP addresses, one for each interface. 751 In contrast, an OSI Intermediate System has only one Network Entity 752 Title (network address). An OSI BIS thus may not have multiple IDRP 753 sessions with another BIS, since the NET is unique and there is no 754 mechanism for multiplexing sessions. However, an IP router may 755 potentially have multiple IDRP sessions with another router, since 756 each BIS may have multiple IP addresses, and one BIS may not be able 757 to ascertain that those addresses correspond to the same BIS. 758 Multiple IDRP sessions between BISs may not be efficient, but they 759 are not illegal, nor do they impact the robustness of the IDRP for IP 760 protocol; they will simply appear as multiple paths to the same 761 neighboring domain. One possible way of avoiding multiple parallel 762 IDRP sessions between a pair of BISs within a single domain is to 763 bind all source addresses of outgoing BISPDUs to the IPv6 address of 764 a particular interface (either physical or logical) of the BIS. 765 Likewise, for a pair of BISs located in adjacent domains, binding the 766 source addresses to a single address of an interface attached to a 767 common subnetwork allows for the elimination of multiple parallel 768 sessions. 770 10 Required set of supported routing policies 772 Policies are provided to IDRP in the form of configuration 773 information. This information is not directly encoded in the 774 protocol. Therefore, IDRP can provide support for very complex 775 routing policies (an example of such policy is presented in Annex K 776 of [5]). However, it is not required that all IDRP implementations 777 support such policies. 779 We are not attempting to standardize the routing policies that must 780 be supported in every IDRP implementation; we strongly encourage all 781 implementors to support the following set of routing policies: 783 RFC DRAFT January 1996 785 IDRP implementations should allow a domain to control announcements 786 of IDRP-learned routes to adjacent domains. Implementations should 787 also support such control with at least the granularity of a single 788 address prefix. Implementations should also support such control 789 with the granularity of a domain, where the domain may be either the 790 domain that originated the route, or the domain that advertised the 791 route to the local system (adjacent domain). Care must be taken when 792 a BIS selects a new route that can't be announced to a particular 793 external peer, while the previously selected route was announced to 794 that peer. Specifically, the local system must explicitly indicate 795 to the peer that the previous route is now infeasible. IDRP 796 implementations should allow a domain to prefer a particular path to 797 a destination (when more than one path is available). At the minimum 798 an implementation shall support this functionality by allowing to 799 administratively assign a degree of preference to a route based 800 solely on the IP address of the neighbor the route is received from. 801 The allowed range of the assigned degree of preference shall be 802 between 0 and 2^(31) - 1. IDRP implementations should allow a domain 803 to ignore routes with certain domains in the RD_PATH path attribute. 804 Such function can be implemented by assigning "infinity" as "weights" 805 for such domains. The route selection process must ignore routes that 806 have "weight" equal to "infinity". 808 11 Operations over Switched Virtual Circuits 810 When using IDRP for IPv4 and IPv6 over Switched Virtual Circuit (SVC) 811 subnetworks it may be desirable to minimize traffic generated by 812 IDRP. Specifically, it may be desirable to eliminate traffic 813 associated with periodic KEEPALIVE messages. IDRP for IPv4 and IPv6 814 includes a mechanism for operation over switched virtual circuit 815 (SVC) services which avoids keeping SVCs permanently open and allows 816 it to eliminates periodic sending of KEEPALIVE messages. 818 This section describes how to operate without periodic KEEPALIVE 819 messages to minimize SVC usage when using an intelligent SVC circuit 820 manager. The proposed scheme may also be used on "permanent" 821 circuits, which support a feature like link quality monitoring or 822 echo request to determine the status of link connectivity. 824 The mechanism described in this section is suitable only between the 825 BISs that are directly connected over a common virtual circuit. 827 11.1 Establishing an IDRP Connection 829 The feature is selected by specifying zero Hold Time in the OPEN 830 BISPDU. 832 11.2 Circuit Manager Properties 834 The circuit manager must have sufficient functionality to be able to 835 RFC DRAFT January 1996 837 compensate for the lack of periodic KEEPALIVE BISPDU: 839 It must be able to determine link layer unreachability in a 840 predictable finite period of a failure occurring. On determining 841 unreachability it should: start a configurable dead timer (comparable 842 to a typical Hold timer value). attempt to re-establish the Link 843 Layer connection. 845 If the dead timer expires it should: send a deactivate indication to 846 IDRP FSM. If the connection is re-established it should: cancel the 847 dead timer. transmit any queued BISPDUs. 849 11.3 Combined Properties 851 Some implementations may not be able to guarantee that the IDRP 852 process and the circuit manager will operate as a single entity; i.e. 853 they can have a separate existence when the other has been stopped or 854 has crashed. 856 If this is the case, a periodic two-way poll between the IDRP process 857 and the circuit manager should be implemented. If the IDRP process 858 discovers the circuit manager has gone away it should close all 859 relevant BIS-BIS connections. If the circuit manager discovers the 860 IDRP process has gone away it should close all its BIS-BIS 861 connections associated with the IDRP process and reject any further 862 incoming BIS-BIS connections. 864 12 Modifications to the conformance clause 866 To reflect the list of functions that shall not be implemented (see 867 section 4 of this document) the following items in the IDRP 868 conformance clause (section 12.1 of [5]) shall not be implemented: 870 clause (d): Transit Delay, Residual Error, Expense, clause (m) 871 clause (r) clause (s) clause (t) 873 13 Modifications to PICS 875 The PICS (Protocol Implementation Conformance Statement) provides a 876 convenient and concise mechanism to define which function need and 877 need not be implemented for IDRP for IPv4 and IPv6. All references 878 in this section are with respect to [5]. 880 All items with PICS Status as Optional need not be implemented in 881 IDRP for IPv4 and IPv6. In addition, IDRP for IPv4 and IPv6 should 882 not support the following items (even if some of the items are listed 883 as Mandatory): 885 RFC DRAFT January 1996 887 Table A.4.3: 888 MGT 890 Table A.4.5: 891 INCONS 893 Table A.4.8: 894 PSRCRT, DATTS, MATCH 896 Table A.4.11: 897 TDLY, RERR, EXP, LQOSG, SECG, PRTY 899 Table A.4.12: 900 TDLYP, RERRP, EXPP, LQOSP, SECP, PRTYP 902 Table A.4.13: 903 TDLYR, RERRR, EXPR, LQOSR, SECR, PRTYR 905 Implementation of all other items with Optional Status not listed in 906 the previous paragraph is optional. 908 14 Navigating through IDRP 910 Here is the list of sections in [5] that are relevant to the IDRP 911 for IPv6 implementation: chapters 1, 3, 4, 5 (except 5.10 and 5.11), 912 6, 7 (except for 7.1, 7.2, 7.3, 7.4, 7.12.8, 7.12.9, 7.12.10, 7.12.11 913 and 7.12.16), 10. The rest of the material in [5] could be safely 914 ignored. 916 15 Security Considerations 918 Security issues are not discussed in this document. 920 16 Acknowledgements 922 Large parts of this document are borrowed from the BGP Protocol 923 specifications and BGP Usage documents ([9], [10]). 925 We would like to thank Susan Hares (MERIT) and John Scudder (MERIT) 926 for their work on IDRP for IPv4. Portions of this document are 927 borrowed from their work. 929 We would like to thank Tony Li (cisco Systems) for his review of this 930 document. 932 Finally we would like to thank the whole Inter-Domain Routing (IDR) 933 Working Group for their contribution to this document. 935 RFC DRAFT January 1996 937 17 References 939 [1] Braun, H-W., "Models of Policy Based Routing", RFC 1104, 940 Merit/NSFNET, June 1989. 942 [2] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter-Domain 943 Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 944 1519, September 1993 946 [3] Deering, S., Hinden, B., "Internet Protocol, Version 6 (IPv6) 947 Specification", RFC1883, January 1996 949 [4] Hinden, B., Deering, S., "IP Version 6 Addressing Architecture", 950 RFC1884, January 1996 952 [5] ISO/IEC IS 10747 - Information Processing Systems - 953 Telecommunications and Information Exchange between Systems - 954 Protocol for Exchange of Inter-domain Routing Information among 955 Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993 956 ftp://networking.raleigh.ibm.com/pub/standards/idrp/is10747.ps 957 ftp://networking.raleigh.ibm.com/pub/standards/idrp/is10747.txt 959 [6] ISO 8473 - Information Processing Systems - Data Communications 960 - Protocol for Providing the Connectionless-mode Network Service, 961 1988. 963 [7] ISO/IEC 10589 - Information Processing Systems - 964 Telecommunications and Information Exchange between systems - 965 Intermediate System to Intermediate System Intra-Domain routing 966 information exchange protocol for use in conjunction with the 967 Protocol for providing the Connectionless-mode Network Service (ISO 968 8473), 1992. 970 [8] ISO 9542 - Information Processing Systems - Telecommunications 971 and information exchange between systems - End system to Intermediate 972 system routing exchange protocol for use in conjunction with the 973 Protocol for providing the connectionless-mode network service (ISO 974 8473) 976 [9] Rekhter, Y., Gross, P., ``Application of the Border Gateway 977 Protocol in the Internet'', RFC1655, July 1994 979 [10] Rekhter, Y., Li, T., ``A Border Gateway Protocol 4 (BGP-4)'', 980 RFC1654, July 1994 982 [11] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation 983 with CIDR", RFC1518, September 1993 985 [12] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address 986 Allocation", RFC1887, January 1996 987 RFC DRAFT January 1996 989 Authors' Addresses 991 Yakov Rekhter 992 cisco Systems, Inc. 993 170 W. Tasman Dr. 994 San Jose, CA 95134 995 email: yakov@cisco.com 997 Paul Traina 998 cisco Systems, Inc. 999 170 W. Tasman Dr. 1000 San Jose, CA 95134 1001 email: pst@cisco.com