Subject: non-standard IPv4 form support in getaddrinfo()

From: Yoshinobu Inoue <[email-masked]>
Date: Mon, 07 Feb 2000 21:46:36 +0900

Hello, I have one concern in getaddrinfo() and would like to
here opinion of other people.

RFC2553 says inet_pton() don't support non-standard IPv4 addr
forms. (such as. 10.1 for 10.0.0.1)

But does it also require getaddrinfo() don't support
non-standard IPv4 addr forms?

Actually KAME getaddrinfo() uses inet_pton() so KAME doesn't
support non-standard IPv4 forms.

And recently KAME is being merged into freebsd-current, and
several people become upset as they find non-standard IPv4
forms are no longer available. They also use it in their
scripts.

To think about backword compatibility with many existing
scripts, I think abondoning it in getaddrinfo() is not
good choice.
On the other hand, I think sync'ing getaddrinfo() behaviour
between platforms will also be important.

Are other platforms actually abondoning or likely to abondon
non-standard IPv4 forms in its getaddrinfo() support?

Yoshinobu Inoue
--------------------------------------------------------------------
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: Jim Bound <[email-masked]>
Date: Mon, 07 Feb 2000 19:28:20 -0500

>non-standard IPv4 addr forms?

Its not stated.  But I don't think we should.

>support non-standard IPv4 forms.

I think all of us will do this till scope-ids show up.  Then inet_pton
don't work.  So in that sense adding a scope-id to an address is
non-standard.

>forms are no longer available. They also use it in their

Why are they doing this?  

>scripts, I think abondoning it in getaddrinfo() is not

Why how much of a market or set of users are we talking about?

>between platforms will also be important.

Thats the purpose of rfc2553 and xns specs.  But we cannot synch all
possible combinations.

>non-standard IPv4 forms in its getaddrinfo() support?

right now yes we are.

/jim

Yoshinobu Inoue

---

From: [email-masked]
Date: Tue, 08 Feb 2000 10:18:26 +0900

I'm still not sure about it, and I personally prefer using inet_pton().
	It is about classful IPv4 address notation, which should have been
	dead since introduction of CIDR.  Examples:
		10 = 10.0.0.0,
		10.16777215 = 10.255.255.255
		10.1 = 10.0.0.1
		10.1.1 = 10.1.0.1,

>Its not stated.  But I don't think we should.

	Just for comment: XNS5.2 says
	- use inet_aton() for numeric IPv4 address decoding, and inet_pton()
	  for IPv6 case.
	inet_aton() supports classful notation  so XNS 5.2 getaddrinfo
	supports classful notation for IPv4 address.

	Is it the right behavior to pick?

>don't work.  So in that sense adding a scope-id to an address is

	What do you mean by "do this"?
	Do you mean that, if your getaddrinfo sees "10" it is ambiguous to it?
	I tend to agree with you but it's not really ambiguous (we have scope
	boundary character, and scoped address is just for IPv6).

>Why how much of a market or set of users are we talking about?

	There are some people still typing
	% ftp 127.1
	% telnet 10.1
	and so forth.  I personally never use it.

itojun

---

From: Jim Bound <[email-masked]>
Date: Mon, 07 Feb 2000 20:29:49 -0500

>	dead since introduction of CIDR.  Examples:

We have to have some rules that is the way rfc2553 is and I am not clear
this should be up for discussion.  If you want that then add it to the
list.  I am against it.

>	Is it the right behavior to pick?

Not IMO.   We had consensus on this previously.

We will parse for scopes.

Yes.  

I await Jimeni's text.

Too bad they loose.  

/jim

---

From: [email-masked]
Date: Tue, 08 Feb 2000 10:37:40 +0900

>this should be up for discussion.  If you want that then add it to the

	I am against as well so I personally don't ask you to list it:-)

>Not IMO.   We had consensus on this previously.

	As long as RFC2553bis and XNS will say the same thing I'll be happy.
	(I'm NOT saying that XNS behavior should be picked, I'm saying that
	both have to pick the right behavior)

	Thanks.

itojun

---

From: Jim Bound <[email-masked]>
Date: Mon, 07 Feb 2000 21:52:01 -0500

rfc2553bis and xns will be 100% in synch....as this time xns team is
here from the beginning for rfc2553bis update working with the ipng
team.  at this point my job is really an "editor".   part of that job is
to make sure we get this done quickly but correctly.

thx
/jim

---

From: Yoshinobu Inoue <[email-masked]>
Date: Tue, 08 Feb 2000 12:13:17 +0900

> to make sure we get this done quickly but correctly.

Let me make sure the contents of the fix again, because I
might change the code just before release.

  -RFC2553bis will require inet_pton() for getaddrinfo()
   resolving numeric IPv4 addr.

  -XNS spec will be updated to require inet_pton() for getaddrinfo()
   resolving numeric IPv4 addr.
   
