Subject: (IPng 6588) Base API : IPv4 Compatible Addresses :: and ::1

From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group <[email-masked]>
Date: Tue, 06 Oct 1998 10:20:45 -0400

Jean-Luc found this bug and it is also probably a bug in the bind code
8.1.2. which needs to be fixed.  They (:: and ::1) should not be used as
IPv4-compatible addresses in section 6.2 getipnodebyaddr().

Here is the existing text:

--------------------------------------------
1.  If af is AF_INET6, and if len equals 16, and if the IPv6 address
    is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address,
    then skip over the first 12 bytes of the IPv6 address, set af to
    AF_INET, and set len to 4.

2.  If af is AF_INET, lookup the name for the given IPv4 address
    (e.g., query for a PTR record in the in-addr.arpa domain).

3.  If af is AF_INET6, lookup the name for the given IPv6 address
    (e.g., query for a PTR record in the ip6.int domain).

4.  If the function is returning success, then the single address that
    is returned in the hostent structure is a copy of the first argument
   to the function with with the same address family that was passed as
   an argument to this function.

All four steps listed are performed, in order.
--------------------------------------------

Here is the proposed text to replace the last sentence above and fix the
IN6_IS_ADDR_V4COMPAT macro:

---------------------------------------------
All four steps listed are performed, in order.  Also note that the IPv6
hex addresses "::" and "::1" MUST NOT be treated as an IPv4-compatible
address to generate a query for a Host Name, and HOST_NOT_FOUND MUST be
returned and a query of the Host Name not performed.

Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
false for "::" and "::1".
---------------------------------------------

Please comment.  I did this as the simplest fix.  

thanks
/jim

--------------------------------------------------------------------
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: Jun-ichiro itojun Itoh <[email-masked]>
Date: Tue, 06 Oct 1998 23:36:00 +0900

>IPv4-compatible addresses in section 6.2 getipnodebyaddr().
(snip)
>hex addresses "::" and "::1" MUST NOT be treated as an IPv4-compatible   <-
>address to generate a query for a Host Name, and HOST_NOT_FOUND MUST be  <-
>returned and a query of the Host Name not performed.			  <-
>

	I believe the first part of the above be listed as the first item
	in the ordered steps listed, as:
	0. If af is AF_INET6, and if len equals 16, and the IPv6 address
	   equals to :: or ::1, go to step 3.

	Do the marked lines mean that we should not query
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
	(old style) for PTR record?  In IPv4 we usually have the following
	two RRs in the database, in practice.
1.0.0.127.in-addr.arpa.	IN PTR	localhost.
localhost.		IN A	127.0.0.1
	Do you suggest that it will be different in IPv6?
	(sorry if I missed any of DNS-related drafts)

[email-masked]
jun-ichiro itoh

---

From: [email-masked]
Date: Tue, 06 Oct 1998 10:56:38 -0400

itojun,

	>   equals to :: or ::1, go to step 3.

I am suggesting that not even happen.  

>	(sorry if I missed any of DNS-related drafts)

I am suggesting that if it does exist it is irrelevant to an application
looking up a name for :: which is completely bogus and ::1 nonsensical.
I believe ::1 for DNS should be deprecated yes but I don't have the
energy to fight that battle, but it is not necessary in this api case
and why it can be in this spec.  

More importantly they are not valid IPv4-Compatible addresses in the
spirit of what those addresses are in RFC 2373.  An IPv4 compatible
address is used to convey a real IPv4 address and ::1 is our loopback
address for IPv6.

/jim