Subject: Re: IPv6 Address validation

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 24 Jun 2003 02:52:40 +0900

>>>>> On Thu, 24 Apr 2003 08:41:53 +1000, 
>>>>> [email-masked] said:

> 	Is the following a legal IPv6 literal?  The RFC's are unclear
> 	about whether leading zeros are allowed or not if they would
> 	make a segment more than 4 character wide.

> 		1234:1234:1234:1234:01234::

> 	Note I would never expect inet_ntop() to produce the above.

> 	We were discussing this when reviewing our inet_pton()
> 	implementation.

Apparently there has been no consensus on this.  The source of the
lack of consensus is an ambiguous text in RFC 3513:

   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
      hexadecimal values of the eight 16-bit pieces of the address.

Some people interpret "01234" as a 16-bit piece, and others do not.
If we can only refer to this text, I don't think we can go further.

Meanwhile, a recent draft draft-main-ipaddr-text-rep-00.txt points out
that RFC 2373, the previous version of the address architecture RFC,
had an ABNF than invalidated "01234":

      IPv6address = hexpart [ ":" IPv4address ]
      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

      IPv6prefix  = hexpart "/" 1*2DIGIT

      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
      hexseq  = hex4 *( ":" hex4)
      hex4    = 1*4HEXDIG

And the draft itself defines a revised and precise version of the
ABNF, which also prohibits "01234" from being used as a "16-bit
piece."

I don't remember why the ABNF was removed in RFC 3513, but, regardless
of the reason, I believe the address architecture authors actually
intend at most four hex digits.

So, assuming we can agree on draft-main-ipaddr-text-rep-00.txt and the
draft will clarify RFC 3513, can we conclude here that inet_pton()
should reject more than four hex digits as a 16-bit piece?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Mon, 23 Jun 2003 17:02:05 -0700

Tatuya-san,

>If we can only refer to this text, I don't think we can go further.

I don't think this case was considered explicitly, but in the tradition of 
"be liberal in what one receives" as long as the string results in 16-bits 
I think it is OK for an implementation to accept it.  Another reason why I 
think this is OK is that the document also allows for less then four hex 
digits.  In my view this confirms that there isn't a strict requirement for 
a number of digits, only that the field results in 16-bits.  So "0", "01", 
"0123", and "01234" are OK, but "12345" is not.

>intend at most four hex digits.

The ABNF was removed from the document because what was specified was 
broken and at the time we couldn't find a working replacement.

>should reject more than four hex digits as a 16-bit piece?

I don't see the need as long as the result is 16-bits, but would like to 
see if there are other opinions.

Thanks,
Bob

---

From: [email-masked]
Date: Tue, 24 Jun 2003 11:06:55 +1000

> see if there are other opinions.

	My opinion would be to reject more than 4 hex digits.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 24 Jun 2003 11:28:12 +0900

>	My opinion would be to reject more than 4 hex digits.

	same here.

itojun

---

From: "Nir Arad" <[email-masked]>
Date: Tue, 24 Jun 2003 10:13:16 +0200

> > My opinion would be to reject more than 4 hex digits.

My vote, too, is to reject.

-- Nir Arad

---

From: Dean Strik <[email-masked]>
Date: Tue, 24 Jun 2003 10:48:58 +0200

> 	My opinion would be to reject more than 4 hex digits.

RFC 2553, section 6.6:
    #define INET6_ADDRSTRLEN   46
I'm not 100% sure about the relevance of this, but it seems like a good
reason not to allow exta digits.

-- 
Dean C. Strik             Eindhoven University of Technology
[email-masked]  |  [email-masked]  |  http://www.ipnet6.org/
"This isn't right. This isn't even wrong." -- Wolfgang Pauli
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "O.L.N.Rao" <[email-masked]>
Date: Tue, 24 Jun 2003 14:46:24 +0530

Hi Bob,

> "0123", and "01234" are OK, but "12345" is not.

From your comments, 
    012345, 0012345, 00012345...etc are all acceptable !!

But, to what extent should be allowed and why ?
Instead of going towards this, prefer not to be liberal in this case at
least.  

Regards,
O.L.N.Rao

---

From: "O.L.N.Rao" <[email-masked]>
Date: Tue, 24 Jun 2003 16:16:33 +0530

-------Original Message-------
 
From: O.L.N.Rao
Date: Tuesday, June 24, 2003 15:07:19
To: [email-masked]
Cc: [email-masked]
Subject: Re: IPv6 Address validation
 
Hi Bob,

    >> 012345, 0012345, 00012345...etc are all acceptable !!

    ********* SORRY FOR TYPOGRAPHICAL ERROR **********
    I mean, 

    01234, 001234, 0001234 ...etc are all acceptable !!

