All,
I just gave draft-itojun-ipv6-transition-abuse-01.txt a quick
read. It notes some legitimate problems with some of the transition
strategies. At least some of these problems can be addressed by simply
using good implementation techniques.
For example the problem noted in 1.1 can be addressed by simply
making sure that known bad addresses aren't used as the destination address
of an encapsulating IPv4 header. Itojun says that this isn't sufficient
but I am not sure that it isn't. It is certainly true that someone can
send you a datagram sourced from the a subnet broadcast IPv4 compatible
IPv6 address and trick a server into responding to that address. Un-
fortunately, they don't need to be that creative since they could just send
a straight IPv4 datagram using the subnet broadcast address as the source
and get the same result.
With regard to the use of mapped addresses. I think it would be
a HUGE mistake to attempt to disallow the use of mapped addresses as a
way to allow a single AF_INET6 both IPv6 and IPv4 transport traffic. One
of the major selling points that we have tried to make to ISVs is that they
can make minimal changes to there existing code base and have it be able to
service both IPv4 and IPv6. If we require seperate sockets for AF_INET
and AF_INET6 that makes ISVs jobs much more complicated.
If application level access control software like tcp wrappers
needs to be updated to understand IPv4 mapped IPv6 addresses then so be it.
They will need to be updated for IPv6 anyway and I don't see how adding
support for mapped address makes that job substantially more complicated.
Further, selecting a different address format to use with SIIT
won't obviate the need to update this filtering software. It will just make
it necessary for the software to understand the translatable format along
with the mapped and compatible formats.
It seems like SIIT should have had its own translatable address
format but I don't see it as a showstopper problem that it doesn't. Or
at least I don't see any showstopper problems in draft-itojun-ipv6-transition-
abuse-01.txt.
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
