idnits 2.17.1 draft-boucadair-isis-v4v6-mi-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], [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 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) == 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 (-08) exists of draft-ietf-isis-mi-02 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 22, 2010 D. Cheng 6 Huawei 7 Y. Lee 8 Comcast 9 October 19, 2009 11 IPv4-mapped IPv6 Instance IDs in IS-IS 12 draft-boucadair-isis-v4v6-mi-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 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 is to isolate the native IPv6 65 routing table from the IPv4 and to prevent to be overloaded by IPv4- 66 mapped one. This isolation is motivated also from an operational 67 perspective to allow specific engineering policies for each instance. 69 Requirements Language 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 88 1. Introduction 90 [I-D.ietf-isis-mi] specifies a mechanism to map each address family 91 to a separate IS-IS [RFC1195] Instance identified by an ID. Accepted 92 ID values are 0 to 65535. Instance ID#0 is used by default (legacy 93 systems). This document requests the assignment of two new MI-IS-IS 94 Instance IDs for the following usages: 96 o Unicast IPv4-mapped IPv6 IS-IS routing instance; 98 o Multicast IPv4-mapped IPv6 IS-IS routing instance. 100 In the context of IPv4 address exhaustion and the IPv6-IPv4 101 interconnection, numerous solutions are currently 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 injecting 107 in intra-domain routing protocols routes to IPv4-mapped IPv6 108 [I-D.ietf-behave-address-format] destinations. In order to prevent 109 from polluting the native IPv6 routing table with IPv4-mapped IPv6 110 routes, this memo defines new Instance IDs which are required for the 111 activation of several IS-IS instances for unicast/multicast IPv4- 112 mapped IPv6. This isolation is also motivated for operational 113 reasons and to ease the migration to full IPv6. As a result, when a 114 separate IS-IS instance for unicast IPv4-mapped IPv6 address family 115 is activated, there creates a separate IS-IS adjacency table based on 116 which unicast IPv4-mapped IPv6 routing is calculated and performed, 117 and similarly, when a separate IS-IS instance for multicast IPv4- 118 mapped IPv6 address family is activated, there creates a separate 119 IS-IS adjacency table for multicast IPv4-mapped IPv6 routing. 121 In case [RFC5120] is deployed, new Multi Topology IDs are required to 122 be defined. As a reminder, [RFC5120] specifies an alternative 123 mechanism to maintain multiple IS-IS topologies within the same IS-IS 124 domain. This memo does not make any preference between the solution 125 described in [RFC5120] and [I-D.ietf-isis-mi]. Network 126 administrators have to make their decisions based on local policies 127 and preferences. If multi-instance mechanism [I-D.ietf-isis-mi] is 128 deployed in an IS-IS network as a preference for multiple topologies, 129 the extensions as defined in this memo may be used to support 130 unicast/multicast IPv4-mapped IPv6 routing, respectively. 132 2. Procedure 134 This document does not require any modification to the procedure 135 specified in [I-D.ietf-isis-mi]. Nevertheless, only routes to IPv4- 136 mapped IPv6 prefixes MUST be instantiated within a IPv4-mapped IPv6 137 routing M-ISIS Concretely, the IANA's prefix defined in 138 [I-D.ietf-behave-address-format] MUST be supported by default. 139 Service providers MAY choose a LIR prefix to build the IPv4-mapped 140 IPv6 addresses. 142 3. Forwarding 144 Only incoming datagrams destined to IPv4-mapped IPv6 addresses are 145 associated with the IPv4-mapped IPv6 unicast/multicast IS-IS 146 Instance, respectively. WKP and/or LIR prefix defined in 147 [I-D.ietf-behave-address-format] MUST be configured in all 148 participating nodes. 150 4. IANA Considerations 152 This document requests the following IS-IS Instance IDs: 154 o Instance ID# for IPv4-mapped IPv6 unicast AF; 156 o Instance ID# for multicast IPv4-mapped IPv6 AF. 158 5. Security Considerations 160 This document does not introduce any security issue in addition to 161 those defined in [I-D.ietf-isis-mi]. 163 6. Acknowledgements 165 TBC 167 7. References 169 7.1. Normative References 171 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 172 dual environments", RFC 1195, December 1990. 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, March 1997. 177 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 178 Topology (MT) Routing in Intermediate System to 179 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 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-isis-mi] 216 Previdi, S., Ginsberg, L., Shand, M., Ward, D., and A. 217 Roy, "IS-IS Multi-Instance", draft-ietf-isis-mi-02 (work 218 in progress), October 2009. 220 Authors' Addresses 222 Mohamed Boucadair 223 France Telecom 224 3, Av Francois Chateau 225 Rennes, 35000 226 France 228 Email: mohamed.boucadair@orange-ftgroup.com 230 Christian Jacquenet 231 France Telecom 232 3, Av Francois Chateau 233 Rennes, 35000 234 France 236 Email: christian.jacquenet@orange-ftgroup.com 238 Dean Cheng 239 Huawei 240 USA 242 Email: Chengd@huawei.com 244 Yiu L. Lee 245 Comcast 246 USA 248 Email: Yiu_Lee@Cable.Comcast.com