idnits 2.17.1 draft-carpenter-6man-whats-global-00.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 document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope'.' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2016) is 2877 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) == Missing Reference: 'ADDARCH' is mentioned on line 82, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-6man-rfc4291bis-02 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-6man-rfc4291bis' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Standards Track June 8, 2016 5 Expires: December 10, 2016 7 What does 'global' mean in IPv6? 8 draft-carpenter-6man-whats-global-00 10 Abstract 12 The word 'global' is used in two different ways in various 13 IPv6-related RFCs and an IANA registry. This document describes the 14 resulting problem. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 10, 2016. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Problem description . . . . . . . . . . . . . . . . . . . . . 2 51 2. Possible fixes . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 54 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1. Problem description 59 As defined in the IPv6 Addressing Architecture 60 [I-D.ietf-6man-rfc4291bis], most of the IPv6 address space is 61 reserved for Global Unicast addresses. The high order bits of such 62 addresses are named 'global routing prefix'. However, the word 63 'global' is not itself defined in the context of unicast addresses. 65 One subset of Global Unicast address space is defined for Unique 66 Local Addresses [RFC4193]. One can quarrel with something being 67 called 'global' and 'local' at the same time, but RFC 4193 is 68 categorical: 70 This document defines an IPv6 unicast address format that is globally 71 unique and is intended for local communications, usually inside of a 72 site. These addresses are not expected to be routable on the global 73 Internet. 74 ... 75 - Globally unique prefix (with high probability of uniqueness). 76 ... 77 - In practice, applications may treat these addresses like global 78 scoped addresses. 79 ... 80 By default, the scope of these addresses is global. That is, they 81 are not limited by ambiguity like the site-local addresses defined in 82 [ADDARCH]. Rather, these prefixes are globally unique, and as such, 83 their applicability is greater than site-local addresses. Their 84 limitation is in the routability of the prefixes, which is limited to 85 a site and any explicit routing agreements with other sites to 86 propagate them... 88 In summary: ULAs are defined in these standards track documents as 89 'global'. 91 However, the IANA registry for special-purpose IPv6 addresses 92 , and the RFC that controls it [RFC6890] 94 use the following definition: 96 o Global - A boolean value indicating whether an IP datagram whose 97 destination address is drawn from the allocated special-purpose 98 address block is forwardable beyond a specified administrative 99 domain. 101 It is evident, even from the last sentence quoted above from RFC 102 4193, that ULAs do not meet this definition of 'global'. As a 103 result, they are marked in the registry with Global = False. The 104 registry also assigns them the property Forwardable = True, which is 105 of course valid, but the fact remains that some RFCs say that ULAs 106 are global, but RFC 6890 and the registry say that they are not. 108 This inconsistency has consequences. Of course, it is always 109 possible for code that manipulates IPv6 addresses to determine with 110 certainty that a given address is, or is not, a ULA. But any code 111 that uses the property 'global' from the IANA registry as a decision 112 criterion might be wrong. 114 As an example, consider the Python 'ipaddress' module 115 , which explicitly 117 cites the IANA registry. It provides the property 'is_global' which 118 tests False for ULAs. A reader of RFC 4193 would expect True. The 119 correct test in Python (apart from an explicit match with fc00::/7) 120 is (is_private and not is_link_local). 122 2. Possible fixes 124 1. Do nothing. 126 2. Change the registry entry for ULAs to Global=True (and update 127 text and RFC 6890 accordingly). 129 3. That, plus rename the registry column from 'Global' to 'Global 130 scope'. 132 4. Change the registry entry for ULAs to Global=Undefined (and 133 update text and RFC 6890 accordingly). 135 5. Rename the registry column from 'Global' to 'Globally reachable' 136 (and update text and RFC 6890 accordingly). 138 6. That, plus add a registry column for 'Global scope'. 140 7. Your suggestion goes here. 142 3. Security Considerations 144 Misclassification of a ULA as non-global might cause it to be used 145 for a purpose that should be limited to link-local addresses for 146 security reasons. 148 4. IANA Considerations 150 If any changes are made as a result of this discussion, they will 151 require IANA actions. 153 5. Normative References 155 [I-D.ietf-6man-rfc4291bis] 156 Hinden, R. and S. Deering, "IP Version 6 Addressing 157 Architecture", draft-ietf-6man-rfc4291bis-02 (work in 158 progress), April 2016. 160 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 161 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 162 . 164 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 165 "Special-Purpose IP Address Registries", BCP 153, 166 RFC 6890, DOI 10.17487/RFC6890, April 2013, 167 . 169 Author's Address 171 Brian Carpenter 172 Department of Computer Science 173 University of Auckland 174 PB 92019 175 Auckland 1142 176 New Zealand 178 Email: brian.e.carpenter@gmail.com