[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6to4 using ::FFFF:0000:0000/96 (mail.comcast.net AAAA record weirdness)
1. The RFC on Basic Socket Interface Extensions for IPv6 (RFC 2553)
states in its section 3.7:
<< Applications may use PF_INET6 sockets to open TCP connections to IPv4
nodes, or send UDP packets to IPv4 nodes, by simply encoding the
destination's IPv4 address as an IPv4-mapped IPv6 address, and
passing that address, within a sockaddr_in6 structure, in the
connect() or sendto() call. >>
IMHO all clients have just to comply, and use their IPv4 stacks when
destinations are mapped addresses.
If XP had done it, no problem would have been identified by Kevin, and
6to4 would not have been in the loop.
2. My previous answer to Kevin and Erik was received by them, but not by
v6ops (apologies for that).
It also contained this comment, which I see as relevant:
I am very pleased that Kevin came up with this "fascinating" example
which revives the "mapped AAAA" issue.
As a matter of fact, mapped addresses as IPv6 destinations are IMHO
very useful for the future, as shows an earlier contribution on the
subject:
http://ops.ietf.org/lists/v6ops/v6ops.2007/msg01031.html
A particular application of mapped AAAA records is for IPv4-only Web
servers to be reachable by IPv6-only clients
- these servers have mapped AAAA in their DNS servers in addition to
their As (feasible manually)
- these clients are in sites where CPEs support NAT v6-v4 (a fairly
simple software evolution of a v4-v4).
Rémi
Brian E Carpenter wrote :
On 2008-01-28 09:21, Kevin Day wrote:
That isn't necessarily so. If the client is attempting to reach
a SIIT translator, such as a NAT-PT, the mapped address should
be used, and should be routed to the translator.
IMHO there is one case where a mapped destination address could reach a
SIIT.
That is if the source host is IPv6-only (not being dual stack, it is not
cocerned with the obligation of RFC-2553 sec. 3,7).
I believe we agree that this a useful case (as I believe we agree that
IPv6 to IPv4 NAT is very useful for graceful transition from IPv4 to IPv6)
So, I think it's XP not doing the right thing here... XP should be
selecting its own v4 stack instead of trying to shove packets to
::ffff:0:0/96 down 6to4... correct?
It seems to be a matter of taste which is the default.
NO, fortunately it isn't a matter of taste (see 1. above) :-).