[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enhanced SIIT



Hesham,

On 2007-10-18 16:35, Hesham Soliman wrote:
> > > > In my opinion we have to be very systematic about this. > The only way
 > > that we can avoid the intrinsic problems of stateless translation
 > > seems to be to have awareness at the IPv6 end that translation is
 > > happening. (The underlying problem is how to reach legacy IPv4
 > > hosts, who by definition can have no such awareness). That seems to
 > > mean getting rid of the "less" in "Stateless IP/ICMP Translation",
 > > so I think we need to go back to basics. I don't have any specific
 > > proposals in mind, but I'm pretty sure that signalling between
 > > the translator and the IPv6 host will be needed.
> > We have been studying network-triggered translation vs > end-device-triggered > translation. One thing that came out of that study is what > happen when the > translator in the middle fails. If you have a model where > mappings are > triggered by the end-devices, you are going to create a > storm of mapping
 > requests to the fall-back translator.

=> I don't know if anyone remembers this draft by Eirk and I some 7 years
ago:
http://tools.ietf.org/html/draft-ietf-ngtrans-siit-dstm-01

It did maintain the statelessness of the translator. The concern at the time
was that
allocating addresses based on external triggers (DNS lookup from some node
on the Internet)
was a serious DoS attack. But even if you remove that feature/bug, the  rest
of the draft still applies today, given a mechanism of allocating an IPv4
address to the IPv6 host. At the time we chose DSTM, but any mechanism would
work. I think it can be a good reference if the WG still wants to work with
translators.

I didn't consciously remember that draft, but DSTM+NAT4 did occur to
me the other day as a possibility. However, I don't think there's any
real need for the DSTM server and the SIIT or NAT4 box to be separate
- the main point is to define how the IPv6 end knows that it's being
forced from native IPv6 mode to translated mode, and knows what the
other end's view of the source and destination addresses is. (It sounds
a bit like shim6 at that point, with the legacy IPv4 host only being able
to handle IPv4 ULIDs.)

     Brian