Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)]

["Fred L. Templin" <ftemplin@IPRG.nokia.com>]

Brian and Keith,

Please don't get me wrong; I'm not suggesting the reinvention of any
wheels here (and I'm *certainly* not arguing in favor of sub-optimality).
I guess what I'm doing is speculating as to whether a truly general-purpose
transition mechanism is possible that would unite the functions of several
existing mechanisms. Ideally, this could entail near-100% code reuse and
would only require building simple links between existing modules so that
the correct functionality is activated under the proper circumstances.

By way of example, my laptop normally connects to my company's network
which accesses the global IPv4 Internet via firewalls, proxies, etc. as
for any corporate Intranet. If I were to enable a transition mechanism
on my laptop while at work, I would probably choose isatap - and hope that
the site has configured a 6to4/isatap router. But, suppose I wanted to take
my laptop home and connect it to the NAT hub behind my DSL modem. In that
case, I would clearly need to use teredo. Suppose I then wanted to take
the laptop to an academic campus with open Internet access; i.e., no
proxies, firewalls or NATs to traverse. In that case, host-based 6to4
would provide the optimal solution. (Example scenarios requiring other
useful mechanisms, e.g., DSTM, configured tunnels, etc., could also be
given.)

I would think it highly unlikely that the average user would understand
or even care about the subtleties of the various scenarios, which suggests
to me that the decision point needs to be automated. I think this might be
possible - especially if a unified addressing scheme were used that places
local IPv4 unicast routing information in the interface identifier portion
of the IPv6 address and global routing information (to possibly include
global IPv4 routing information) in the routing prefix.

Does the above give you a better idea of where I'm coming from?

Fred
ftemplin@iprg.nokia.com

Brian E Carpenter wrote:
> "Fred L. Templin" wrote:
>
>>>I use 6to4 on hosts every day, so I don't consider it hammering.
>>>
>>>But 6to4 was primariliy intended for routers.  That it happens
>>>to work on some hosts is a happy side-benefit, not the design goal.
>>>
>>>Keith
>>
>>If you want to run 6to4 on a host that happens to have a global IPv4 address
>>and can accept 'ip-proto-41' w/o creating a security risk, then that is fine.
>>But (and you seem to recognize this), if one wants to postulate a "generalized
>>host-based 6to4" mechanism, that is a different matter and one that is not
>>covered by any existing RFCs.
>>
>>To realize a "generalized host-based 6to4", one would need to incorporate the
>>NAT traversal mechanisms first pioneered by TEREDO and the two-stage (end-to-edge;
>>edge-to-internet) tunneling mechanism first pioneered by ISATAP. But, then this
>>becomes more than just vanilla 6to4 and represents a unified transition mechanism
>>that incorporates elements proven by earlier works in various degrees. Finally,
>>a truly generalized mechanism would work behind a corporate firewall w/o requiring
>>any per-host firewall filter configurations and w/o exposing the site to outside
>>attackers. It's not clear to me whether a solution for this exists - but, it
>>would be pretty interesting if one could be identified!
>
>
> If you are really stuck behind a NAT you have no choice but to try some
> Teredo-like trick, and one Teredo in the world is enough. But trying to
> support enterprise scenarios where neither the ISP, nor the corporate IS
> people, are willing to support IPv6, *and* there is a NAT in the way, is
> just not worth considering IMHO. Too complicated, too many failure modes.
>
>    Brian