Are these assumptions correct?

Yoshinobu Inoue

---

From: Jim Bound <[email-masked]>
Date: Tue, 08 Feb 2000 08:40:00 -0500

Yoshinobu,

>might change the code just before release.

Be careful.  All of us have been burned now 3 times. I personally have
changed important network applications twice now.  This list takes time
to reach consensus.    

>   resolving numeric IPv4 addr.

No.  We cannot require this and should not state this at all.
getaddrinfo is a "middleware" API not a systems API like
getipnodebyname.  Hence, it does a lot more than just get one address
or name.  It returns to the programmer and entire set of values in
various datastructures depending on what is presented and the flags set.
Because we will be permitting users to key in a sin6_scope_id with an
address to ftp or telnet as examples inet_pton may or may not be used
depending on how an implementation of getaddrinfo parses the string
containing scope_id + address.  A first level string operation behind
the getaddrinfo may parse out first the scope_id then use inet_pton to
convert it to a presentable address.  Or an implementation may invent a
new parser for the string scoped-id + address.

inet_pton is a useful tool in rfc2553 which has consensus and
implementors can use it or not use it.  We do not mandate its use and
nor will XNS.
   
>Are these assumptions correct?

I think the answer is NO.

/jim

---

From: [email-masked]
Date: Tue, 08 Feb 2000 22:59:09 +0900

>new parser for the string scoped-id + address.

	Let me rephrase what shin tried to ask.  Will RFC2553bis declare
	what kind of input string getaddrinfo(3) should take?  Independent
	from the use of scopeid portion, I think there should be clear
	definition on it.

	And then, the acceptable IPv4 numeric "input string" set will
	automatically decide whether classfull notation will be allowed or not.

itojun

---

From: Jim Bound <[email-masked]>
Date: Tue, 08 Feb 2000 09:43:30 -0500

Its a pointer to a Null terminated string char *nodename.  As rfc2553
states:

