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