idnits 2.17.00 (12 Aug 2021) /tmp/idnits24818/draft-boucadair-ospf-v4v6-ospfv3-mt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-ospf-af-alt], [I-D.ietf-ospf-mt-ospfv3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2010) is 4474 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: A later version (-04) exists of draft-boucadair-dslite-interco-v4v6-02 == Outdated reference: draft-ietf-behave-address-format has been published as RFC 6052 == Outdated reference: draft-ietf-behave-v6v4-xlate has been published as RFC 6145 == Outdated reference: draft-ietf-behave-v6v4-xlate-stateful has been published as RFC 6146 == Outdated reference: draft-ietf-ospf-af-alt has been published as RFC 5838 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track France Telecom 5 Expires: August 16, 2010 D. Cheng 6 Huawei 7 Y. Lee 8 Comcast 9 February 12, 2010 11 Multi-Topology/Multi-Instance OSPFv3 for IPv4-Embedded IPv6 12 draft-boucadair-ospf-v4v6-ospfv3-mt-02 14 Abstract 16 This memo defines two new Multi Topology Routing Identifiers (MT 17 IDs), based on [I-D.ietf-ospf-mt-ospfv3] and two new Instance 18 Identifiers (MI IDs), based on [I-D.ietf-ospf-af-alt], respectively, 19 in OSPFv3. With these identifiers, an IPv4-Embedded IPv6 topology is 20 maintained for both IPv6 unicast and multicast traffic. The purpose 21 of running separate instances or topologies for IPv4- Embedded IPv6 22 traffic is to distinguish from the native IPv6 routing topology, and 23 the topology that is used for routing IPv4-Embedded IPv6 datagrams 24 only. Separate instances/topologies are also meant to prevent any 25 overload of the native IPv6 routing tables by IPv4-Embedded IPv6 26 routes. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on August 16, 2010. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 2. IPv4-Embedded IPv6 OSPFv3 Topologies . . . . . . . . . . . . . 4 87 3. IPv4-Embedded IPv6 OSPFv3 Instances . . . . . . . . . . . . . . 5 88 4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 5 89 5. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 90 6. Advertising IPv4-Embedded IPv6 Routes . . . . . . . . . . . . . 5 91 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 6 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 100 1. Introduction 102 Within the double context of public IPv4 address exhaustion and IPv6- 103 IPv4 interconnection, numerous solutions are being elaborated within 104 IETF. Both translation (e.g., [I-D.ietf-behave-v6v4-xlate-stateful] 105 and [I-D.ietf-behave-v6v4-xlate]) and encapsulation (e.g., 106 [I-D.boucadair-dslite-interco-v4v6] and 107 [I-D.boucadair-behave-ipv6-portrange]) based schemes are proposed to 108 allow IPv6-IPv4 interconnection. These solutions require the 109 injection of routes to IPv4-Embedded IPv6 prefixes 110 [I-D.ietf-behave-address-format] in intra-domain routing protocols . 112 In order to prevent any overload of the native IPv6 routing table 113 with IPv4-Embedded IPv6 routes, this document defines new MT IDs 114 (resp., MI IDs) which are required for the activation of multiple 115 topologies (resp., Instances), where the native IPv6 topology (resp., 116 Instance) would be distinct from the IPv4-Embedded IPv6 topology 117 (resp., Instance). Operational reasons also motivate this approach 118 which is meant to ease the migration to full IPv6. As a result, the 119 unicast IPv4- Embedded IPv6 topology (resp., Instance) is used for 120 unicast IPv4- Embedded IPv6 route computation purposes, and the 121 multicast IPv4- Embedded IPv6 topology (resp., Instance) is used for 122 multicast IPv4- Embedded IPv6 route computation purposes. 124 This document does not make any preference between the solution 125 described in [I-D.ietf-ospf-mt-ospfv3] and [I-D.ietf-ospf-af-alt]. 126 Network administrators have to make their decisions based on local 127 policies. If the multi-instance mechanism is deployed in an OSPFv3 128 network as a preference for multiple topologies, the MI extensions 129 defined in this document may be used to support unicast/multicast 130 IPv4-Embedded IPv6 routing. If MT-OSPFv3 mechanism is deployed in an 131 OSPFv3 network as a preference for multiple topologies, the MT 132 extensions defined in this document may be used to support unicast/ 133 multicast IPv4-Embedded IPv6 routing. 135 2. IPv4-Embedded IPv6 OSPFv3 Topologies 137 MT-OSPFv3 [I-D.ietf-ospf-mt-ospfv3] is a mechanism that has been 138 specified to run various topologies based on several criteria such as 139 the need to distinguish the IPv6 unicast topology from the IPv4 140 routing topology. Distinct MT IDs (Multi-Topology Identifiers) are 141 assigned by IANA (e.g., MT ID# 0 for IPv6 routing topology, MT ID# 3 142 for IPv6 multicast topology, etc.). MT ID #5-#31 range is reserved 143 for IETF consensus. This document requests the assignment of two new 144 MT IDs for the following usages: 146 o IPv4-Embedded IPv6 unicast topology; 148 o IPv4-Embedded IPv6 multicast topology. 150 3. IPv4-Embedded IPv6 OSPFv3 Instances 152 [I-D.ietf-ospf-af-alt] specifies a mechanism to map each address 153 family (AF) to a separate OSPFv3 [RFC5340] Instance identified by an 154 ID. Many Instance IDs have been reserved for different AF (e.g., 155 Instance ID#0 - #31 for IPv6 unicast AF, Instance ID#32 - #63 for 156 IPv6 multicast AF, etc.). Instance ID#0 is used by default for IPv6 157 unicast AF. This document requests the assignment of two new 158 Instance IDs for the IPv4-Embedded IPv6 AF: 160 o IPv4-Embedded IPv6 unicast AF; 162 o IPv4-Embedded IPv6 multicast AF. 164 4. Provisioning 166 Adequate provisioning must be done according to 167 [I-D.ietf-ospf-mt-ospfv3] and [I-D.ietf-ospf-af-alt], respectively, 168 based on the corresponding mechanism that is actually used in an 169 OSPFv3 network, in order to have a fully-connected IPv4-Embedded IPv6 170 unicast or multicast topology. 172 5. Procedure 174 This document does not require any modification to the procedure 175 specified in [I-D.ietf-ospf-mt-ospfv3] nor in [I-D.ietf-ospf-af-alt]. 176 Nevertheless, routes to IPv4-Embedded IPv6 addresses or prefixes MUST 177 be instantiated within an IPv4-Embedded IPv6 MT-OSPFv3 (resp., MI- 178 OSPFv3). Concretely, the IANA prefix defined in 179 [I-D.ietf-behave-address-format] MUST be supported by default. 180 Service providers MAY also choose a LIR prefix to build the IPv4- 181 Embedded IPv6 addresses. 183 6. Advertising IPv4-Embedded IPv6 Routes 185 With one of the mechanisms (i.e., a separate OSPFv3 instance or a 186 separate OSPFv3 topology) as described above, reachability of IPv4- 187 Embedded IPv6 destinations can be advertised in an IPv6 network using 188 OSPFv3. 190 In general, IPv4-Embedded IPv6 addresses and prefixes are advertised 191 into an OSPFv3 network using AS External LSA [RFC5340], i.e.- with 192 the advertising scope throughout the entire Autonomous System. This 193 is because an advertising node in this case is most likely connected 194 to one or more IPv4 networks, and as such, it functions as an 195 Autonomous System Boundary Router (ASBR) in the perspective of OSPFv3 196 routing domain. Any OSPFv3 area that does not want to receive such 197 advertisement can be configured as a stub area or with other routing 198 policy. 200 By default, the metric in an AS External LSA that carries one or more 201 IPv4-Embedded IPv6 addresses and prefixes is a Type 1 external 202 metric, which is then to be added to the metric of an intra-AS path 203 during OSPFv3 routes calculation. By configuration on an ASBR, the 204 metric can be set to a Type 2 external metric, which is considered 205 much larger than any intra-AS path. The detail is referred to OSPFv3 206 specification [RFC5340]. In either case, an external metric may be 207 exact the same unit as in an IPv4 network (running OSPFv2 or others), 208 but may also be specified by a routing policy, the detail is outside 209 of the scope of this document. 211 Advertising IPv4-Embedded IPv6 addresses and prefixes using OSPFv3 212 inter-area prefix LSA is for future study. 214 7. Forwarding 216 Only incoming datagrams destined to IPv4-Embedded IPv6 addresses are 217 associated (and forwarded accordingly) with the IPv4-Embedded IPv6 218 unicast/multicast topology, respectively. WKP (i.e., 64:FF9B::/96) 219 and/or LIR prefix defined in [I-D.ietf-behave-address-format] MUST be 220 configured in all participating nodes. 222 8. IANA Considerations 224 This document requests the following MT-OSPFv3 IDs: 226 o MT ID# for IPv4-Embedded IPv6 unicast topology 228 o MT ID# for IPv4-Embedded IPv6 multicast topology. 230 and the following OSPFv3 Instance IDs: 232 o Instance ID# for IPv4-Embedded IPv6 unicast AF; 234 o Instance ID# for IPv4-Embedded IPv6 multicast AF. 236 9. Security Considerations 238 This document does not introduce any security issue in addition to 239 those defined in [RFC5340]. 241 10. Acknowledgements 243 TBC 245 11. References 247 11.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 253 for IPv6", RFC 5340, July 2008. 255 11.2. Informative References 257 [I-D.boucadair-behave-ipv6-portrange] 258 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 259 Kassi-Lahlou, M., Bajko, G., Lee, Y., Melia, T., and O. 260 Vautrin, "Flexible IPv6 Migration Scenarios in the Context 261 of IPv4 Address Shortage", 262 draft-boucadair-behave-ipv6-portrange-04 (work in 263 progress), October 2009. 265 [I-D.boucadair-dslite-interco-v4v6] 266 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 267 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 268 Stack lite in IPv6-only Network", 269 draft-boucadair-dslite-interco-v4v6-02 (work in progress), 270 October 2009. 272 [I-D.ietf-behave-address-format] 273 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 274 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 275 draft-ietf-behave-address-format-04 (work in progress), 276 January 2010. 278 [I-D.ietf-behave-v6v4-xlate] 279 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 280 Algorithm", draft-ietf-behave-v6v4-xlate-09 (work in 281 progress), February 2010. 283 [I-D.ietf-behave-v6v4-xlate-stateful] 284 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 285 NAT64: Network Address and Protocol Translation from IPv6 286 Clients to IPv4 Servers", 287 draft-ietf-behave-v6v4-xlate-stateful-08 (work in 288 progress), January 2010. 290 [I-D.ietf-ospf-af-alt] 291 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 292 Aggarwal, "Support of address families in OSPFv3", 293 draft-ietf-ospf-af-alt-10 (work in progress), 294 December 2009. 296 [I-D.ietf-ospf-mt-ospfv3] 297 Mirtorabi, S. and A. Roy, "Multi-topology routing in 298 OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in 299 progress), July 2007. 301 Authors' Addresses 303 Mohamed Boucadair 304 France Telecom 305 3, Av Francois Chateau 306 Rennes, 35000 307 France 309 Email: mohamed.boucadair@orange-ftgroup.com 311 Christian Jacquenet 312 France Telecom 313 3, Av Francois Chateau 314 Rennes, 35000 315 France 317 Email: christian.jacquenet@orange-ftgroup.com 319 Dean Cheng 320 Huawei 321 USA 323 Email: Chengd@huawei.com 324 Yiu L. Lee 325 Comcast 326 USA 328 Email: Yiu_Lee@Cable.Comcast.com