idnits 2.17.1 draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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-behave-address-format], [RFC2740], [I-D.ietf-ospf-mt-ospfv3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 20, 2009) is 5301 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) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) == Outdated reference: A later version (-04) exists of draft-boucadair-behave-ipv6-portrange-03 == Outdated reference: A later version (-04) exists of draft-boucadair-dslite-interco-v4v6-02 == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-00 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-01 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-02 == Outdated reference: A later version (-10) exists of draft-ietf-ospf-af-alt-08 Summary: 3 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: April 23, 2010 D. Cheng 6 Huawei 7 Y. Lee 8 Comcast 9 October 20, 2009 11 Multi-Topology OSPFv3 for IPv4-mapped IPv6 12 draft-boucadair-ospf-v4v6-ospfv3-mt-01 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on April 23, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This memo defines two new Multi Topology Routing Identifiers (MT IDs) 60 in OSPFv3 [RFC2740]). These new MT-OSPFv3 [I-D.ietf-ospf-mt-ospfv3] 61 topologies are meant to convey routing information which is 62 restricted to IPv4-mapped IPv6 addresses 63 [I-D.ietf-behave-address-format]. The goal of running separate 64 instances for IPv4-mapped IPv6 routes is to isolate the IPv6 routing 65 table from the IPv4 routing table, and to avoid any overload due to 66 the population of the table by IPv4-inferred routes. This isolation 67 is motivated also from an operational perspective to enforce specific 68 routing policies for each topology. 70 Requirements Language 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 89 1. Introduction 91 MT-OSPFv3 [I-D.ietf-ospf-mt-ospfv3] is a mechanism that has been 92 specified to run various topologies based on several criteria such as 93 the need to distinguish the IPv6 routing topology from the IPv4 94 routing topology. Distinct MT IDs (Multi topology Identifiers) are 95 assigned by IANA (e.g., MT ID # 0 for IPv6 routing topology, MT ID # 96 3 for IPv6 multicast topology, etc.). MT ID # 5-#31 range is 97 reserved for IETF consensus. This document requests the assignment 98 of two new MT IDs for the following usages: 100 o Unicast IPv4-mapped IPv6 topology; 102 o Multicast IPv4-mapped IPv6 topology. 104 Within the double context of IPv4 address exhaustion and the IPv6- 105 IPv4 interconnection, numerous solutions are being elaborated within 106 IETF. Both translation (e.g., [I-D.ietf-behave-v6v4-xlate-stateful] 107 and [I-D.ietf-behave-v6v4-xlate]) and encapsulation (e.g., 108 [I-D.boucadair-dslite-interco-v4v6] and 109 [I-D.boucadair-behave-ipv6-portrange]) based schemes are proposed to 110 allow IPv6-IPv4 interconnection. These solutions require injecting 111 in intra-domain routing protocols routes to IPv4-mapped IPv6 112 [I-D.ietf-behave-address-format] destinations. 114 In order to prevent any overload of the native IPv6 routing table 115 with IPv4-mapped IPv6 routes, this memo defines new MT IDs which are 116 required for the activation of multiple topologies, where the native 117 IPv6 topology would be distinct from the IPv4-mapped topology. This 118 is also motivated for operational reasons and to ease the migration 119 to full IPv6. As a result, the unicast IPv4-mapped IPv6 topology is 120 used for unicast IPv4-mapped IPv6 route computation purposes, and the 121 multicast IPv4-mapped IPv6 topology is used for multicast IPv4-mapped 122 IPv6 route computation purposes. 124 As a reminder, [I-D.ietf-ospf-af-alt] sspecifies a mechanism to 125 maintain multiple topologies. In particular, each topology is 126 created by a separate OSPFv3 instance identified by a unique Instance 127 ID. Each instance maintains its own neighbour adjacencies, link 128 state database and SPF computation. Network administrators have to 129 make their decisions based on local policies and preferences as to 130 which mechanism to deploy. If MT-OSPFv3 mechanism 131 [I-D.ietf-ospf-mt-ospfv3] is deployed in an OSPFv3 network as a 132 preference for multiple topologies, the extensions defined in this 133 memo may be used to support unicast/multicast IPv4-mapped IPv6 134 routing. 136 2. Procedure 138 This document does not require any modification to the procedure 139 specified in [I-D.ietf-ospf-mt-ospfv3]. Nevertheless, only routes to 140 IPv4-mapped IPv6 prefixes MUST be instantiated within an IPv4-mapped 141 IPv6 routing MT-OSPFv3. Concretely, the IANA prefix defined in 142 [I-D.ietf-behave-address-format] MUST be supported by default. 143 Service providers MAY also choose a LIR prefix to build the IPv4- 144 mapped IPv6 addresses. 146 3. Forwarding 148 Only incoming datagrams destined to IPv4-mapped IPv6 addresses are 149 associated (and therfore forwarded according to ) with the IPv4- 150 mapped IPv6 unicast/multicast topology, respectively. WKP and/or LIR 151 prefix defined in [I-D.ietf-behave-address-format] MUST be configured 152 in all participating nodes. 154 4. IANA Considerations 156 This document requests the following MT-OSPFv3 IDs: 158 o MT ID# for IPv4-mapped IPv6 unicast topology 160 o MT ID# for multicast IPv4-mapped IPv6 topology. 162 5. Security Considerations 164 This document does not introduce any security issue in addition to 165 those defined in [RFC2740]. 167 6. Acknowledgements 169 TBC 171 7. References 173 7.1. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, March 1997. 178 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 179 RFC 2740, December 1999. 181 7.2. Informative References 183 [I-D.boucadair-behave-ipv6-portrange] 184 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 185 Kassi-Lahlou, M., Bajko, G., Lee, Y., and T. Melia, 186 "Flexible IPv6 Migration Scenarios in the Context of IPv4 187 Address Shortage", 188 draft-boucadair-behave-ipv6-portrange-03 (work in 189 progress), October 2009. 191 [I-D.boucadair-dslite-interco-v4v6] 192 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 193 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 194 Stack lite in IPv6-only Network", 195 draft-boucadair-dslite-interco-v4v6-02 (work in progress), 196 October 2009. 198 [I-D.ietf-behave-address-format] 199 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 200 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 201 draft-ietf-behave-address-format-00 (work in progress), 202 August 2009. 204 [I-D.ietf-behave-v6v4-xlate] 205 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 206 Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in 207 progress), September 2009. 209 [I-D.ietf-behave-v6v4-xlate-stateful] 210 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 211 Address and Protocol Translation from IPv6 Clients to IPv4 212 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work 213 in progress), October 2009. 215 [I-D.ietf-ospf-af-alt] 216 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 217 Aggarwal, "Support of address families in OSPFv3", 218 draft-ietf-ospf-af-alt-08 (work in progress), July 2009. 220 [I-D.ietf-ospf-mt-ospfv3] 221 Mirtorabi, S. and A. Roy, "Multi-topology routing in 222 OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in 223 progress), July 2007. 225 Authors' Addresses 227 Mohamed Boucadair 228 France Telecom 229 3, Av Francois Chateau 230 Rennes, 35000 231 France 233 Email: mohamed.boucadair@orange-ftgroup.com 235 Christian Jacquenet 236 France Telecom 237 3, Av Francois Chateau 238 Rennes, 35000 239 France 241 Email: christian.jacquenet@orange-ftgroup.com 243 Dean Cheng 244 Huawei 245 USA 247 Email: Chengd@huawei.com 249 Yiu L. Lee 250 Comcast 251 USA 253 Email: Yiu_Lee@Cable.Comcast.com