Subject: Re: BIND 9.1.1 AND IPv4-MAPPED IPv6 addresses

From: Praveen Kumar Amritaluru <[email-masked]>
Date: Wed, 9 May 2001 22:12:51 +0530 (IST)

Hi,

	In my opinion too, mapped  addresses  should never be present in
	db       files.       The       resolver        calls       like
	getipnodebyname()/getaddrinfo()  or other calls will dynamically
	generate IPv4-mapped-IPv6 addresses.

	This has been made amply clear in RFC2553  although  implicitly.
	It   says   that   getipnodebyname()   calls   should   generate
	IPv4-mapped-IPv6  addresses  on fly  when it  cannot  find  AAAA
	records.  The call will query for A records and generate  mapped
	addresses  from these  records  and  return  the  results.  This
	inturn implies that no mapped  addresses should be present in db
	files.

	But  what  seems  to  be   ambiguous   is   IPv4-compatible-IPv6
	addresses.  There  is  no   reference   about  this   except  in
	getipnodebyaddr()  in RFC2553  which says that  initial  12 bits
	needs to be stripped and then query is made for the IPv4 address
	in in-addr.arpa domain.

	This  seems to  suggest  that we need to have a PTR  record  for
	IPv4-compatible-IPv6  addresses in in-addr.arpa domain as is the
	case with A records (IPv4 addresses) and not IP6.INT domain.

	But how about  forward  resolution,  should  AAAA  records  or A
	records need to be generated for IPv4-compatible-IPv6 addresses.
	There is a reference in "Unix  Network  Programming  Volume-1 by
	Stevens" that says  IPv4-compatible-IPv6  addresses  should have
	AAAA  records  which was  probably  written  before  RFC2553 was
	drafted.  But there  seems to be little  inconsistency  b/w this
	reference  in UNP-1 by  Stevens  and  RFC2553  which  states for
	reverse resolution it has to take it from in-addr.arpa domain.

	Or does it mean that  forward  resolution  uses AAAA records for
	compatible  addresses  and  in-addr.arpa  domain  (IPv4  address
	reverse domain) for address -> nodename resolution.

	Actually there is no flag similar to AI_V4MAPPED  for generating
	IPv4-compatbile-IPv6 address??  Is this a required one?

	Any ideas regarding IPv4-compatbile-IPv6 addresses.

Cheers,

Praveen

