Subject: RE: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Mon, 23 Sep 2002 08:29:57 -0700

> Please read section 1.3 in RFC 2765.

Done that, again...

> It states the reason for using the IPv4-mapped addresses and not
something
> else. Using a different prefix for SIIT would require that
applications be
> made
> SIIT aware; as the specification is written the applications merely
have
> to be
> dual-stack capable (i.e. aware that IPv4-mapped addresses refer to
IPv4
> peers)
> for SIIT to work.

The more I read SIIT, the more I find its usage limited. SIIT assumes
that one can allocate an IPv4 address to each participating IPv6 node,
and that the applications behave exactly as if the system was dual
stack, i.e. manipulate IPv4 addresses when dealing with IPv4 hosts. The
only differences with a complete dual stack system appear to be:

1) That we don't need an IPv6 routing infrastructure in the domain to
which the hosts are connected.

2) That the TCP stack itself does not need to be multi-protocol, as a
"bump in the API" is sufficient.

The first advantage is only valid in some contexts, i.e. when
maintaining an IPv4 infrastructure is actually costly. In an unmanaged
network, which is typically single subnet, this advantage all but
disappears: the only real piece of infrastructure needed to support IPv4
is the DHCPv4 server, but this is also needed to allocate IPv4 addresses
to hosts in the SIIT environment. The second advantage is also
questionable: I don't know many platforms that support dual stack
applications and would not also feature a dual TCP-IP stack.

> I'd agree that this is complex; perhaps too complex.

I think itojun pointed at the real cost of the mechanism, which is
confusion between IPv4 and IPv6 paths, leading to possible security
errors. Another possible problem is, what happens if the host mistakenly
sends a packet where the destination address is a mapped address, while
the source address is a regular IPv6 address?

> Which is why the v6ops WG needs to look at which transition mechanisms
> are truly needed.

From the unmanaged analysis, it seems that we need two mechanisms:

1) A simple way to run dual-stack hosts in an IPv6 only infrastructure,
assuming that we can allocate a "realm-unique" IPv4 address to each dual
stack host.

2) A "classic NAT", complete with ALG et al., that let an IPv6 only host
contact servers on the IPv4 Internet, without assuming allocation of an
IPv4 address to the host, and with only limited IPv4 knowledge in the
host.

There have been two attempts at the first mechanism, SIIT, which uses
translation, and DSTM, which uses tunneling. Both have their
limitations: translation creates some "interesting" corner cases; DSTM
tunneling imposes that all IPv4 packets go through a relay. My
preference would be to evolve DSTM into a complete "IPv4 over IPv6"
specification, thus providing a well defined solution for dual stack
hosts in an IPv6 only network.

The "classic NAT" is a simple evolution of what NAT do today, including
port mapping and application gateways, just replacing occurrences of
"private addresses" by "IPv6 addresses". We can benefit of a SIIT-like
approach by representing IPv4 addresses in IPv6 as "<translator's
prefix>:I.P.V.4", making it trivial for IPv6 hosts to target IPv4
servers; gateway state will be needed in the other direction.

-- Christian Huitema

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 Sep 2002 12:23:39 +0200 (CEST)

> "bump in the API" is sufficient.

There is also the theoretical possibility to share the IPv4 addresses
by doing very short leases. But practical benefits of this is a function
of the traffic pattern. If most of the IPv6-only nodes communicate with IPv4
nodes every few minutes you'll need one IPv4 address per node in any case.

And the disadvantage of SIIT with short leases is that the host
protocol stack needs to detect when an IPv4 address is needed
(and ask DHCPv6 for one just like in DSTM) as well as keep track
of when it needs to be refreshed (so that the address can be released
when no more connections and "sessions" over UDP use the address).
That add a fair amount of complexity to the host.

> errors. 

I actually think that class of issues can be handled because
the information is all available to the host. Thus the host
can have different rules for when to accept packets from :ffff:1.2.3.4
than IPv4 packets from 1.2.3.4.
Of course, the recommendations for default policy rules and their motivation
should be written down in order to help implementors build secure stuff.

> Another possible problem is, what happens if the host mistakenly

Nothing useful. The RFC says to use 0.0.0.0 as the IPv4 source
in that case (which allowsthe  traceroute from the IPv4 end to display 0.0.0.0
for ICMP errors generated from native IPv6 routers).
Perhaps it would be better to send back an error in this case.

Basically with SIIT it makes no sense for a host to originate an IPv6 packet
towards an IPv4-mapped address unless it has an IPv4-translatable source
address.

> assuming that we can allocate a "realm-unique" IPv4 address to each dual

Yep. More detailed questions are 
 - whether it is worth-while to try to allocate and release the IPv4 address 
   on demand, or whether to try to keep it forever once it has been configured.
 - how remote (from a trust perspective) is the IPv4 address allocator; in
   particular is it operated by the same entity as the host, or by some
   remote service provider?
   In the former case DoS attacks against the address pool is a local matter;
   in the latter case one might need deployable DHCP authentication to
   limit the impact of DoS.

> IPv4 address to the host, and with only limited IPv4 knowledge in the

Yep.
I wonder whether it would be desirable to be able to have DNSSEC work
through such a box i.e. not prevent the hosts from verifying the DNSSEC
signatures.

  Erik