[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enhanced SIIT
> >
> > 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.
Hesham
>
> - Alain.
>
>
>