Hi,
<snip>---
>
> 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]
Thanks for the clarification.
>
> So IPv4-compatible addresses (6to4 addresses, "native" IPv6 address) must
> 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.
>
> > 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.
>
> I'm aware of that optimization but it isn't clear to me that it
> is needed or desired.
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.
>
>
> > 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.
>
> Forward uses AAAA (or A6).
>
> > Actually there is no flag similar to AI_V4MAPPED for generating
> > 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.
>
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
> Erik
>
>
--
==============================================================================
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 PROTECTED]
--------------------------------------------------------------------
