idnits 2.17.1 draft-ietf-rps-tunnels-00.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-26) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([V6TRNS], [IPV6], [6BONE], [DVMRP], [MBONE], [GRE], [SSMMC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 (November 1996) is 10024 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) -- Possible downref: Non-RFC (?) normative reference: ref. '6BONE' == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-03 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'DVMRP') ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. 'GRE') == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-ipv6-tunnel-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'MBONE' == Outdated reference: A later version (-03) exists of draft-ietf-rps-rpsl-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'SSMMC' ** Obsolete normative reference: RFC 1933 (ref. 'V6TRNS') (Obsoleted by RFC 2893) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT David Meyer 3 draft-ietf-rps-tunnels-00.txt University of Oregon 4 Category: Standards Track November 1996 6 Representing Tunnels in RPSL 8 Status of this Memo 10 This document provides extensions to the Routing Policy Specification 11 Language [RPSL] to provide support for tunnels of various types. 13 Internet Drafts 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This document specifies the language and set of semantics describing 34 tunnels in the Routing Policy Specification Language (RPSL). It 35 defines a new tunnel class, inet-tunnel, and a set of extensions to 36 the inet-rtr class. An instance of the inet-tunnel class specifies 37 endpoints for tunnels of various encapsulation types, including DVMRP 38 [DVMRP], GRE [GRE], and IPv6 [IPV6]. 40 This memo is a product of the Routing Policy System Working Group 41 (RPS) in the Operational Requirements area of the Internet 42 Engineering Task Force. Submit comments to or the 43 author. 45 Introduction 47 Tunneling is a fundamental networking technology that is used in a 48 variety circumstances. A common use of tunneling is to incrementally 49 deploy a new network layer protocol. The approach is to encapsulate 50 ("tunnel") the new protocol through the existing network layer proto- 51 col, usually IP. Examples of this approach include include the multi- 52 cast backbone [MBONE], where multicast packets are encapsulated in IP 53 packets using protocol 4 (IP in IP), and IPv6 backbone [6BONE], where 54 IPv6 packets are encapsulated in IP packets using IP protocol 41 55 [V6TRNS]. 57 Another use of tunneling is to force congruence between the existing 58 (IP unicast) topology and some new topology. Due the special require- 59 ments of IP multicast routing, the MBONE is also an example of this 60 use of tunneling. 62 This document describes extensions to RPSL to support general tunnel- 63 ing mechanisms. The extensions support point to point and point to 64 multipoint tunnels of encapsulation types, including DVMRP, GRE, and 65 IPv6. In addition to the encapsulation, a protocol to run inside the 66 tunnel can also be specified. 68 Extensions to the inet-rtr class 70 The inet-rtr class' peer attribute is extended to describe tunnels by 71 assigning a new peer type (tunnel). The tunnel peer attribute has the 72 following fields: 74 inet-rtr: 75 ... 76 peer: tunnel source= 77 encap= 78 name= 79 ... 80 peer: tunnel source= 81 encap= 82 name= 84 The type clause of then tunnel peer attribute describes the encapsu- 85 lation on the tunnel. The defined encapsulation types are DVMRP 86 [DVMRP], GRE [GRE], or IPv6 [IPV6]. The name clause refers to a tun- 87 nel object (see below). If there are multiple tunnel peer attributes 88 with the same name attribute, then the tunnel is a point to mul- 89 tipoint tunnel. Note that a router can be the source of multiple tun- 90 nels. 92 Each inet-rtr tunnel peer instance has a mandatory name, source, and 93 destination attributes. The tunnel source attribute must correspond 94 to an ifaddr attribute for the inet-rtr instance. 96 The inet-rtr instance below describes a DVMRP tunnel with source 97 204.70.32.6 and destination 204.70.158.61. The tag MBONE-TUNNEL-EUG 98 refers to a tunnel instance (see below). The same router has a GRE 99 tunnel. 101 inet-rtr: eugene-isp.nero.net 102 loacalas: AS4600 103 ifaddr: 204.70.32.6 masklen 30 104 ... 105 peer: tunnel encap=DVMRP name=MBONE-TUNNEL-EUG 204.70.32.6 204.70.158.61 106 peer: tunnel encap=GRE name=GRE-TUNNEL-EUG 204.70.32.6 206.42.19.240 107 ... 109 The inet-tunnel Class 111 A tunnel is specified by an instance of the inet-tunnel class. The 112 attributes of the inet-tunnel class are described below. 114 inet-tunnel: 115 tunnel-source: 116 tunnel-sink: 117 ... 118 tunnel-sink: 119 tunnel-protocol: 120 tunnel-in: from accept 121 tunnel-in: from accept 122 ... 123 tunnel-in: from accept 124 tunnel-out: to 125 [action 126 [scope=;] 127 [boundary=;] 128 [dvmrp-metric=;]] 129 announce 130 tunnel-out: to 131 [action 132 [scope=;] 133 [boundary=;] 134 [dvmrp-metric=;]] 135 announce 136 ... 137 tunnel-out: to 138 [action 139 [scope=;] 140 [boundary=;] 141 [dvmrp-metric=;]] 142 announce 144 inet-tunnel Class Attributes 146 inet-tunnel: mandatory, single valued 147 tunnel-source: mandatory, single valued, class key 148 tunnel-sink: mandatory, single valued, class key 149 tunnel-protocol: mandatory, single valued 150 tunnel-in: mandatory, multi-valued 151 tunnel-out: mandatory, multi-valued 153 An instance of the inet-tunnel class describes a single tunnel 154 (although the tunnel-source may be the source of multiple tunnels). 155 The name attribute is a key that is used in an inet-rtr object to 156 reference the tunnel object. The tunnel may be point to point or 157 point to multipoint. A multipoint tunnel will have more than one 158 tunnel-sink value. Each tunnel-sink must have corresponding tunnel-in 159 and tunnel-out attributes. The tunnel-protocol is the protocol to run 160 "inside" the tunnel. The values for tunnel-protocol include BGP, 161 RIPv6, DVMRP, PIM-DM, and PIM-SM. See [SSMMC] for an application that 162 uses BGP tunneled in GRE. 164 The inet-tunnel class's tunnel-out attribute includes an action 165 clause for which the currently defined actions include: (i). The 166 minimum IP time-to-live required for a packet to be forwarded to the 167 specified endpoint (in the case of multipoint tunnels, there may be 168 per endpoint scopes), (ii). A boundary attribute describes a class of 169 packets that will not be forwarded through the tunnel, and (iii). A 170 DVMRP metric. These attributes are particularly relevant to multicast 171 routing. 173 The inet-tunnel class also has routing filter specifications which 174 describe filters that are appropriate for the tunnel's routing proto- 175 col. In the case of DVMRP, the filter specification 176 can be the list of network prefixes accepted or advertised. 178 Finally, an instance of the inet-tunnel class also has all of the 179 administrative fields present in an aut-num class, including guar- 180 dian, admin-c, tech-c, notify, mnt-by, changed, and source. 182 Example 184 In this example, the inet-rtr eugene-isp.nero.net has a DVMRP tunnel 185 with the sink on the inet-rtr dec3800-2-fddi-0.SanFrancisco.mci.net. 186 The tunnel object is called MBONE-TUNNEL-EUG. eugene-isp.nero.net 187 will accept any routes. eugene-isp.nero.net will forward packets to 188 the DVMRP tunnel if the packet's time-to-live is greater than or 189 equal to 64. In addition, eugene-isp.nero.net will not pass any pack- 190 ets that match the administrative scope boundary filter (in this 191 case, 239.254.0.0/16). 193 In addition, the inet-rtr eugene-isp.nero.net has a GRE tunnel 194 represented by GRE-TUNNEL-EUG. 196 inet-tunnel: MBONE-TUNNEL-EUG 197 tunnel-source: eugene-isp.nero.net 198 tunnel-sink: dec3800-2-fddi-0.SanFrancisco.mci.net 199 tunnel-protocol: DVMRP 200 tunnel-in: from 204.70.158.61 accept ANY 201 tunnel-out: to 204.70.158.61 202 action 203 scope=64; 204 boundary={239.254.0.0/16}; 205 dvmrp-metric=1; 206 announce AS-NERO-TRANSIT 207 guardian: meyer@ns.uoregon.edu 208 admin-c: DMM65 209 tech-c: DMM65 210 notify: nethelp@ns.uoregon.edu 211 mnt-by: MAINT-AS3582 212 changed: meyer@ns.uoregon.edu 961104 213 source: RADB 215 inet-tunnel: GRE-TUNNEL-EUG 216 tunnel-source: eugene-isp.nero.net 217 tunnel-sink: ogre.prognet.com 218 tunnel-protocol: PIM-DM 219 tunnel-in: from 204.70.158.61 accept ANY 220 tunnel-out: to 206.42.19.240 221 action 222 scope=64; 223 announce ANY 224 guardian: meyer@ns.uoregon.edu 225 admin-c: DMM65 226 tech-c: DMM65 227 notify: nethelp@ns.uoregon.edu 228 mnt-by: MAINT-AS3582 229 changed: meyer@ns.uoregon.edu 961104 230 source: RADB 232 Security Considerations 234 Security considerations are not discussed in this memo. 236 References 238 [6BONE] See http://www-6bone.lbl.gov/6bone/ 240 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing 241 Protocol", draft-ietf-idmr-dvmrp-v3-03, September, 242 1996. 244 [GRE] S. Hanks, T. Li, D. Farinacci, and P. Traina, "Generic 245 Routing Encapsulation (GRE)", RFC1701, October, 1994. 247 [IPV6] A. Conta and S. Deering, "Generic Packet Tunneling in 248 IPv6", draft-ietf-ipngwg-ipv6-tunnel-04.txt, October, 249 1996 251 [MBONE] See http://www.best.com/~prince/techinfo/misc.html 253 [RPSL] C. Alaettinoglu, et. al., "Routing Policy 254 Specification Language (RPSL)", 255 draft-ietf-rps-rpsl-00.txt, October, 1996. 257 [SSMMC] Y. Rekhter, "Auto route injection with tunnelling", 258 NANOG, October, 1996. For additional information, see 259 http://www.academ.com/nanog/oct1996/multihome.html 261 [V6TRNS] R. Gilligan and E. Nordmark, "Transition Mechanisms 262 for IPv6 Hosts and Routers", RFC 1933, April 1996. 264 Author's Address 266 David Meyer 267 University of Oregon 268 1225 Kincaid St. 269 Eugene, OR 97403 271 phone: +1 541.346.1747 273 email: meyer@ns.uoregon.edu