idnits 2.17.00 (12 Aug 2021) /tmp/idnits47192/draft-boucadair-isis-v4v6-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], [I-D.ietf-isis-mi], [RFC1195]), 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 4589 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-behave-ipv6-portrange-03 == 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-isis-mi has been published as RFC 6822 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: April 23, 2010 D. Cheng 6 Huawei 7 Y. Lee 8 Comcast 9 October 20, 2009 11 IPv4-mapped IPv6 Instance IDs in IS-IS 12 draft-boucadair-isis-v4v6-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 IS-IS [RFC1195]). These new Instance IDs [I-D.ietf-isis-mi] are 61 meant to instantiate distinct IS-IS instances to convey routing 62 information which is restricted to IPv4-mapped IPv6 addresses 63 [I-D.ietf-behave-address-format]. The ultimate goal of running 64 separate instances for IPv4-mapped IPv6 routes is to isolate the IPv6 65 routing table from the IPv4 routing table, and to avoid any overload 66 due to the population of the table by IPv4-mapped IPv6 routes. This 67 isolation is motivated also from an operational perspective to allow 68 the enforcement of specific 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 89 1. Introduction 91 [I-D.ietf-isis-mi] specifies a mechanism to map each address family 92 to a separate IS-IS [RFC1195] Instance identified by an ID. Accepted 93 ID values are 0 to 65535. Instance ID#0 is used by default (legacy 94 systems). This document requests the assignment of two new MI-IS-IS 95 Instance IDs for the following usages: 97 o Unicast IPv4-mapped IPv6 IS-IS routing instance; 99 o Multicast IPv4-mapped IPv6 IS-IS routing instance. 101 Within the double context of IPv4 address exhaustion and the IPv6- 102 IPv4 interconnection, numerous solutions are being elaborated within 103 IETF. Both translation (e.g., [I-D.ietf-behave-v6v4-xlate-stateful] 104 and [I-D.ietf-behave-v6v4-xlate]) and encapsulation (e.g., 105 [I-D.boucadair-dslite-interco-v4v6] and 106 [I-D.boucadair-behave-ipv6-portrange]) schemes are proposed to 107 facilitate IPv6-IPv4 interconnection. These solutions require the 108 injection of routes to IPv4-mapped IPv6 109 [I-D.ietf-behave-address-format] destination prefixes in intra-domain 110 routing protocols. In order to prevent any overload of the native 111 IPv6 routing table with IPv4-mapped IPv6 routes, this memo defines 112 new Instance IDs which are required for the activation of several 113 IS-IS instances for unicast/multicast IPv4-mapped IPv6. Such new 114 instances are also meant to facilitate the operation of networks that 115 convey IPv4 and IPv6 traffic and to ease the migration to full IPv6. 116 As a result, when a separate IS-IS instance for unicast IPv4-mapped 117 IPv6 address family is activated, a distinct IS-IS adjacency table is 118 created, based on which unicast IPv4-mapped IPv6 routes is computed. 119 Likewise, when a separate IS-IS instance for multicast IPv4- mapped 120 IPv6 address family is activated, a distinct IS-IS adjacency table is 121 created for multicast IPv4-mapped IPv6 route computation purposes. 123 In case [RFC5120] is deployed, new Multi Topology IDs are required to 124 be defined. As a reminder, [RFC5120] specifies a mechanism to 125 maintain multiple IS-IS topologies within the same IS-IS domain. 126 This memo does not make any preference between the solution described 127 in [RFC5120] and [I-D.ietf-isis-mi]. Network administrators have to 128 make their decisions based on local policies and preferences. If the 129 multi-instance mechanism [I-D.ietf-isis-mi] is deployed in an IS-IS 130 network as a preference for multiple topologies, the extensions as 131 defined in this memo may be used to support unicast/multicast IPv4- 132 mapped IPv6 routing, respectively. 134 2. Procedure 136 This document does not require any modification to the procedure 137 specified in [I-D.ietf-isis-mi]. Nevertheless, only routes to IPv4- 138 mapped IPv6 prefixes MUST be instantiated within a IPv4-mapped IPv6 139 routing M-ISIS Concretely, the IANA prefix defined in 140 [I-D.ietf-behave-address-format] MUST be supported by default. 141 Service providers MAY also choose a LIR prefix to build the IPv4- 142 mapped IPv6 addresses. 144 3. Forwarding 146 Only incoming datagrams destined to IPv4-mapped IPv6 addresses are 147 associated (and therefore are forwarded) with the IPv4-mapped IPv6 148 unicast/multicast IS-IS Instance, respectively. WKP and/or LIR 149 prefix defined in [I-D.ietf-behave-address-format] MUST be configured 150 in all participating nodes. 152 4. IANA Considerations 154 This document requests the following IS-IS Instance IDs: 156 o Instance ID# for IPv4-mapped IPv6 unicast AF; 158 o Instance ID# for multicast IPv4-mapped IPv6 AF. 160 5. Security Considerations 162 This document does not introduce any security issue in addition to 163 those defined in [I-D.ietf-isis-mi]. 165 6. Acknowledgements 167 TBC 169 7. References 171 7.1. Normative References 173 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 174 dual environments", RFC 1195, December 1990. 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 180 Topology (MT) Routing in Intermediate System to 181 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 183 7.2. Informative References 185 [I-D.boucadair-behave-ipv6-portrange] 186 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 187 Kassi-Lahlou, M., Bajko, G., Lee, Y., and T. Melia, 188 "Flexible IPv6 Migration Scenarios in the Context of IPv4 189 Address Shortage", 190 draft-boucadair-behave-ipv6-portrange-03 (work in 191 progress), October 2009. 193 [I-D.boucadair-dslite-interco-v4v6] 194 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 195 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 196 Stack lite in IPv6-only Network", 197 draft-boucadair-dslite-interco-v4v6-02 (work in progress), 198 October 2009. 200 [I-D.ietf-behave-address-format] 201 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 202 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 203 draft-ietf-behave-address-format-00 (work in progress), 204 August 2009. 206 [I-D.ietf-behave-v6v4-xlate] 207 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 208 Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in 209 progress), September 2009. 211 [I-D.ietf-behave-v6v4-xlate-stateful] 212 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 213 Address and Protocol Translation from IPv6 Clients to IPv4 214 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work 215 in progress), October 2009. 217 [I-D.ietf-isis-mi] 218 Previdi, S., Ginsberg, L., Shand, M., Ward, D., and A. 219 Roy, "IS-IS Multi-Instance", draft-ietf-isis-mi-02 (work 220 in progress), October 2009. 222 Authors' Addresses 224 Mohamed Boucadair 225 France Telecom 226 3, Av Francois Chateau 227 Rennes, 35000 228 France 230 Email: mohamed.boucadair@orange-ftgroup.com 232 Christian Jacquenet 233 France Telecom 234 3, Av Francois Chateau 235 Rennes, 35000 236 France 238 Email: christian.jacquenet@orange-ftgroup.com 240 Dean Cheng 241 Huawei 242 USA 244 Email: Chengd@huawei.com 246 Yiu L. Lee 247 Comcast 248 USA 250 Email: Yiu_Lee@Cable.Comcast.com