> 
> On Wed, May 09, 2001 at 01:04:31PM +0200, Sogor Laszlo wrote:
> > In the root.hint file of IPv6 DNS server there is an IPv4-mapped address
> > (::ffff:0:0/96):
> > 
> > .		3600000  IN  NS		ns.root
> > ns.root		3600000	     AAAA	::ffff:192.168.1.2
> 
> In my opinion mapped addresses should never ever be used in the DNS
> or on the wire. Only exception for using it on the wire is SIIT,
> with NAT-PT you should choose some other prefix if possible. You
> might have a look at RFC 2766, and look for where it says PREFIX.
> 
> > So BIND don't handle IPv4-mapped IPv6 addresses, but mapped addresses must
> > be used because of the NAT-PT. :(( 
> 
> No, or are mapped addresses hard coded in the implementation?
> 
> Stig
> 
> 

-- 
==============================================================================
Praveen Kumar Amritaluru                 Phone (Off) : (91)(80)2251554 x 1306
HP India Software Operations             Telnet      : 847-1306
Bangalore 560 052
India.
==============================================================================

--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Fri, 11 May 2001 10:19:28 +0200 (CEST)

> 	needs to be stripped and then query is made for the IPv4 address

IPv4-compatible addresses are very very very different than IPv4-mapped
addresses. Talking about both in the same email is a source of confusion :-(

IPv4-compatible addresses, just like the 6to4 addresses, are real
IPv6 addresses i.e. they always appear in IPv6 packet headers.
Neither one of them can be crafted by getaddrinfo etc from knowing the
IPv4 address of the peer, because the peer might not have configured that
IPv6 address on an interface.
[To contrast: The IPv4-mapped are just an *encoding* of an IPv4 address in an 
sockaddr_in6 structure thus it should be semantically identical to the 
underlying IPv4 address]

So IPv4-compatible addresses (6to4 addresses, "native" IPv6 address) must
be configured on the nodes and must be retrieved from something like the DNS. 

> 	case with A records (IPv4 addresses) and not IP6.INT domain.

I'm aware of that optimization but it isn't clear to me that it
is needed or desired.

> 	reverse domain) for address -> nodename resolution.

Forward uses AAAA (or A6).

> 	IPv4-compatbile-IPv6 address??  Is this a required one?

There wouldn't be a need.
The AI_V4MAPPED flag is there so that the application can specify whether
it wants to see IPv4 addresses as AF_INET addresses or as AF_INET6 addresses
containing an IPv4-mapped address.

> 	Any ideas regarding IPv4-compatbile-IPv6 addresses.

Perhaps we should deprecate them?
They are only useful for automatic tunneling and 6to4 tunneling is
essentially a superset of automatic tunneling.

  Erik

---

From: Jim Bound <[email-masked]>
Date: Fri, 11 May 2001 08:50:46 -0400 (EDT)

I would support deprecating IPv4-compatible addresses and compaq asked for
this 2 years ago :-----)  we were told no.  but we did not have 6to4
either.

/jim

---

From: Praveen Kumar Amritaluru <[email-masked]>
Date: Mon, 14 May 2001 21:52:33 +0530 (IST)

Hi,

<snip>---

> sockaddr_in6 structure thus it should be semantically identical to the 

	Thanks for the clarification.

> be configured on the nodes and must be retrieved from something like the DNS. 

	Since IPv4-compatible  addresses are "native" IPv6 addresses and
	must be  configured  in DNS, by default  the PTR  records for V6
	addresses will be placed in IP6.INT domain (which was the domain
	at that time before IP6.ARPA).  There is no reference in RFC1886
	that says PTR records for "IPv4-compatible  addresses" should be
	placed in in-addr.arpa domain.

	Since IP6.INT domain is the domain for reverse resolution as per
	the RFC1886, the PTR records will be placed in IP6.INT domain by
	default if he has not seen RFC2553 which is absurd to assume so.
	This  will  lead  to an  inconsistency  in the way  records  are
	placed.  So the resolver libraries used by many applications may
	be  searching  for  PTR  records  in  IP6.INT   domain   whereas
	getipnodebyYY() and getnameinfo() will be searching for the same
	records in in-addr.arpa domain.

> I'm aware of that optimization but it isn't clear to me that it

	I dont see any  optimization in this especially with the complex
	A6 records and  indirection  stuff to be handled by  nameservers
	and resolvers.

	Even  so, I dont  feel  there  is any  appreciable  optimization
	gained  by  just  placing  IPv4-compatible  addresses  alone  in
	in-addr.arpa domain.

> essentially a superset of automatic tunneling.

	Not sure  about  deprecating.  If not  being  deprecated  then I
	think the next  revision of  RFC2553-bis  needs  changes in this
	respect.

	Any comments?

Praveen

---

From: Praveen Kumar Amritaluru <[email-masked]>
Date: Tue, 15 May 2001 22:57:38 +0530 (IST)

Hi Erik,

<snip>--

> I'm aware of that optimization but it isn't clear to me that it

Please find a section (page 25) of RFC2553, Mar 1999 enclosed below:

   One possible source of confusion is the handling of IPv4-mapped IPv6
   addresses and IPv4-compatible IPv6 addresses, but the following logic
   should apply.

      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.

The question is:

	If  IPv4  compatible  address  is  a  proper  IPv6  address  and
	searching of IPv4 compatible  address in in-addr.arpa  domain is
	just for  optimization,  then why not just  search the record in
	in-addr.arpa  domain and return hostent structure filled with v6
	address and not v4 address.

	Setting af to AF_INET in returning  hostent structure means that
	we are treating  this address as IPv4  address.  But that is not
	true.  IPv4  compatible  address  is a IPv6  address  and so the
	resultant  hostent  structure  should  contain  IPv4  compatible
	address in network format in h_addr_list array and family should
	be set to AF_INET6 only.

Or does af being  mentioned  does not refer to family  field in  hostent
structure being returned to application.

I feel that phrase is not correct w.r.t IPv4-compatible address.

	Anybody has any comments in this regard?

-Praveen