home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1924.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  10.2 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                             R. Elz
  8. Request for Comments: 1924                       University of Melbourne
  9. Category: Informational                                     1 April 1996
  10.  
  11.  
  12.                A Compact Representation of IPv6 Addresses
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. 1. Abstract
  21.  
  22.    IPv6 addresses, being 128 bits long, need 32 characters to write in
  23.    the general case, if standard hex representation, is used, plus more
  24.    for any punctuation inserted (typically about another 7 characters,
  25.    or 39 characters total).  This document specifies a more compact
  26.    representation of IPv6 addresses, which permits encoding in a mere 20
  27.    bytes.
  28.  
  29. 2. Introduction
  30.  
  31.    It is always necessary to be able to write in characters the form of
  32.    an address, though in actual use it is always carried in binary.  For
  33.    IP version 4 (IP Classic) the well known dotted quad format is used.
  34.    That is, 10.1.0.23 is one such address.  Each decimal integer
  35.    represents a one octet of the 4 octet address, and consequently has a
  36.    value between 0 and 255 (inclusive).  The written length of the
  37.    address varies between 7 and 15 bytes.
  38.  
  39.    For IPv6 however, addresses are 16 octets long [IPv6], if the old
  40.    standard form were to be used, addresses would be anywhere between 31
  41.    and 63 bytes, which is, of course, untenable.
  42.  
  43.    Because of that, IPv6 had chosen to represent addresses using hex
  44.    digits, and use only half as many punctuation characters, which will
  45.    mean addresses of between 15 and 39 bytes, which is still quite long.
  46.    Further, in an attempt to save more bytes, a special format was
  47.    invented, in which a single run of zero octets can be dropped, the
  48.    two adjacent punctuation characters indicate this has happened, the
  49.    number of missing zeroes can be deduced from the fixed size of the
  50.    address.
  51.  
  52.    In most cases, using genuine IPv6 addresses, one may expect the
  53.    address as written to tend toward the upper limit of 39 octets, as
  54.    long strings of zeroes are likely to be rare, and most of the other
  55.  
  56.  
  57.  
  58. Elz                          Informational                      [Page 1]
  59.  
  60. RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996
  61.  
  62.  
  63.    groups of 4 hex digits are likely to be longer than a single non-zero
  64.    digit (just as MAC addresses typically have digits spread throughout
  65.    their length).
  66.  
  67.    This document specifies a new encoding, which can always represent
  68.    any IPv6 address in 20 octets.  While longer than the shortest
  69.    possible representation of an IPv6 address, this is barely longer
  70.    than half the longest representation, and will typically be shorter
  71.    than the representation of most IPv6 addresses.
  72.  
  73. 3. Current formats
  74.  
  75.    [AddrSpec] specifies that the preferred text representation of IPv6
  76.    addresses is in one of three conventional forms.
  77.  
  78.    The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
  79.    hexadecimal values of the eight 16-bit pieces of the address.
  80.  
  81.    Examples:
  82.  
  83.         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210  (39 characters)
  84.  
  85.         1080:0:0:0:8:800:200C:417A  (25 characters)
  86.  
  87.    The second, or zero suppressed, form allows "::" to indicate multiple
  88.    groups of suppressed zeroes, hence:
  89.  
  90.         1080:0:0:0:8:800:200C:417A
  91.  
  92.    may be represented as
  93.  
  94.         1080::8:800:200C:417A
  95.  
  96.    a saving of just 5 characters from this typical address form, and
  97.    still leaving 21 characters.
  98.  
  99.    In other cases the saving is more dramatic, in the extreme case, the
  100.    address:
  101.  
  102.         0:0:0:0:0:0:0:0
  103.  
  104.    that is, the unspecified address, can be written as
  105.  
  106.         ::
  107.  
  108.    This is just 2 characters, which is a considerable saving.  However
  109.    such cases will rarely be encountered.
  110.  
  111.  
  112.  
  113.  
  114. Elz                          Informational                      [Page 2]
  115.  
  116. RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996
  117.  
  118.  
  119.    The third possible form mixes the new IPv6 form with the old IPv4
  120.    form, and is intended mostly for transition, when IPv4 addresses are
  121.    embedded into IPv6 addresses.  These can be considerably longer than
  122.    the longest normal IPv6 representation, and will eventually be phased
  123.    out.  Consequently they will not be considered further here.
  124.  
  125. 4. The New Encoding Format
  126.  
  127.    The new standard way of writing IPv6 addresses is to treat them as a
  128.    128 bit integer, encode that in base 85 notation, then encode that
  129.    using 85 ASCII characters.
  130.  
  131. 4.1. Why 85?
  132.  
  133.    2^128 is 340282366920938463463374607431768211456.  85^20 is
  134.    387595310845143558731231784820556640625, and thus in 20 digits of
  135.    base 85 representation all possible 2^128 IPv6 addresses can clearly
  136.    be encoded.
  137.  
  138.    84^20 is 305904398238499908683087849324518834176, clearly not
  139.    sufficient, 21 characters would be needed to encode using base 84,
  140.    this wastage of notational space cannot be tolerated.
  141.  
  142.    On the other hand, 94^19 is just
  143.    30862366077815087592879016454695419904, also insufficient to encode
  144.    all 2^128 different IPv6 addresses, so 20 characters would be needed
  145.    even with base 94 encoding.  As there are just 94 ASCII characters
  146.    (excluding control characters, space, and del) base 94 is the largest
  147.    reasonable value that can be used.  Even if space were allowed, base
  148.    95 would still require 20 characters.
  149.  
  150.    Thus, any value between 85 and 94 inclusive could reasonably be
  151.    chosen.  Selecting 85 allows the use of the smallest possible subset
  152.    of the ASCII characters, enabling more characters to be retained for
  153.    other uses, eg, to delimit the address.
  154.  
  155. 4.2. The Character Set
  156.  
  157.    The character set to encode the 85 base85 digits, is defined to be,
  158.    in ascending order:
  159.  
  160.              '0'..'9', 'A'..'Z', 'a'..'z', '!', '#', '$', '%', '&', '(',
  161.              ')', '*', '+', '-', ';', '<', '=', '>', '?', '@', '^', '_',
  162.              '`', '{', '|', '}', and '~'.
  163.  
  164.    This set has been chosen with considerable care.  From the 94
  165.    printable ASCII characters, the following nine were omitted:
  166.  
  167.  
  168.  
  169.  
  170. Elz                          Informational                      [Page 3]
  171.  
  172. RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996
  173.  
  174.  
  175.       '"' and "'", which allow the representation of IPv6 addresses to
  176.       be quoted in other environments where some of the characters in
  177.       the chosen character set may, unquoted, have other meanings.
  178.  
  179.       ',' to allow lists of IPv6 addresses to conveniently be written,
  180.       and '.' to allow an IPv6 address to end a sentence without
  181.       requiring it to be quoted.
  182.  
  183.       '/' so IPv6 addresses can be written in standard CIDR
  184.       address/length notation, and ':' because that causes problems when
  185.       used in mail headers and URLs.
  186.  
  187.       '[' and ']', so those can be used to delimit IPv6 addresses when
  188.       represented as text strings, as they often are for IPv4,
  189.  
  190.       And last, '\', because it is often difficult to represent in a way
  191.       where it does not appear to be a quote character, including in the
  192.       source of this document.
  193.  
  194. 5. Converting an IPv6 address to base 85.
  195.  
  196.    The conversion process is a simple one of division, taking the
  197.    remainders at each step, and dividing the quotient again, then
  198.    reading up the page, as is done for any other base conversion.
  199.  
  200.    For example, consider the address shown above
  201.  
  202.         1080:0:0:0:8:800:200C:417A
  203.  
  204.    In decimal, considered as a 128 bit number, that is
  205.    21932261930451111902915077091070067066.
  206.  
  207.    As we divide that successively by 85 the following remainders emerge:
  208.    51, 34, 65, 57, 58, 0, 75, 53, 37, 4, 19, 61, 31, 63, 12, 66, 46, 70,
  209.    68, 4.
  210.  
  211.    Thus in base85 the address is:
  212.  
  213.         4-68-70-46-66-12-63-31-61-19-4-37-53-75-0-58-57-65-34-51.
  214.  
  215.    Then, when encoded as specified above, this becomes:
  216.  
  217.         4)+k&C#VzJ4br>0wv%Yp
  218.  
  219.    This procedure is trivially reversed to produce the binary form of
  220.    the address from textually encoded format.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Elz                          Informational                      [Page 4]
  227.  
  228. RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996
  229.  
  230.  
  231. 6. Additional Benefit
  232.  
  233.    Apart from generally reducing the length of an IPv6 address when
  234.    encode in a textual format, this scheme also has the benefit of
  235.    returning IPv6 addresses to a fixed length representation, leading
  236.    zeroes are never omitted, thus removing the ugly and awkward variable
  237.    length representation that has previously been recommended.
  238.  
  239. 7. Implementation Issues
  240.  
  241.    Many current processors do not find 128 bit integer arithmetic, as
  242.    required for this technique, a trivial operation.  This is not
  243.    considered a serious drawback in the representation, but a flaw of
  244.    the processor designs.
  245.  
  246.    It may be expected that future processors will address this defect,
  247.    quite possibly before any significant IPv6 deployment has been
  248.    accomplished.
  249.  
  250. 8. Security Considerations
  251.  
  252.    By encoding addresses in this form, it is less likely that a casual
  253.    observer will be able to immediately detect the binary form of the
  254.    address, and thus will find it harder to make immediate use of the
  255.    address.  As IPv6 addresses are not intended to be learned by humans,
  256.    one reason for which being that they are expected to alter in
  257.    comparatively short timespan, by human perception, the somewhat
  258.    challenging nature of the addresses is seen as a feature.
  259.  
  260.    Further, the appearance of the address, as if it may be random
  261.    gibberish in a compressed file, makes it much harder to detect by a
  262.    packet sniffer programmed to look for bypassing addresses.
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Elz                          Informational                      [Page 5]
  283.  
  284. RFC 1924       A Compact Representation of IPv6 Addresses   1 April 1996
  285.  
  286.  
  287. 9. References
  288.  
  289.    [IPv6]        Internet Protocol, Version 6 (IPv6) Specification,
  290.                  S. Deering, R. Hinden, RFC 1883, January 4, 1996.
  291.  
  292.    [AddrSpec]    IP Version 6 Addressing Architecture,
  293.                  R. Hinden, S. Deering, RFC 1884, January 4, 1996.
  294.  
  295. 10. Author's Address
  296.  
  297.    Robert Elz
  298.    Computer Science
  299.    University of Melbourne
  300.    Parkville, Victoria, 3052
  301.    Australia
  302.  
  303.    EMail: kre@munnari.OZ.AU
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Elz                          Informational                      [Page 6]
  339.  
  340.