Internet Draft                                            L. Donnerhacke
Category: Proposed Standard                                       Editor
Updates: 4291, 5952                                     Richard Hartmann
Expires: October 5, 2011                                          Editor
                                                           April 7, 2011

                       Naming IPv6 address parts
                 draft-denog-v6ops-addresspartnaming-04

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 5, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.








Donnerhacke, Hartmann    Expires October 6, 2011                [Page 1]

 
Internet Draft          Naming IPv6 address parts          April 7, 2011


Abstract

   In the daily communication between technicians, engineers and other
   people who need to deal with computer networks, it is often necessary
   to refer to particular parts of IP addresses. In the world of IPv4,
   the term "octet" is well established, however as the use of IPv6 is
   spreading, it becomes apparent that there is no such commonly
   accepted term for IPv6 addresses.

   Discussing and explaining technical matters become difficult when
   different people use different terms for the same thing. Therefore,
   this document discusses several naming proposal for those 16bit
   pieces of IPv6 addreses.

Table of Contents


. Introduction

   Verbal and written communication requires a common set of terms, eas-
   ily understood by every potential party. While deploying IPv6, when
   refering to segments of IPv6 addresses, confusion regularly arises
   due to the usage of different and sometimes conflicting nomenclature
   for the same pieces of information.

   [IPV6Addr] is the normative reference to IPv6 addressing and avoids
   to coin a special term for the subject of this document itself:
      The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
      four hexadecimal digits of the eight 16-bit pieces of the address.

   [IPv6Rep] is the normative reference to IPv6 address text representa-
   tion and introduces the term "16-bit field" or short "field".



















Donnerhacke, Hartmann    Expires October 6, 2011                [Page 2]

 
Internet Draft          Naming IPv6 address parts          April 7, 2011


. Rationale

   While we readily agree that the naming of IPv6 address parts is not
   the most pressing concern the Internet is facing today, a common
   nomenclature is important for efficient communication.

   In IPv6 deployments the delimiting colons are regularly used to
   facilitate the separation of labels discerning not only administra-
   tive boundaries but also network segments and distinct infrastructure
   components. Consequently the values between the colons are frequently
   refered to especially in communication regarding coordinative mat-
   ters.

   Time spent explaining what one is referring to is wasted and con-
   flicting names can lead to misunderstanding while the usage of a com-
   mon term helps facilitating quick understanding.

   To solve this problem, the specification of a precise and recogniz-
   able term is advised.

   A typical ambiguity occurs in [IPv6Rep] which uses the term "field"
   or "16-bit field" for the term in question. This case is interesting
   because there was a short IETF WG discussion which term should be
   used.
      If an IPv6 address field in a certificate was incorrectly verified
      by converting it to text ...

   Since parts of the internet community only accept authoritative
   advice substantiated by a published document, also known as the
   'citation needed' approach, it is helpful to have a definite source.

. Naming Considerations

   Any term that can be confused with other technical terms due to pho-
   netic similarities can lead to misconfiguration causing reachability
   and security risks to the involved parties. Even with English being
   the preferred language in the IT world today, a good name should
   describe the technical matter precisely while being easy to remember,
   spell and pronounce in as many languages as possible.












Donnerhacke, Hartmann    Expires October 6, 2011                [Page 3]

 
Internet Draft          Naming IPv6 address parts          April 7, 2011


. Naming Proposals

4.1. hextet

   "hexadectet" is directly derived from IPv4's "octet", thus techni-
   cally correct and convenient to get used to. Because it is harder to
   pronounce, the short form "hextet" is used.

   "hextet" MUST be used in all technical documents and specifications
   refering to IPv6 address parts.

4.2. quibble

   A nibble is a 4bit entity, hence 16 bits are a quad nibble. This is a
   rather bulky word, however, so "quibble" is a convenient abbrevia-
   tion. It is a unique term in networking but has an existing meaning
   in ordinary English.

   "quibble" MAY be used for informal communication.

. Security Considerations

   This memo does not directly discuss security issues, however the lack
   of a common, well established term could theoretically lead to misin-
   terpretation, possible leading to insecure configuration of computer
   systems.

. IANA Considerations

   No assignments by the IANA are required. However it is considered
   desirable that the IANA adopts the term in future documents.

. References

