Brian Zill <[EMAIL PROTECTED]> writes:
> What I'm saying is that I don't see why you'd ever need to guess. It
> shouldn't matter to the user-land program how the packet got there.
> The kernel should ensure that you get a v4-mapped packet with wire
> format of IPv6 if and only if it would have let you get the same
> packet with a wire format of IPv4.
I'll try to make up a scenario where it matters, and try to draw some
conclusions.
Say I have a box with two interfaces, one IPv6 interface connected to
the dangerous internet, and an IPv4 interface connected to a local
IPv4 only trusted network.
The box is running a dual stack, and there is some server running on
it that listens on an IPv6 socket bound to the unspecified address,
which can accept both IPv6 connections and IPv4 connections. In the
latter case, getpeername returns a mapped address.
The server software uses some kind of source-address based access
control. As you have pointed out, the server has to recognize IPv4
mapped addresses and perform IPv4 access control [1] (this is not a
big issue, as the application uses only an IPv6 socket, so this is the
only place IPv4 addresses shows up).
The second is the rules... As the only IPv4 network the machine is
attached to is trusted, the user may have configured rules like "Any
IPv4 source is trusted". That's a bad assumption [2] to make, but I
think it is an easy mistake to make. (The assumption would be safe if
the stack dropped any packet that arrives on the wire with a mapped
source addresses).
Next, if the user is aware of this, he includes stricter rules, saying
that only IPv4 addresses on the local subnet are trusted. But packets
can still be faked by sending packets with mapped source addresses
from the internet; the application will believe that they originate
from the trusted local network. [3] Again, there is an easy mistake to
make: To assume that IPv4 packets can't be faked by addressing them to
an IPv6 interface.
These are three related but dfferent problems, that need to be
considered separately. Let's see what we can do:
1. For applications that use mapped addresses to deal with IPv4 peers,
this is just natural. But for an application that listens on two
sockets, one IPv4 (bound to the unspecified IPv4 address) and one
IPv6 (bound to the unspecified IPv6), it's natural to expect that
any IPv4 peer will connect to the IPv4 socket, not the IPv6 one.
In this case, one would want to configure the IPv6 socket to never
ever pass on a packet with a mapped source address, no matter if
the mapped address appeared on the wire or was generated
internally. (I seem to recall that there is some option to do that,
on a by socket basis). Otherwise, the application has to reject
mapped addresses. In anycase, this doesn't have much to with mapped
addresses on the wire.
2. I think there are only two approaches: Either forbid mapped
addresses on the wire, or teach users and developers that they must
never make the assumtion above. I.e. teach them that it is possible
to recieve packets that, from access control point of view *are*
IPv4 packets, on an IPv6 only interface.
3. Here, the answer is probably some kind of ingress filtering. The
stack should know which addresses belongs to the trusted network,
and drop packets with addresses belonging to that network, unless
they arrive the IPv4 interface attached directly to that network. I
believe that this is particularly important for tcp, because there
it is extremely inconvenient for the application to check the
incoming interface for each individual packet. The
filtering should be applied equally to IPv4 packets and IPv6
packets with mapped addresses.
The goal of the filtering (like for ingress filtering in general, I
think), is to make sure that applications can look at source
addresses and make valid assumptions about where a packet arrived
from.
The other alternative is to listen on more sockets, one for each
interface, but that is messier to setup, in particular if you have
several addresses on each interface. (Perhaps attaching a link-id in
the scope-id field when binding the sockets, as discussed in some
other thread, may come in handy).
/Niels
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
