idnits 2.17.00 (12 Aug 2021) /tmp/idnits56130/draft-davey-mpls-rsvp-ipv6-unnum-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 278. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 242), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([OSPFv3-TE], [ISIS-TE], [RFC3477]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2005) is 6304 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) == Outdated reference: draft-ietf-ospf-ospfv3-traffic has been published as RFC 5329 == Outdated reference: draft-ietf-isis-ipv6-te has been published as RFC 6119 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Davey 3 INTERNET-DRAFT N. Neate 4 Updates: RFC3477 Data Connection Ltd (DCL) 5 Proposed category: Standards Track 6 Expires: August 2005 7 February 2005 9 Signalling Unnumbered Links in Resource ReSerVation Protocol - 10 Traffic Engineering (RSVP-TE) in an IPv6 Network 11 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 or will be disclosed, and any of which I become aware will be 18 disclosed, in accordance with RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society 2005. All Rights Reserved. 40 Abstract 42 Currently, RSVP-TE signalling over unnumbered links identifies 43 routers using 32-bit Router IDs [RFC3477]. Traffic engineering 44 extensions to IGP protocols for use in IPv6 networks use 128-bit IPv6 45 addresses to identify routers [OSPFv3-TE], [ISIS-TE]. This document 46 specifies extensions for RSVP-TE signalling over unnumbered links to 47 use 128-bit Router IDs in an IPv6 network. 49 1. Terms 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119. 55 2. Overview 57 Supporting RSVP-TE over unnumbered links in an IPv6 network (that is, 58 links that do not have global-scope IPv6 addresses) involves two 59 components: (a) the ability to carry (TE) information about 60 unnumbered links in IGP TE extensions (ISIS or OSPFv3), and (b) the 61 ability to specify unnumbered links in RSVP-TE signalling. The 62 former is covered in [OSPFv3-TE] and [ISIS-TE]. The focus of this 63 document is on the latter. 65 Currently, RSVP-TE signalling for unnumbered links does not support 66 unnumbered links in an IPv6 network because it does not provide a way 67 to identify a router using a 128-bit IPv6 address in its 68 LSP_TUNNEL_INTERFACE_ID, Explicit Route and Record Route Objects. 69 This document proposes simple extensions that allow RSVP-TE 70 signalling over unnumbered links [RFC3477] to be used in an IPv6 71 network. 73 3. Definition of Terms 75 3.1 IPv6 Router IDs 77 In the context of this document, the term "IPv6 Router ID" means a 78 stable IPv6 address of an LSR that is always reachable if there is 79 any connectivity to the LSR. If OSPFv3 is being used as the IGP then 80 the IPv6 Router ID SHOULD be set to the "Router IPv6 Address" as 81 defined in [OSPFv3-TE]. If IS-IS is being used as the IGP then the 82 IPv6 Router ID SHOULD be set to the "IPv6 TE Router ID" as defined in 83 [ISIS-TE]. 85 3.2 Interface IDs 87 In this document, Interface IDs are as defined in [RFC3477]. 89 4. Definition of Objects and Subobjects 91 4.1 LSP_TUNNEL_INTERFACE_ID Object 93 [RFC3477] states that if an LSR that originates an LSP advertises 94 this LSP as an unnumbered Forwarding Adjacency in IS-IS or OSPF (see 95 [LSP-HIER]), or the LSR uses the Forwarding Adjacency formed by this 96 LSP as an unnumbered component link of a bundled link (see 97 [LINK-BUNDLE]), the LSR MUST allocate an identifier to that 98 Forwarding Adjacency (just like for any other unnumbered link). 99 Moreover, the path message used for establishing the LSP that forms a 100 Forwarding Adjacency MUST contain the LSP_TUNNEL_INTERFACE_ID object, 101 as described in [RFC3477]. 103 For IPv6 networks, the LSP_TUNNEL_INTERFACE_ID object has a class 104 number of 193, C-Type of 2 (suggested value; to be assigned by 105 IANA) and length of 24. The format is given below. 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | IPv6 Router ID | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | IPv6 Router ID (continued) | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | IPv6 Router ID (continued) | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | IPv6 Router ID (continued) | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Interface ID (32 bits) | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 4.2 Explicit Route Object 123 A new subobject of the Explicit Route Object (ERO) is used to specify 124 unnumbered links in an IPv6 network. This subobject has the 125 following format. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 |L| Type | Length | Reserved (MUST be zero) | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | IPv6 Router ID | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | IPv6 Router ID (continued) | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | IPv6 Router ID (continued) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | IPv6 Router ID (continued) | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Interface ID (32 bits) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 The Type is 5, Unnumbered Interface ID for IPv6 network (suggested 144 value; to be assigned by IANA). The Length is 24. 146 The Interface ID is the identifier assigned to the link by the LSR 147 specified by the IPv6 Router ID. 149 4.3 Record Router Object 151 A new subobject of the Record Route Object (RRO) is used to record 152 that the LSP path traversed an unnumbered link in an IPv6 network. 153 This subobject has the following format. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type | Length | Flags | Reserved (MBZ)| 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | IPv6 Router ID | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | IPv6 Router ID (continued) | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | IPv6 Router ID (continued) | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | IPv6 Router ID (continued) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Interface ID (32 bits) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 The Type is 5, Unnumbered Interface ID for IPv6 network (suggested 171 value; to be assigned by IANA); the Length is 24. Flags are as 172 defined in [RFC3477]. 174 5. Processing of objects 176 The processing of the objects and subobjects defined above is the 177 same as the processing for the equivalent objects and subobjects 178 defined in [RFC3477]. 180 6. Security Considerations 182 This document raises no new security considerations. 184 7. IANA Considerations 186 This document defines a new C-type of 2, forward/reverse interface ID 187 for IPv6 networks, for the LSP_TUNNEL_INTERFACE_ID object. 189 This document also defines the new subobject type of 5, unnumbered 190 interface ID for IPv6 network, for the EXPLICIT_ROUTE object and the 191 ROUTE_RECORD object. 193 8. References 195 8.1 Normative References 197 [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered Links in 198 Resource ReSerVation Protocol - Traffic Engineering 199 (RSVP-TE)", RFC3477, January 2003. 201 [OSPFv3-TE] 202 K. Ishiguro and T. Takada, "Traffic Engineering Extensions 203 to OSPF version 3", draft-ietf-ospf-ospfv3-traffic-02.txt, 204 July 2004 (work in progress). 206 [ISIS-TE] J. Harrison, J. Berger and M. Bartlett, "IPv6 Traffic 207 Engineering in IS-IS", draft-ietf-isis-ipv6-te-00.txt, 208 January 2005 (work in progress). 210 8.2 Informative References 212 [LSP-HIER] 213 Kompella, K. and Y. Rekhter, "LSP Hierarchy with 214 Generalized MPLS TE" (work in progress). 216 [LINK-BUNDLE] 217 Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling 218 in MPLS Traffic Engineering" (work in progress). 220 9. Authors' Address 222 Alan Davey 223 Data Connection Ltd 224 100 Church Street 225 EN2 6BQ 226 U.K. 227 Phone: +44 20 8366 1177 228 Email: alan.davey@dataconnection.com 230 Nic Neate 231 Data Connection Ltd 232 100 Church Street 233 EN2 6BQ 234 U.K. 235 Phone: +44 20 8366 1177 236 Email: nic.neate@dataconnection.com 238 10. Full Copyright Statement 240 Copyright (C) The Internet Society (2005). This document is subject 241 to the rights, licenses and restrictions contained in BCP 78, and 242 except as set forth therein, the authors retain all their rights. 244 This document and the information contained herein are provided on an 245 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 246 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 247 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 248 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 249 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 250 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 252 This document may not be modified, and derivative works of it may 253 not be created, except to publish it as an RFC and to translate it 254 into languages other than English. 256 Intellectual Property Statement 258 The IETF takes no position regarding the validity or scope of any 259 Intellectual Property Rights or other rights that might be claimed to 260 pertain to the implementation or use of the technology described in 261 this document or the extent to which any license under such rights 262 might or might not be available; nor does it represent that it has 263 made any independent effort to identify any such rights. Information 264 on the procedures with respect to rights in IETF Documents can be 265 found in BCP 78 and BCP 79. 267 Copies of IPR disclosures made to the IETF Secretariat and any 268 assurances of licenses to be made available, or the result of an 269 attempt made to obtain a general license or permission for the use of 270 such proprietary rights by implementers or users of this 271 specification can be obtained from the IETF on-line IPR repository at 272 http://www.ietf.org/ipr. 274 The IETF invites any interested party to bring to its attention any 275 copyrights, patents or patent applications, or other proprietary 276 rights that may cover technology that may be required to implement 277 this standard. Please address the information to the IETF at 278 ietf-ipr@ietf.org.