7.1. Normative References

   [IPV6Addr] Deering, S. and R. Hinden, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006

   [IPv6Rep] Kawamura, S. and Kawashima, M., "A Recommendation for IPv6
              Address Text Representation", RFC 5952, August 2010

   [Q.6]     ITU-T, "Advantages of international automatic working",
              Fascicle VI.1 of the Blue Book, 1988

   [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
              Requirement Levels




Donnerhacke, Hartmann    Expires October 6, 2011                [Page 4]

 
Internet Draft          Naming IPv6 address parts          April 7, 2011


7.2. Informal References

   [greg]     http://etherealmind.com/network-dictionary-chazwazza/,
              Sept 5, 2010

. Acknowledgements

   Thanks go to Greg Ferro who initiated the discussion by proposing the
   term "chazwazza".[greg]

   Many thanks to all those people which contribute to our work and
   participate in the straw poll about all the other propoals, which are
   described in former versions of this memo: Chazwazza, Chunk, Column,
   Colonade, Colonnade, Doctet, Field, Hexadectet, Hit, Orone, Part,
   Provider number, customer number, network number, Quad nibble,
   qibble, Segment, Tuple, and Word.

   The inital version of this document was created following the spirit
   of [Q.6].
































Donnerhacke, Hartmann    Expires October 6, 2011                [Page 5]

 
Internet Draft          Naming IPv6 address parts          April 7, 2011


Authors' Addresses

   Lutz Donnerhacke
   Leutragraben 1
   07743 Jena
   Germany
   Tel: 1.6.5.3.7.5.1.4.6.3.9.4.e164.arpa.
   EMail: lutz@thur.de

   Richard Hartmann
   Munich
   Germany
   Email: richih.mailinglist@gmail.com
   http://richardhartmann.de

   Michael Horn
   Po Box 540153
   10042 Berlin
   Germany
   http://nibbler.tel/

   Kay Rechthien
   Netsign GmbH
   Lindenallee 27
   14050 Berlin
   Germany
   EMail: kre@netsign.eu

   Leon Weber
   Ahornstrasse 5d
   01458 Ottendorf-Okrilla
   Germany
   EMail: leon@whitejack.org


















Donnerhacke, Hartmann    Expires October 6, 2011                [Page 6]

 
Internet Draft          Naming IPv6 address parts          April 7, 2011


Supporter's Addresses

   Ronny Boesger
   Lahnsteiner Strasse 7
   07629 Hermsdorf
   eMail: rb@isppro.de

   Thorsten Dahm
   Josefstrasse 21
   66265 Heusweiler
   Germany
   EMail: t.dahm@resolution.de

   Joerg Dorchain
   Harspergerflur 23
   66740 Saarlouis
   Germany
   EMail: joerg@dorchain.net

   Sascha Lenz
   s-lz.net
   Zum Oberbaeumle 49
   97318 Kitzingen
   Germany
   E-Mail: sascha.lenz@s-lz.net

   Jens Link
   Freelance Consultant
   Foelderichstr. 40
   13595 Berlin
   Germany
   EMail: jl@jenslink.net

   Jan Walzer
   Kopernikusstrasse 2
   68519 Viernheim
   Germany
   EMail: jan.w@lzer.net

   Sebastian Wiesinger
   Germany
   EMail: sebastian@karotte.org









Donnerhacke, Hartmann    Expires October 6, 2011                [Page 7]

 
Internet Draft          Naming IPv6 address parts          April 7, 2011


Appendix A. Change History

   00 - inital version

   01 - Jens Link moved from Author to Supporter
      - Leon Weber moved from Supporter to Author
      - numerous typographic fixes
      - added "field" from [IPv6Rep] as proposal and as reason
      - added "part" for completeness
      - dismissed "hextet / hexatet / sixlet"
      - created sub sections for each proposal
      - added update notification of RFC4291 and RFC5952
      - added a "Security considerations" section

   02 - Fixing nits
      - Propose a selection mechanism

   03 - Added Hextet
      - Removed references to DENOG
      - Select two proposals based of the straw poll and the WG

   04 - Upgraded hextet to MUST
      - Corrected formalia & typos
      - lower-cased hextet and quibble as that is consensus for octet
      - Formatting
      - Fixed nits introduced by -03

























Donnerhacke, Hartmann    Expires October 6, 2011                [Page 8]