Date: Sat, 9 Dec 95 22:35:48 +0100
Message-Id: <9512092135.AA15824@mercutio.admin.kth.se>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Olle Jarnefors <ojarnef@admin.kth.se>
To: drums@cs.utk.edu
Cc: Olle Jarnefors <ojarnef@admin.kth.se>
In-Reply-To: <199512080810.DAA01542@CS.UTK.EDU> (Fri, 08 Dec 1995 03:10:37 EST;
 From: Roger Fajman <RAF@CU.NIH.GOV>)
Subject: Re: IPv6 address representation

Roger Fajman <RAF@CU.NIH.GOV> wrote in message
<199512080810.DAA01542@CS.UTK.EDU>:

> > Just checking, but is there any agreement on how IPv6 address literals
> > are to be represented in email addresses?

> No.  The colons are considered to be a serious problem.
> Any suggestions?

There should be no problem, if only RFC 822 was followed. It says:

:       A domain-ref must be THE official name of a registry, network,
:       or  host. [...] At times, it is necessary to bypass standard  mechan-
:       isms  for  resolving  such  references,  using  more primitive
:       information, such as a network host address  rather  than  its
:       associated host name.
: 
:       To permit such references, this standard provides the  domain-
:       literal  construct. [...]
:
:       Domain-literals which refer to domains within the ARPA  Inter-
:       net  specify  32-bit  Internet addresses, in four 8-bit fields
:       noted in decimal, [...] For example:
:
:                                [10.0.3.19]

:    domain-literal =  "[" *(dtext / quoted-pair) "]"

:    dtext       =  <any CHAR excluding "[",     ; => may be folded
:                    "]", "\" & CR, & including
:                    linear-white-space>

This RFC 822 syntax is general enough to allow almost any ASCII
character sequence as the content of a <domain-literal>. A naive
use of the text representation of 128-bit IPv6 addresses
specified in draft-ietf-ipngwg-addr-arch-03.txt would give such
addresses as the following, and this wouldn't break the letter
or intent of RFC 822:

   user@[0:0:0:0:0:FFFF:8190:3426]

   user@[::FFFF:8190:3426]

   user@[::FFFF:129.144.52.38]

(These three would be representation-equivalent addresses.)

Is the real problem that currently deployed software doesn't
expect to find any other special character than "." within a
[...] construct in the <domain> part of an <addr-spec>? In that
case, map ":" to "..":

   user@[....FFFF..129.144.52.38]

Or is it that only "." and decimal digits are expected? The
hexadecimal values will then have to be converted to decimal
values:

   user@[....65535..129.144.52.38]

Or is it that precisely four groups of no more than three
decimal digits, delimited by ".", are expected? In that case the
RFC 822 requirement to use the [...] construct when bypassing
"the official [domain] name" by "using more primitive
information" can't be met. It will be necessary, I suppose, to
invent a toplevel pseudo-domain .ipv6:

   user@h.h.ffff.h.i129.i144.i52.i38.ipv6

(":" is mapped to ".h.", "::" to ".h.h." or "h.h." when it's the
first component of the IPv6 address, "." is mapped to ".", "i"
is prepended to groups starting with a decimal digit.)

/Olle

--
Olle Jarnefors, Royal Institute of Technology, Stockholm <ojarnef@admin.kth.se>