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