Subject: Re: New "IP Version 6 Addressing Architecture" draft

From: Tim Hartrick <[email-masked]>
Date: Fri, 21 Jul 2000 14:07:28 -0700 (PDT)

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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sat, 22 Jul 2000 07:57:37 +0900

>a straight IPv4 datagram using the subnet broadcast address as the source

	the point i would like to make was that:
	- it is much easier to inject malicious packet from remote,
	  with bypassing normal access control imposed by normal routers
	  inbetween
	- it is much harder to track the source down, as malicious party can use
	  many relays (6to4 relays, auto-tunnel routers, whatever) to
	  anonymize his traffic.  this is just like smtp case: tracking the
	  source of spam is very hard due to smtp relays.
	sorry if it was unclear.

>support for mapped address makes that job substantially more complicated.

	there's no way for the current API to recognize IPv4 traffic on top
	of AF_INET6 socket (appears as IPv4 mapped address), and native
	IPv6 traffic with IPv4 mapped address in the header).  at least
	we need to provide the functionality.

itojun