On 24 jul 2008, at 7:27, Pekka Savola wrote:
What we need is for IPv6-only systems to successfully send and
receive IPv6 packets with mapped addresses as the source or
destination. And we haven't seen any type of system do this so far.
I'm not sure that "we" (if it implies the IETF and network community
in general) need to be able to send and receive v6 packets with
mapped addresses as the source or destination.
The premise being that we'd use the v4mapped prefix for NAT64.
Why is using the mapped addresses on the wire such a holy grail of
v6-only operation?
See my list of advantages the other day.
The most compelling is that applications that think they're using IPv4
will work. With existing NAT-PT or the NAT64 draft as it is now this
isn't the case.
I.e., when I was at the LACNIC meeting IPv4 was turned off, but unlike
at the last IETF meeting, there was a NAT-PT translator present. So I
could browse the web, connect to Jabber, send/receive email etc even
though the servers didn't have IPv6 addresses.
However, a SIP client, Skype and BitTorrent didn't work: they
explicitly use IPv4 addresses, which weren't reachable. Obviously
those clients can be upgraded, but it would be extremely useful if
existing IPv4 applications could work through a NAT64 translator.
On the other hand, this can also be accomplished with an arbitrary
prefix if the host knows the prefix and intercepts API calls that
would normally generate IPv4 packets but turn those into IPv6 packets
towards the translator if there is no IPv4 connectivity.
As a destination address, it might result in IPv6 DFZ being polluted
with the corresponding v4 routes except if you only use it in very
restricted environments (e.g. default route only).
Yes, and if the sky fell we'd all be covered in blue.
As far as I know, this hasn't happened with the 6to4 prefix so I see
no reason to reject using a well known prefix to avoid this risk.
As a source address, if the node(s) on link are also provided with
real IPv6 addresses, this would be indistinguishable from source
address spoofing.
Only translators would transmit packets with v4mapped source
addresses, so this isn't much of an issue.
I'd like folks to just forget about the mapped addresses on the wire
and find other kind of solutions for this problem.
Please provide better reasons.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
