idnits 2.17.1 draft-boucadair-isis-v4v6-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-isis-mi], [RFC5120]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances 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 23, 2010) is 5148 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 (-08) exists of draft-ietf-isis-mi-02 == 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-04 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-09 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-08 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 27, 2010 D. Cheng 6 Huawei 7 Y. Lee 8 Comcast 9 February 23, 2010 11 Multi-Topology/Multi-Instance ISIS for IPv4-Embedded IPv6 12 draft-boucadair-isis-v4v6-mt-02 14 Abstract 16 This document defines two new Multi Topology Routing Identifiers (MT 17 IDs), based on [RFC5120] and two new Instance Identifiers (MI IDs), 18 based on [I-D.ietf-isis-mi], respectively, in the Intermediate System 19 to Intermediate System. With these identifiers, an IPv4-Embedded 20 IPv6 topology is maintained for both IPv6 unicast and multicast 21 traffic. The purpose of running separate instances or topologies for 22 IPv4-Embedded IPv6 traffic is to distinguish from the native IPv6 23 routing topology, and the topology that is used for routing IPv4- 24 Embedded IPv6 datagrams only. Separate instances/topologies are also 25 meant to prevent any overload of the native IPv6 routing tables by 26 IPv4-Embedded IPv6 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 27, 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 IS-IS Topologies . . . . . . . . . . . . . . 4 87 3. IPv4-Embedded IPv6 IS-IS Instances . . . . . . . . . . . . . . 5 88 4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 5 89 5. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 90 6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 98 1. Introduction 100 Within the double context of public IPv4 address exhaustion and IPv6- 101 IPv4 interconnection, numerous solutions are being elaborated within 102 IETF. Both translation (e.g., [I-D.ietf-behave-v6v4-xlate-stateful] 103 and [I-D.ietf-behave-v6v4-xlate]) and encapsulation (e.g., 104 [I-D.boucadair-dslite-interco-v4v6] and 105 [I-D.boucadair-behave-ipv6-portrange]) based schemes are proposed to 106 allow IPv6-IPv4 interconnection. These solutions require the 107 injection of routes to IPv4-Embedded IPv6 prefixes 108 [I-D.ietf-behave-address-format] in intra-domain routing protocols . 110 In order to prevent any overload of the native IPv6 routing table 111 with IPv4-Embedded IPv6 routes, this document defines new MT IDs 112 (resp., MI IDs) which are required for the activation of multiple 113 topologies (resp., Instances), where the native IPv6 topology (resp., 114 Instance) would be distinct from the IPv4-Embedded IPv6 topology 115 (resp., Instance). Operational reasons also motivate this approach 116 which is meant to ease the migration to full IPv6. As a result, the 117 unicast IPv4-Embedded IPv6 topology (resp., Instance) is used for 118 unicast IPv4-Embedded IPv6 route computation purposes, and the 119 multicast IPv4-Embedded IPv6 topology (resp., Instance) is used for 120 multicast IPv4-Embedded IPv6 route computation purposes. 122 This document does not make any preference between the solution 123 described in [RFC5120] and [I-D.ietf-isis-mi]. Network 124 administrators have to make their decisions based on local policies. 125 If the multi-instance mechanism is deployed in an IS-IS network as a 126 preference for multiple topologies, the MI extensions defined in this 127 document may be used to support unicast/multicast IPv4-Embedded IPv6 128 routing. If M-ISIS mechanism is deployed in an IS-IS network as a 129 preference for multiple topologies, the MT extensions defined in this 130 document may be used to support unicast/multicast IPv4-Embedded IPv6 131 routing. 133 2. IPv4-Embedded IPv6 IS-IS Topologies 135 M-ISIS [RFC5120] is a mechanism that has been specified to run within 136 a single IS-IS [RFC1195] domain where various logical IS-IS 137 topologies are deployed, based on several criteria such as the need 138 to differentiate IPv6 topologies from IPv4 topologies. Distinct MT 139 IDs (Multi Topology Identifiers) are assigned by IANA (e.g., MT ID # 140 0 for standard topology, MT ID # 2 for IPv6 routing topology, etc.). 141 MT ID # 6-#3995 range is reserved for IETF consensus. This document 142 requests the assignment of two new MT IDs for the following usages: 144 o IPv4-Embedded IPv6 unicast topology; 146 o IPv4-Embedded IPv6 multicast topology. 148 3. IPv4-Embedded IPv6 IS-IS Instances 150 [I-D.ietf-isis-mi] specifies a mechanism to map each address family 151 (AF) to a separate IS-IS Instance identified by an ID. Accepted ID 152 values are 0 to 65535. Instance ID#0 is used by default (legacy 153 systems). This document requests the assignment of two new MI-IS-IS 154 Instance IDs for the following usages: 156 o IPv4-Embedded IPv6 unicast AF; 158 o IPv4-Embedded IPv6 multicast AF. 160 4. Provisioning 162 Adequate provisioning must be done according to [RFC5120] and 163 [I-D.ietf-isis-mi], respectively, based on the corresponding 164 mechanism that is actually used in an IS-IS network, in order to have 165 a fully-connected IPv4-Embedded IPv6 unicast or multicast topology. 167 5. Procedure 169 This document does not require any modification to the procedure 170 specified in [RFC5120] nor in [I-D.ietf-isis-mi]. Nevertheless, 171 routes to IPv4-Embedded IPv6 addresses or prefixes MUST be 172 instantiated within an IPv4-Embedded IPv6 M-ISIS (resp., MI-ISIS). 173 Concretely, the WKP prefix (i.e., 64:FF9B::/96) defined in 174 [I-D.ietf-behave-address-format] must be supported by default. 175 Service providers may also choose a LIR prefix to build the IPv4- 176 Embedded IPv6 addresses. 178 6. Forwarding 180 Only incoming datagrams destined to IPv4-Embedded IPv6 addresses are 181 associated (and forwarded accordingly) with the IPv4-Embedded IPv6 182 unicast/multicast topology, respectively. WKP (i.e., 64:FF9B::/96) 183 and/or LIR prefix defined in [I-D.ietf-behave-address-format] must be 184 configured in all participating nodes. 186 7. IANA Considerations 188 TBC. 190 8. Security Considerations 192 This document does not introduce any security issue in addition to 193 those defined in [RFC5120] and [I-D.ietf-isis-mi]. 195 9. References 197 9.1. Normative References 199 [I-D.ietf-isis-mi] 200 Previdi, S., Ginsberg, L., Shand, M., Ward, D., and A. 201 Roy, "IS-IS Multi-Instance", draft-ietf-isis-mi-02 (work 202 in progress), October 2009. 204 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 205 dual environments", RFC 1195, December 1990. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 211 Topology (MT) Routing in Intermediate System to 212 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 214 9.2. Informative References 216 [I-D.boucadair-behave-ipv6-portrange] 217 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 218 Kassi-Lahlou, M., Bajko, G., Lee, Y., Melia, T., and O. 219 Vautrin, "Flexible IPv6 Migration Scenarios in the Context 220 of IPv4 Address Shortage", 221 draft-boucadair-behave-ipv6-portrange-04 (work in 222 progress), October 2009. 224 [I-D.boucadair-dslite-interco-v4v6] 225 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 226 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 227 Stack lite in IPv6-only Network", 228 draft-boucadair-dslite-interco-v4v6-02 (work in progress), 229 October 2009. 231 [I-D.ietf-behave-address-format] 232 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 233 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 234 draft-ietf-behave-address-format-04 (work in progress), 235 January 2010. 237 [I-D.ietf-behave-v6v4-xlate] 238 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 239 Algorithm", draft-ietf-behave-v6v4-xlate-09 (work in 240 progress), February 2010. 242 [I-D.ietf-behave-v6v4-xlate-stateful] 243 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 244 NAT64: Network Address and Protocol Translation from IPv6 245 Clients to IPv4 Servers", 246 draft-ietf-behave-v6v4-xlate-stateful-08 (work in 247 progress), January 2010. 249 Authors' Addresses 251 Mohamed Boucadair 252 France Telecom 253 3, Av Francois Chateau 254 Rennes, 35000 255 France 257 Email: mohamed.boucadair@orange-ftgroup.com 259 Christian Jacquenet 260 France Telecom 261 3, Av Francois Chateau 262 Rennes, 35000 263 France 265 Email: christian.jacquenet@orange-ftgroup.com 267 Dean Cheng 268 Huawei 269 USA 271 Email: Chengd@huawei.com 272 Yiu L. Lee 273 Comcast 274 USA 276 Email: Yiu_Lee@Cable.Comcast.com