idnits 2.17.1 draft-ietf-ospf-ospfv3-iid-registry-update-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 ([RFC5838]), 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 (Using the creation date from RFC5838, updated by this document, for RFC5378 checks: 2004-04-06) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2013) is 4018 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 5226 (Obsoleted by RFC 8126) -- No information found for draft-ietf-ospf-ipv4 - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Retana 3 Internet-Draft Cisco Systems, Inc. 4 Updates: 5838 (if approved) D. Cheng 5 Intended status: Standards Track Huawei Technologies 6 Expires: October 28, 2013 April 26, 2013 8 OSPFv3 Instance ID Registry Update 9 draft-ietf-ospf-ospfv3-iid-registry-update-04 11 Abstract 13 This document modifies the "Unassigned" number space in the IANA 14 "OSPFv3 Instance ID Address Family Values" registry by dividing it in 15 two halves, one half Unassigned but managed via Standards Action, and 16 the other Reserved for Private Use. It updates [RFC5838]. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 28, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. OSPFv3 Instance ID Address Family Values Registry Update . . 3 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 6.2. Informative References . . . . . . . . . . . . . . . . . 4 60 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 4 61 A.1. Changes between the -00 and -01 versions. . . . . . . . . 4 62 A.2. Changes between the -01 and -02 versions. . . . . . . . . 4 63 A.3. Changes between the -02 and -03 versions. . . . . . . . . 4 64 A.4. Changes between the -03 and -04 versions. . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 [RFC5838] defined the "OSPFv3 Instance ID Address Family Values" 70 registry for the purpose of mapping OSPFv3 Instance IDs to different 71 address families. The following table lists the value ranges as 72 allocated for [RFC5838]. 74 +---------------------------+-------------------+-------------------+ 75 | Instance ID Range | Description | Assignment Policy | 76 +---------------------------+-------------------+-------------------+ 77 | Instance ID # 0 - # 31 | IPv6 unicast AF | Already Assigned | 78 | Instance ID # 32 - # 63 | IPv6 multicast AF | Already Assigned | 79 | Instance ID # 64 - # 95 | IPv4 unicast AF | Already Assigned | 80 | Instance ID # 96 - # 127 | IPv4 multicast AF | Already Assigned | 81 | Instance ID # 128 - # 255 | Unassigned | Standards Action | 82 +---------------------------+-------------------+-------------------+ 84 In some networks additional OSPFv3 instances may be required to 85 operationally identify specific applications. This need requires a 86 pool of Instance IDs that the operator may locally assign for that 87 purpose. 89 For example, [I-D.ietf-ospf-ipv4-embedded-ipv6-routing] describes an 90 application in which IPv4-embedded IPv6 addresses [RFC6052] are used 91 to transport IPv4 packets over an IPv6 network. While the 92 IPv4-embedded IPv6 addresses do in fact represent IPv6 destinations, 93 it would be operationally benefitial to be able to easily identify 94 the the specific application by having a separate space to do so. 95 This benefit is enabled by the allocation of a range of Private Use 96 Instance IDs. 98 This document updates [RFC5838] by modifying the "OSPFv3 Instance ID 99 Address Family Values" registry. If divides the original Unassinged 100 space in two halves, one half Unassigned but managed via Standards 101 Action, and the other Reserved for Private Use. 103 2. OSPFv3 Instance ID Address Family Values Registry Update 105 The IANA "OSPFv3 Instance ID Address Family Values" registry must be 106 updated as follows: 108 +---------------------------+-------------+-----------------------+ 109 | Instance ID Range | Description | Assignment Policy | 110 +---------------------------+-------------+-----------------------+ 111 | Instance ID # 128 - # 191 | Unassigned | Standards Action | 112 | Instance ID # 192 - # 255 | Reserved | Private Use [RFC5226] | 113 +---------------------------+-------------+-----------------------+ 115 3. IANA Considerations 117 This document requests the modification of the "OSPFv3 Instance ID 118 Address Family Values" registry as described in Section 2. The 119 reference to [RFC5838] should be removed from the registry for the 120 modified ranges. 122 4. Security Considerations 124 This document modifies the assignment policy of an IANA registry 125 defined in [RFC5838]. It does not introduce any new security issues. 127 5. Acknowledgements 129 Many thanks to Acee Lindem, Stewart Bryant, Nevil Brownlee, Pearl 130 Liang, Ben Campbell, Adrian Farrel and Richard Barnes for their 131 review and input. 133 6. References 134 6.1. Normative References 136 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 137 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 138 May 2008. 140 6.2. Informative References 142 [I-D.ietf-ospf-ipv4-embedded-ipv6-routing] 143 Cheng, D., Boucadair, M., and A. Retana, "Routing for 144 IPv4-embedded IPv6 Packets", draft-ietf-ospf-ipv4 145 -embedded-ipv6-routing-11 (work in progress), April 2013. 147 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 148 Aggarwal, "Support of Address Families in OSPFv3", RFC 149 5838, April 2010. 151 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 152 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 153 October 2010. 155 Appendix A. Change Log 157 This section to be removed by the RFC Editor before publication. 159 A.1. Changes between the -00 and -01 versions. 161 o Eliminated rfc2119 keywords, section about Requirements Language 162 and corresponding reference. 164 o Updated acks. 166 A.2. Changes between the -01 and -02 versions. 168 o Added indicated that this draft updates rfc5838. 170 o Clarified the description of the 'Private Use' range to 171 'Reserved'. 173 o Added the need to remove the reference to rfc5838 from the updated 174 registry fields. 176 o Updated acks. 178 A.3. Changes between the -02 and -03 versions. 180 o Inserted example of the motivation. 182 o Updated acks. 184 A.4. Changes between the -03 and -04 versions. 186 o Added an explanation of the update to RFC5838 (Abstract and 187 Introduction). 189 o In the Introduction, clarified that the table represents the 190 allocation made in RFC5838. 192 o Added text to clarify the reason we need a Private Use space. 194 o Updated acks. 196 o Added a reference to RFC6052. 198 Authors' Addresses 200 Alvaro Retana 201 Cisco Systems, Inc. 202 7025 Kit Creek Rd. 203 Research Triangle Park, NC 27709 204 USA 206 Email: aretana@cisco.com 208 Dean Cheng 209 Huawei Technologies 210 2330 Central Expressway 211 Santa Clara, California 95050 212 USA 214 Email: dean.cheng@huawei.com