------------------------
   The nodename and servname arguments are pointers to null-terminated
   strings or NULL.  One or both of these two arguments must be a non-
   NULL pointer.  In the normal client scenario, both the nodename and
   servname are specified.  In the normal server scenario, only the
   servname is specified.  A non-NULL nodename string can be either a
   node name or a numeric host address string (i.e., a dotted-decimal
   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
  be either a service name or a decimal port number.
---------------------------

What more would you like to see specified.  What would you like to see
the text say?  Then we can discuss it in concrete terms instead of
abstract terms.

>	automatically decide whether classfull notation will be allowed or not.

I think we need to discuss the above before we can answer this question.

thanks
/jim

---

From: [email-masked]
Date: Tue, 08 Feb 2000 23:54:45 +0900

>Its a pointer to a Null terminated string char *nodename.  As rfc2553
						~~~~~~~~~~~~~~~~~~~~~~
>   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  be either a service name or a decimal port number.

	I see, "dotted-decimal IPv4 address" in the above was not clear enough
	and this leaded to difference in understanding (between "allow classful
	notation" and "disallow it").
	I personally prefer the following text to be added, or the following
	text to replace the line in the paren (underlined part).

itojun

For IPv4 numeric address, getaddrinfo accepts what inet_pton() takes.
For IPv6 numeric address, getaddrinfo accepts what inet_pton() takes,
and the extended numeric IPv6 address format for scoped
addresses defined in *jinmei draft*.

(To recap for discussion purposes, inet_pton() takes the following:
    it will take dotted-quad decimals.
    If the af argument is AF_INET, the function accepts a string in the
    standard IPv4 dotted-decimal form:

	    ddd.ddd.ddd.ddd

    where ddd is a one to three digit decimal number between 0 and 255.
    Note that many implementations of the existing inet_addr() and
    inet_aton() functions accept nonstandard input: octal numbers,
    hexadecimal numbers, and fewer than four numbers.  inet_pton() does
    not accept these formats.
)

---

From: Jim Bound <[email-masked]>
Date: Tue, 08 Feb 2000 10:44:43 -0500

Itojun,

>	notation" and "disallow it").

I think its very clear and well defined.  It seems to me you want it to
do more and not that its not clear.  I wrote the first implementation of
it and it was perfectly clear to me as one implementors opinion.

>For IPv4 numeric address, getaddrinfo accepts what inet_pton() takes.

I don't think we should do this and limit how getaddrinfo processes IPv4
numeric addresses in the future.

>addresses defined in *jinmei draft*.

This is totally unacceptable to me as an implementor I do not want to
change the syntax, semantics, or behavior of inet_pton or inet_ntop
which it would have to change to support jinmei's draft. This will
require a new API parser.

We should not change inet_pton in rfc2553 at all.  Is my feeling.
The ramifications to installed base are to negative.  

)

/jim

---

From: [email-masked]
Date: Wed, 09 Feb 2000 00:52:40 +0900

>numeric addresses in the future.

	I see, is there any chance to put reference to "(standard)
	dotted-decimal IPv4 address"?  i think XNS and RFC2553 disagreed
	in some point in the past, due to the text around here.  getaddrinfo()
	description is less clear than what inet_pton() description says.

>The ramifications to installed base are to negative.  

	(maybe due to my poor english skill) I never tried to suggest change
	inet_pton() behavior in the above.  I think you are misreading the
	above.  we do not need to change inet_pton() behavior at all.

	For simple (standard) IPv6 numeric, getaddrinfo() needs to just call
	inet_pton() (or some other supporting function).
	To support jinmei draft, getaddrinfo() needs to do (1) scope-address
	splitting, (2) scope parsing and (3) call inet_pton().

itojun

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 08 Feb 2000 11:19:20 -0500

Jim

I agree with Itojun that some of the following text may help clarify
what getaddrinfo() considers a valid 'nodename'.  We should avoid all the
references to inet_*() functions, but add either a definition or a reference
to what is considered a "standard IPv4 dotted-decimal form."

-vlad

> >    not accept these formats.

+++++++++++++++++++++++++++++++
Vladislav Yasevich
Compaq Computer Corp.
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
(603) 884-1079
--------------------------------------------------------------------
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: Jim Bound <[email-masked]>
Date: Tue, 08 Feb 2000 11:27:46 -0500

Itojun,

We need to make sure XNS and rfc2553 are in synch here as I said before.
We can further define what is mean't by "standard" yes.

OK we have had this problem before talking.  Lets parse your sentence in
public as I need to make sure folks know I am not "misreading" input
from the team, as saying that implies I am not capable of comprehension

>For IPv6 numeric address, getaddrinfo accepts what inet_pton() takes,

OK the clause above states IPv6 numeric address, getaddrinfo accepts
what inet_pton takes:  To me that means when presented with a numeric
addres inet_pton can parse it.  Thats fine I agree and there is no
change to inet_pton.  I would add that address must be a standard
address if I think we should say anything about inet_pton at all in the
spec for getaddrinfo.

>addresses defined in *jinmei draft*.

Above the word "and" is a conjunction tying it to the previous context
in the sentence above.  The "and" makes it a dependent clause on the
first clause.  I take it to mean that your saying in addition to the
IPv6 numeric address inet_pton should also support parsing an "extended
IPv6 numeric address" which "is defined in jinmei's draft" 

That to me means your saying inet_pton must be able to accept:

A)  4ffe::12 (which it does today)
      and
B)   4ffe::12|323 (where | is a delimeter to define the scope_id 323
                 or however we all agree to define this via jinmei's
                 work)

If we support "B" above its a change to inet_pton and why I said what I
did.  

SO I DID NOT MISREAD YOUR TEXT.  You were just not clear and defining at
the detail level.

>	inet_pton() (or some other supporting function).

This is clear.

>	splitting, (2) scope parsing and (3) call inet_pton().

This is how I would like to see it done too but I am not sure we have
consensus on this?  I do not think rfc2553 should specify the actual
routines to do this but state an implementation will support a user
entering a conbined IPv6 address + sin6_scope_id for which getaddrinfo
will return an Ipv6 address and the scope_id in sockaddr->sin6_scope_id.
We cannot mandate getaddrinfo use inet_pton at all.  

/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 09 Feb 2000 03:14:21 +0900

>>>>> On Tue, 08 Feb 2000 11:27:46 -0500, 
>>>>> Jim Bound <[email-masked]> said:

> SO I DID NOT MISREAD YOUR TEXT.  You were just not clear and defining at

I think itojun's intention was the following:

  For 4ffe::12|323, getaddrinfo first separate the address into the
  "real" address portion (4ffe::12) and the scope_id portion(323), and
  pass the "real" address portion to inet_pton in order to translate
  the textual addres into a 128bit IPv6 binary address.

He didn't argue that inet_pton should understand the compound form
(above "B").

In any case, their (itojun and Yoshinobu) main concern is how
getaddrinfo() treats *IPv4* addresses, more specifically, if the
function should accept the "classful" format of *IPv4* addresses like

		10 = 10.0.0.0,

I think this is not (directly) relevant to our draft of *IPv6* textual
addresses.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Feb 2000 12:15:09 +0100

In your previous mail you wrote:

