idnits 2.17.1 draft-boucadair-ospf-v4v6-ospfv3-mi-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-af-alt]), 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 5295 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 IPv4-mapped IPv6 Instance IDs in OSPFv3 12 draft-boucadair-ospf-v4v6-ospfv3-mi-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 Instance Identifiers (Instance IDs) in 60 OSPFv3 [RFC2740]). These new Instance IDs [I-D.ietf-ospf-af-alt] are 61 meant to instantiate distinct OSPFv3 instances to convey routing 62 information which is specific to IPv4-mapped IPv6 address Address 63 Family [I-D.ietf-behave-address-format]. The goal of running 64 separate instances for IPv4-mapped IPv6 is to distinguish the native 65 IPv6 routing topology from the IPv4 routing topology. Separate 66 instances are also meant to prevent any overload of the native IPv6 67 routing tables by IPv4-mapped IPv6 routes. This isolation is 68 motivated also from an operational perspective to enforce specific 69 routing policies for each topology. 71 Requirements Language 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 90 1. Introduction 92 [I-D.ietf-ospf-af-alt] specifies a mechanism to map each address 93 family (AF) to a separate OSPFv3 [RFC2740] Instance identified by an 94 ID. Many Instance IDs have been reserved for different AF (e.g., 95 Instance ID #0 - #31 for IPv6 unicast AF, Instance ID#32 - #63 for 96 IPv6 multicast AF, etc.). Instance ID #0 is used by default for IPv6 97 unicast AF. This document requests to assign two new Instance IDs 98 for the IPv4-mapped IPv6 AF. They are: 100 o Unicast IPv4-mapped IPv6 AF; 102 o Multicast IPv4-mapped IPv6 AF. 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]) schemes are proposed to 110 facilitate IPv6-IPv4 interconnection. These solutions require the 111 injection of routes to IPv4-mapped IPv6 112 [I-D.ietf-behave-address-format] destinations in intra-domain routing 113 protocols. In order to prevent any overload of the native IPv6 114 routing table with IPv4-mapped IPv6 routes, this memo defines new 115 Instance IDs which are required for the activation of several OSPFv3 116 instances for unicast/multicast IPv4- inferred IPv6 route computation 117 purposes. This isolation is also motivated for operational reasons 118 and to ease the migration to full IPv6. As a result, when a separate 119 OSPFv3 instance for unicast IPv4-mapped IPv6 AF is activated, a 120 separate OSPFv3 topology is calculated. Likewise, when a separate 121 OSPFv3 instance for multicast IPv4- inferred IPv6 AF is activated, 122 another distinct OSPFv3 topology is computed. 124 In order to prevent from polluting the native IPv6 routing table with 125 IPv4-mapped IPv6 routes, this memo defines new Instance IDs which are 126 required for the activation of several OSPFv3 instances for unicast/ 127 multicast IPv4-mapped IPv6. This isolation is also motivated for 128 operational reasons and to ease the migration to full IPv6. As a 129 result, when a separate OSPFv3 instance for unicast IPv4-mapped IPv6 130 AF is activated, there creates a separate OSPFv3 topology based on 131 which unicast IPv4-mapped IPv6 routing is calculated and performed, 132 and similarly, when a separate OSPFv3 instance for multicast IPv4- 133 mapped IPv6 AF is activated, there creates a separate OSPFv3 topology 134 for multicast IPv4-mapped IPv6 routing. 136 As a reminder, [I-D.ietf-ospf-mt-ospfv3] specifies a mechanism to 137 maintain multiple OSPFv3 topologies within the same domain. This 138 memo does not make any preference between the solution described in 139 [I-D.ietf-ospf-mt-ospfv3] and [I-D.ietf-ospf-af-alt]. Network 140 administrators have to make their decisions based on local policies 141 and preferences. If the multi-instance mechanism 142 [I-D.ietf-ospf-af-alt] is deployed in an OSPFv3 network as a 143 preference for multiple topologies, the extensions defined in this 144 memo may be used to support unicast/multicast IPv4-mapped IPv6 145 routing. 147 2. Procedure 149 This document does not require any modification to the procedure 150 specified in [I-D.ietf-ospf-af-alt]. Nevertheless, only routes to 151 IPv4-mapped IPv6 prefixes MUST be instantiated within a IPv4-mapped 152 IPv6 routing MI-OSPFv3. Concretely, the IANA prefix defined in 153 [I-D.ietf-behave-address-format] MUST be supported by default. 154 Service providers MAY also choose a LIR prefix to build the IPv4- 155 mapped IPv6 addresses. 157 3. Forwarding 159 Only incoming datagrams destined to IPv4-mapped IPv6 addresses are 160 associated (and therfore forwarded according to) with the IPv4-mapped 161 IPv6 unicast/multicast OSPFv3 Instance, respectively. WKP and/or LIR 162 prefix defined in [I-D.ietf-behave-address-format] MUST be configured 163 in all participating nodes. 165 4. IANA Considerations 167 This document requests the following OSPFv3 Instance IDs: 169 o Instance ID# for IPv4-mapped IPv6 unicast AF; 171 o Instance ID# for multicast IPv4-mapped IPv6 AF. 173 5. Security Considerations 175 This document does not introduce any security issue in addition to 176 those defined in [RFC2740]. 178 6. Acknowledgements 180 TBC 182 7. References 184 7.1. Normative References 186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 187 Requirement Levels", BCP 14, RFC 2119, March 1997. 189 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 190 RFC 2740, December 1999. 192 7.2. Informative References 194 [I-D.boucadair-behave-ipv6-portrange] 195 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 196 Kassi-Lahlou, M., Bajko, G., Lee, Y., and T. Melia, 197 "Flexible IPv6 Migration Scenarios in the Context of IPv4 198 Address Shortage", 199 draft-boucadair-behave-ipv6-portrange-03 (work in 200 progress), October 2009. 202 [I-D.boucadair-dslite-interco-v4v6] 203 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 204 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 205 Stack lite in IPv6-only Network", 206 draft-boucadair-dslite-interco-v4v6-02 (work in progress), 207 October 2009. 209 [I-D.ietf-behave-address-format] 210 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 211 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 212 draft-ietf-behave-address-format-00 (work in progress), 213 August 2009. 215 [I-D.ietf-behave-v6v4-xlate] 216 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 217 Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in 218 progress), September 2009. 220 [I-D.ietf-behave-v6v4-xlate-stateful] 221 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 222 Address and Protocol Translation from IPv6 Clients to IPv4 223 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work 224 in progress), October 2009. 226 [I-D.ietf-ospf-af-alt] 227 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 228 Aggarwal, "Support of address families in OSPFv3", 229 draft-ietf-ospf-af-alt-08 (work in progress), July 2009. 231 [I-D.ietf-ospf-mt-ospfv3] 232 Mirtorabi, S. and A. Roy, "Multi-topology routing in 233 OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in 234 progress), July 2007. 236 Authors' Addresses 238 Mohamed Boucadair 239 France Telecom 240 3, Av Francois Chateau 241 Rennes, 35000 242 France 244 Email: mohamed.boucadair@orange-ftgroup.com 246 Christian Jacquenet 247 France Telecom 248 3, Av Francois Chateau 249 Rennes, 35000 250 France 252 Email: christian.jacquenet@orange-ftgroup.com 254 Dean Cheng 255 Huawei 256 USA 258 Email: Chengd@huawei.com 260 Yiu L. Lee 261 Comcast 262 USA 264 Email: Yiu_Lee@Cable.Comcast.com