Regards,
O.L.N.Rao

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Jun 2003 18:26:08 +0700

My take on this is that it simply doesn't matter - there is no
need to be specific on what is permitted, and what is not.

What needs to be specific is what must be permitted - if implementations
then want to allow extensions, that's fine.

So, what should be defined is a standard representation form, and
all parsers should be required to correctly parse that form, but
if some parser wants to handle more than that, I cannot think of
any good reason to forbid it.

So, I would not require
	:01234:
to be handled by inet_pton() and friends, but if it happens to be
easy to implement, or deemed useful, then fine.

And the same is true for 001234 0001234 or 000000000001234 - to any
normal human they all mean the same thing.

Similarly, even though no-one I know does it, and I certainly wouldn't
require it, if someone wants to allow

	2002:10.11.12.13::/48

that's just fine too (ignoring the use of a 1918 address in a 6to4
address for this purpose).

inet_ntop() and friends should only ever generate "standard form"
strings (this is what INET6_ADDRSTRLEN relates to, it is
irrelevant when considering inet_tton()) and anyone who (for
whatever bizarre reason) is writing a literal address and actually
cares about portable interpretation, should only ever write them
in standard form.   But none of that says that inet_pton() should
reject addresses that aren't in that standard form.

The only note I'd add, is that implementors should use some caution
in the additions they permit, so as to avoid accidentally treating
strings which "obviously" weren't intended to be IPv6 address literals
as if they were.

kre

---

From: [email-masked]
Date: Wed, 25 Jun 2003 11:13:55 +0900

>require it, if someone wants to allow

	i disagree with the standpoint.  if we don't standardize what
	is accepted by inet_pton(), we will have usability/portability problem.
	if we leave it to "do whatever you want" state as you said, we will
	experience painful cleanup process in the near future, just like
	transition from inet_aton to inet_pton (inet_aton accepted hex/octal/
	less-than-four component format, and inet_pton only accepts decimal
	4-component format).

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jun 2003 19:34:33 +0200

This looks like a misunderstanding of the Postel principle.

Obviously, we should specify syntax that is non-redundant,
i.e. no extra leading zeros. I think that is what the
draft-main-ipaddr-text-rep-00.txt syntax does.

Also obviously, implementors who want to follow the Postel
principle will write parsers that accept any number of leading
zeros. But that isn't something we need to define in ABNF
or in any API. It's just defensive programming.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: [email-masked]
Date: Thu, 26 Jun 2003 11:20:38 +1000

> or in any API. It's just defensive programming.

	Having dealt with bug reports due to inconsistant IPv4
	address parsing I don't want to have to deal with the same
	problems in IPv6.  I also don't want to have to deal with
	"But it works on this machine" complaints because that
	machine just happens to have a liberal parser.

	Users can deal pretty well with errors.  They have a
	lot more trouble dealing with inconsistancy.

	Mark

---

From: Robert Elz <[email-masked]>
Date: Thu, 26 Jun 2003 15:57:33 +0700

Date:        Wed, 25 Jun 2003 11:13:55 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	i disagree with the standpoint.  if we don't standardize what
  | 	is accepted by inet_pton(), we will have usability/portability problem.

We need to standardise what inet_pton() is expected to be able to
convert.   We don't have to prohibit it from accepting anything else.

Then people should be encouraged to generate only that expected form
(or those forms).  And certainly inet_ntop() should do that.   But if
I am manually typing one of those addresses, I really don't want to be
penalised for accidentally typing one too many meaningless leading zeroes.

  | 	if we leave it to "do whatever you want" state as you said, we will
  | 	experience painful cleanup process in the near future, just like
  | 	transition from inet_aton to inet_pton (inet_aton accepted hex/octal/
  | 	less-than-four component format, and inet_pton only accepts decimal
  | 	4-component format).

As I recall, what input was legal for inet_aton() (inet_addr() really, that's
where all this started) was never defined - that is, whether 10.1 was legal
or not was just discovered by accident (and that 128.1 meant something
quite different than 10.1 - or sometimes did).

I certainly agree that we need to document the format in which addresses
should be written in order to be able to be processed everywhere.   That
is "do whatever you want" isn't anyone's position here I don't think
(that would include, for example, allowing an implementation of inet_pton()
which expected a string of 32 hex digits without punctuation, and which
rejected anything else.)

But it is just silly to attempt to tell people that they're not allowed
to implement harmless extensions which make things easier to use.  In
time some of those extensions may become so widely used as to become
(effectively) standard - if we had been going to actually standardise
inet_aton() 12/13 years ago (or more), then 10.1 would almost certainly
have been included as legal.   Today we wouldn't do that, as classful
addresses are essentially dead (the 1918 addresses being probably
the last real hold-outs).

kre