=> I believe these non-standard IPv4 address forms should be
garbage collected... I am in favor of a little statement or
a reference about what is the textual form of an IPv4 address
(in fact we need this too for IPv4 compatible IPv6 addresses
which are usually represented as ::<ipv4-address>. RFC 2373
uses but does not define the "standard IPv4 representation"
then perhaps it is not enough to add a reference to it?

Regards

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Wed, 16 Feb 2000 09:35:59 -0500

>then perhaps it is not enough to add a reference to it?

I agreed to better word smithing to the textual form.  But if 2373 ain't
right go fix rfc2373 that is good standards practice, lets not make
every reference to rfc2373 have to explain it.  But I think 2373 is
fine:

By definition: ::<ipv4-address>  is very clear.

  1.  :: is a separator
  2.  if all zeros proceed it one has an IPv4 compatible address
  3.  <ipv4-address> is what we all know IPv4 addresses to be 
      which is a 4 byte dotted decimal notation where each '.'
      represents one byte.  Ergo using # to represent a digit
      for this discussion #.#.#.#  means 10.1.1.3 is valid
      but:
        10.1  is incomplete and invalid
        10/14 is invalid 
        etc...

I do not see the need to specify this in rfc2553bis nor should we.

/jim

---

From: [email-masked]
Date: Thu, 17 Feb 2000 00:30:44 +1100

> then perhaps it is not enough to add a reference to it?

	I think this is perfectly clear.  The description below does
	not allow for the other forms.

      RFC2373, Section 2.2.

      3. An alternative form that is sometimes more convenient when
      dealing with a mixed environment of IPv4 and IPv6 nodes is
      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values
      of the six high-order 16-bit pieces of the address, and the
      'd's are the decimal values of the four low-order 8-bit pieces
      of the address (standard IPv4 representation).

--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Feb 2000 10:58:26 +1100

Date:        Thu, 17 Feb 2000 00:30:44 +1100
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	I think this is perfectly clear.  The description below does
  | 	not allow for the other forms.
  | 
  |       RFC2373, Section 2.2.
  | 
  |       3. An alternative form that is sometimes more convenient when
  |       dealing with a mixed environment of IPv4 and IPv6 nodes is
  |       x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values
  |       of the six high-order 16-bit pieces of the address, and the
  |       'd's are the decimal values of the four low-order 8-bit pieces
  |       of the address (standard IPv4 representation).

If you're reading that out of the
	x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values
	of the six high-order 16-bit pieces of the address, and the
	'd's are the decimal values of the four low-order 8-bit pieces
	of the address
wording, then one would also have to conclude that ::1.2.3.4 is invalid,
as that doesn't have the x's for the high order 16 bit pieces.   On the
other hand if, as I think we all do, allow the x's to be omitted (::)
(as is specified elsewhere, but not here explicitly) then I think you could
also read that to allow "unnecessary" d's to be deleted as well.

On the other hand, if it is "standard IPv4 representation" that is supposed
to require all 4 decimal digits, then I think that fails, as being an
undefined term (which I think is where this discussion originated).

By convention - one could almost call it standard - 10.1 has been acceptable
just about anywhere 10.0.0.1 was intended (and contrary to what has
sometimes been claimed, there's nothing classful or classless about this,
it is just a notational convention - perhaps more likely to be useful in
a classful environment, but that's all ... 10.1.5 works too after all (meaning
10.1.0.5)).

But please don't read this message as implying support for continuing that
abbreviated form of IPv4 addressing in IPv6 addresses - I don't think IPv6
literal addresses should be used almost anywhere at all, and I certainly
don't think we need to make notational shorthands to make them easier to
use (I'd be happy if we required all 32 hex digits, and the 7 interspersed
colons, and allowed no shortened forms at all...)

But the spec does need to be clear on what is acceptable, and what is not,
and I don't think any good is done out of taking slightly imprecise
language, and just claimimg it is precise enough - just fix it when the
doc is revised.

kre

---

From: [email-masked]
Date: Thu, 17 Feb 2000 11:38:31 +1100

> also read that to allow "unnecessary" d's to be deleted as well.

	The combination with compression is specified just below the quoted
	text.  The compression syntax is specified in the preceeding
	paragraph to the one I quoted.

	I can't see how anyone can say that ::10.1 is legal if they read
	RFC2373, Section 2.2.  I know I had to ask myself if the other
	forms were legal when implementing inet_pton() but the answer was
	clearly there.

	However it can't hurt to say the other IPv4 literal address forms
	(octal, hexadecimal, less than 4 elements) are excluded.

> undefined term (which I think is where this discussion originated).

	The discussion started from the assertion that the addresses were
	::<standard IPv4 representation>, ::<IPv4 dotted decimal quad>
	would be a better description.

> a classful environment, but that's all ... 10.1.5 works too after all (meanin

	Agreed.
> language, and just claimimg it is precise enough - just fix it when the

	Mark