idnits 2.17.1 draft-boucadair-ospf-v4v6-ospfv3-mt-00.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 19, 2009) is 5303 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 22, 2010 D. Cheng 6 Huawei 7 Y. Lee 8 Comcast 9 October 19, 2009 11 Multi-Topology OSPFv3 for IPv4-mapped IPv6 12 draft-boucadair-ospf-v4v6-ospfv3-mt-00 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 22, 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 ultimate goal of instantiating 64 dedicated topologies for IPv4-mapped IPv6 is to isolate the native 65 IPv6 routing table from the IPv4 and to prevent from being overloaded 66 by IPv4-mapped one. This isolation is motivated also from an 67 operational perspective to enforce specific engineering policies for 68 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 isolating IPv6 routing from IPv4 one. Distinct MT IDs (Multi 94 topology Identifiers) are assigned by IANA (e.g., MT ID # 0 for IPv6 95 routing topology, MT ID # 3 for IPv6 multicast topology, etc.). MT 96 ID # 5-#31 range is reserved for IETF consensus. This document 97 requests the assignment of two new MT IDs for the following usages: 99 o Unicast IPv4-mapped IPv6 topology; 101 o Multicast IPv4-mapped IPv6 topology. 103 In the context of IPv4 address exhaustion and the IPv6-IPv4 104 interconnection, numerous solutions are currently elaborated within 105 IETF. Both translation (e.g., [I-D.ietf-behave-v6v4-xlate-stateful] 106 and [I-D.ietf-behave-v6v4-xlate]) and encapsulation (e.g., 107 [I-D.boucadair-dslite-interco-v4v6] and 108 [I-D.boucadair-behave-ipv6-portrange]) based schemes are proposed to 109 allow IPv6-IPv4 interconnection. These solutions require injecting 110 in intra-domain routing protocols routes to IPv4-mapped IPv6 111 [I-D.ietf-behave-address-format] destinations. 113 In order to prevent from polluting the native IPv6 routing table with 114 IPv4-mapped IPv6 routes, this memo defines new MT IDs which are 115 required for the activation of multiple topologies to isolate the 116 native IPv6 routing table from the IPv4-mapped one. This is also 117 motivated for operational reasons and to ease the migration to full 118 IPv6. And as a result, the unicast IPv4-mapped IPv6 topology is used 119 for calculating routes for unicast IPv4-mapped IPv6 packets, and the 120 multicast IPv4-mapped IPv6 topology is for calculating routes for 121 multicast IPv4-mapped IPv6 packets. 123 As a reminder, [I-D.ietf-ospf-af-alt] specifies an alternative 124 mechanism to maintain multiple topologies, and in particular, each 125 topology is created by a separate OSPFv3 instance identified by a 126 unique Instance ID. Each instance maintains its own neighbour 127 adjacencies, link state database and SPF computation. Network 128 administrators have to make their decisions based on local policies 129 and preferences as which mechanism to deploy. If MT-OSPFv3 mechanism 130 [I-D.ietf-ospf-mt-ospfv3] is deployed in an OSPFv3 network as a 131 preference for multiple topologies, the extensions as defined in this 132 memo may be used to support unicast/multicast IPv4-mapped IPv6 133 routing. 135 2. Procedure 137 This document does not require any modification to the procedure 138 specified in [I-D.ietf-ospf-mt-ospfv3]. Nevertheless, only routes to 139 IPv4-mapped IPv6 prefixes MUST be instantiated within an IPv4-mapped 140 IPv6 routing MT-OSPFv3. Concretely, the IANA's prefix defined in 141 [I-D.ietf-behave-address-format] MUST be supported by default. 142 Service providers MAY choose a LIR prefix to build the IPv4-mapped 143 IPv6 addresses. 145 3. Forwarding 147 Only incoming datagrams destined to IPv4-mapped IPv6 addresses are 148 associated with the IPv4-mapped IPv6 unicast/multicast topology, 149 respectively. WKP and/or LIR prefix defined in 150 [I-D.ietf-behave-address-format] MUST be configured in all 151 participating nodes. 153 4. IANA Considerations 155 This document requests the following MT-OSPFv3 IDs: 157 o MT ID# for IPv4-mapped IPv6 unicast topology 159 o MT ID# for multicast IPv4-mapped IPv6 topology. 161 5. Security Considerations 163 This document does not introduce any security issue in addition to 164 those defined in [RFC2740]. 166 6. Acknowledgements 168 TBC 170 7. References 172 7.1. Normative References 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, March 1997. 177 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 178 RFC 2740, December 1999. 180 7.2. Informative References 182 [I-D.boucadair-behave-ipv6-portrange] 183 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 184 Kassi-Lahlou, M., Bajko, G., Lee, Y., and T. Melia, 185 "Flexible IPv6 Migration Scenarios in the Context of IPv4 186 Address Shortage", 187 draft-boucadair-behave-ipv6-portrange-03 (work in 188 progress), October 2009. 190 [I-D.boucadair-dslite-interco-v4v6] 191 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 192 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 193 Stack lite in IPv6-only Network", 194 draft-boucadair-dslite-interco-v4v6-02 (work in progress), 195 October 2009. 197 [I-D.ietf-behave-address-format] 198 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 199 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 200 draft-ietf-behave-address-format-00 (work in progress), 201 August 2009. 203 [I-D.ietf-behave-v6v4-xlate] 204 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 205 Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in 206 progress), September 2009. 208 [I-D.ietf-behave-v6v4-xlate-stateful] 209 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 210 Address and Protocol Translation from IPv6 Clients to IPv4 211 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work 212 in progress), October 2009. 214 [I-D.ietf-ospf-af-alt] 215 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 216 Aggarwal, "Support of address families in OSPFv3", 217 draft-ietf-ospf-af-alt-08 (work in progress), July 2009. 219 [I-D.ietf-ospf-mt-ospfv3] 220 Mirtorabi, S. and A. Roy, "Multi-topology routing in 221 OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in 222 progress), July 2007. 224 Authors' Addresses 226 Mohamed Boucadair 227 France Telecom 228 3, Av Francois Chateau 229 Rennes, 35000 230 France 232 Email: mohamed.boucadair@orange-ftgroup.com 234 Christian Jacquenet 235 France Telecom 236 3, Av Francois Chateau 237 Rennes, 35000 238 France 240 Email: christian.jacquenet@orange-ftgroup.com 242 Dean Cheng 243 Huawei 244 USA 246 Email: Chengd@huawei.com 248 Yiu L. Lee 249 Comcast 250 USA 252 Email: Yiu_Lee@Cable.Comcast.com