> 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.
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.
> 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.
> 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.
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
