draft-hartmann-6man-addresspartnaming.nroff

   1 .pl 10.0i
   2 .po 0
   3 .ll 7.2i
   4 .lt 7.2i
   5 .nr LL 7.2i
   6 .nr LT 7.2i
   7 .ds RF [Page %]
   8 .ds LH Internet Draft
   9 .ds CH Naming IPv6 address parts
  10 .ds LF Donnerhacke, Hartmann
  11 .ds RH May 6, 2011
  12 .ds CF Expires November 5, 2011
  13 .hy 0
  14 .ad l
  15 .nf
  16 .\" 5678901234567 check 72 column width 12345678901234567890123456789012
  17 Internet Draft                                            L. Donnerhacke
  18 Category: Proposed Standard                                       Editor
  19 Updates: 4291, 5952                                     Richard Hartmann
  20 Expires: November 5, 2011                                         Editor
  21                                                              May 6, 2011
  22
  23 .ce 2
  24 Naming IPv6 address parts
  25 draft-hartmann-6man-addresspartnaming-01
  26
  27 .fi
  28 .in 3
  29 .ti 0
  30 Status of this Memo
  31
  32 This Internet-Draft is submitted to IETF in full conformance with the
  33 provisions of BCP 78 and BCP 79.
  34
  35 Internet-Drafts are working documents of the Internet Engineering Task
  36 Force (IETF), its areas, and its working groups.  Note that other
  37 groups may also distribute working documents as Internet-Drafts.
  38
  39 Internet-Drafts are draft documents valid for a maximum of six months
  40 and may be updated, replaced, or obsoleted by other documents at any
  41 time.  It is inappropriate to use Internet-Drafts as reference material
  42 or to cite them other than as "work in progress."
  43
  44 The list of current Internet-Drafts can be accessed at
  45 http://www.ietf.org/ietf/1id-abstracts.txt.
  46
  47 The list of Internet-Draft Shadow Directories can be accessed at
  48 http://www.ietf.org/shadow.html.
  49
  50 This Internet-Draft will expire on October 5, 2011.
  51
  52 .ti 0
  53 Copyright Notice
  54
  55 Copyright (c) 2011 IETF Trust and the persons identified as the document
  56 authors.  All rights reserved.
  57
  58 This document is subject to BCP 78 and the IETF Trust's Legal Provisions
  59 Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect
  60 on the date of publication of this document.  Please review these documents
  61 carefully, as they describe your rights and restrictions with respect to
  62 this document.
  63
  64 .bp
  65 .ti 0
  66 Abstract
  67
  68 In the daily communication between technicians, engineers and other people
  69 who need to deal with computer networks, it is often necessary to refer to
  70 particular parts of IP addresses. In the world of IPv4, the term "octet" is
  71 well established, however as the use of IPv6 is spreading, it becomes
  72 apparent that there is no such commonly accepted term for IPv6 addresses.
  73
  74 Discussing and explaining technical matters become difficult when different
  75 people use different terms for the same thing. Therefore, this document
  76 discusses several naming proposal for those 16bit pieces of IPv6 addreses.
  77
  78 .in 0
  79 Table of Contents
  80
  81 .nf
  82 .so draft-hartmann-6man-addresspartnaming.toc
  83 .fi
  84
  85 .hy 14
  86 .in 3
  87 .ti 0
  88 1. Introduction
  89
  90 Verbal and written communication requires a common set of terms, easily
  91 understood by every potential party. While deploying IPv6, when refering to
  92 segments of IPv6 addresses, confusion regularly arises due to the usage of
  93 different and sometimes conflicting nomenclature for the same pieces of
  94 information.
  95
  96 [IPV6Addr] is the normative reference to IPv6 addressing and avoids to coin
  97 a special term for the subject of this document itself:
  98 .br
  99 .in 6
 100 The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four
 101 hexadecimal digits of the eight 16-bit pieces of the address.
 102
 103 .in 3
 104 [IPv6Rep] is the normative reference to IPv6 address text representation and
 105 introduces the term "16-bit field" or short "field".
 106
 107 .bp
 108 .ti 0
 109 2. Rationale
 110
 111 While we readily agree that the naming of IPv6 address parts is not the most
 112 pressing concern the Internet is facing today, a common nomenclature is
 113 important for efficient communication.
 114
 115 In IPv6 deployments the delimiting colons are regularly used to facilitate
 116 the separation of labels discerning not only administrative boundaries but
 117 also network segments and distinct infrastructure components. Consequently
 118 the values between the colons are frequently refered to especially in
 119 communication regarding coordinative matters.
 120
 121 Time spent explaining what one is referring to is wasted and conflicting
 122 names can lead to misunderstanding while the usage of a common term helps
 123 facilitating quick understanding.
 124
 125 To solve this problem, the specification of a precise and recognizable term
 126 is advised.
 127
 128 A typical ambiguity occurs in [IPv6Rep] which uses the term "field" or
 129 "16-bit field" for the term in question. This case is interesting because
 130 there was a short IETF WG discussion which term should be used.
 131 .in 6
 132 If an IPv6 address field in a certificate was incorrectly verified by
 133 converting it to text ...
 134
 135 .in 3
 136 Since parts of the internet community only accept authoritative advice
 137 substantiated by a published document, also known as the 'citation needed'
 138 approach, it is helpful to have a definite source.
 139
 140 .ti 0
 141 3. Naming Considerations
 142
 143 Any term that can be confused with other technical terms due to phonetic
 144 similarities can lead to misconfiguration causing reachability and security
 145 risks to the involved and third parties. Even with English being the
 146 preferred language in the IT world today, a good name should describe the
 147 technical matter precisely while being easy to remember, spell and pronounce
 148 in as many languages as possible.
 149
 150 .bp
 151 .ti 0
 152 4. hextet
 153
 154 "hexadectet" is directly derived from IPv4's "octet", thus technically
 155 correct and convenient to get used to. Because it is harder to pronounce,
 156 the short form "hextet" is used.
 157
 158 A hextet refers to a 16 bit entity, aligned by colons.
 159
 160 "hextet" MUST be used in all technical documents and specifications refering
 161 to IPv6 address parts. It SHOULD be used in all informal communication,
 162 written or otherwise
 163
 164 .ti 0
 165 5. Security Considerations
 166
 167 This memo does not directly discuss security issues, however the lack of a
 168 common, well established term could lead to misinterpretation, possibly
 169 resulting in insecure configurations and other problems.
 170
 171 .ti 0
 172 6. IANA Considerations
 173
 174 No assignments by the IANA are required. However it will be required
 175 that the IANA adopts the term in future documents.
 176
 177 .hy 0
 178 .in 14
 179 .ti 0
 180 7. References
 181
 182 .ti 0
 183 7.1. Normative References
 184
 185 .ti 3
 186 [IPV6Addr] Deering, S. and R. Hinden, "IP Version 6 Addressing Architecture",
 187 RFC 4291, February 2006
 188
 189 .ti 3
 190 [IPv6Rep] Kawamura, S. and Kawashima, M., "A Recommendation for IPv6
 191 Address Text Representation", RFC 5952, August 2010
 192
 193 .ti 3
 194 [Q.6]     ITU-T, "Advantages of international automatic working",
 195 Fascicle VI.1 of the Blue Book, 1988
 196
 197 .ti 3
 198 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement
 199 Levels
 200
 201 .bp
 202 .ti 0
 203 7.2. Informal References
 204
 205 .ti 3
 206 [greg]     http://etherealmind.com/network-dictionary-chazwazza/, Sept 5, 2010
 207
 208 .in 3
 209 .ti 0
 210 8. Acknowledgements
 211
 212 Thanks go to Greg Ferro who initiated the discussion by proposing the term
 213 "chazwazza".[greg]
 214
 215 Many thanks to all everyone who contributed to this document and participated
 216 in the poll, whittling down the other propoals, which are described in
 217 former versions of this memo: Chazwazza, Chunk, Column, Colonade, Colonnade,
 218 Doctet, Field, Hexadectet, Hit, Orone, Part, Provider Number, Customer
 219 Number, Network Number, Quad nibble, Qibble, Segment, Tuple, and Word.
 220
 221 The inital version of this document was created following the spirit of
 222 [Q.6].
 223
 224 .bp
 225 .ti 0
 226 Authors' Addresses
 227
 228 .nf
 229 Lutz Donnerhacke
 230 Leutragraben 1
 231 07743 Jena
 232 Germany
 233 Tel: 1.6.5.3.7.5.1.4.6.3.9.4.e164.arpa.
 234 EMail: lutz@thur.de
 235
 236 Richard Hartmann
 237 Munich
 238 Germany
 239 Email: richih.mailinglist@gmail.com
 240 IRC: RichiH@{freenode,OFTC,IRCnet}
 241 http://richardhartmann.de
 242
 243 Michael Horn
 244 Po Box 540153
 245 10042 Berlin
 246 Germany
 247 http://nibbler.tel/
 248
 249 Kay Rechthien
 250 Netsign GmbH
 251 Lindenallee 27
 252 14050 Berlin
 253 Germany
 254 EMail: kre@netsign.eu
 255
 256 Leon Weber
 257 Ahornstrasse 5d
 258 01458 Ottendorf-Okrilla
 259 Germany
 260 EMail: leon@whitejack.org
 261
 262 .bp
 263 .ti 0
 264 Supporter's Addresses
 265
 266 Ronny Boesger
 267 Lahnsteiner Strasse 7
 268 07629 Hermsdorf
 269 eMail: rb@isppro.de
 270
 271 Thorsten Dahm
 272 Josefstrasse 21
 273 66265 Heusweiler
 274 Germany
 275 EMail: t.dahm@resolution.de
 276
 277 Joerg Dorchain
 278 Harspergerflur 23
 279 66740 Saarlouis
 280 Germany
 281 EMail: joerg@dorchain.net
 282
 283 Sascha Lenz
 284 s-lz.net
 285 Zum Oberbaeumle 49
 286 97318 Kitzingen
 287 Germany
 288 E-Mail: sascha.lenz@s-lz.net
 289
 290 Jens Link
 291 Freelance Consultant
 292 Foelderichstr. 40
 293 13595 Berlin
 294 Germany
 295 EMail: jl@jenslink.net
 296
 297 Jan Walzer
 298 Kopernikusstrasse 2
 299 68519 Viernheim
 300 Germany
 301 EMail: jan.w@lzer.net
 302
 303 Sebastian Wiesinger
 304 Germany
 305 EMail: sebastian@karotte.org
 306
 307 .bp
 308 .ti 0
 309 Appendix A. Change History
 310
 311 00 - inital version
 312    - exact copy of draft-denog-v6ops-addresspartnaming-04
 313
 314 01 - propose hextet as only option, try to get this version
 315      accepted as WG item