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

["Tony Hain" <alh-ietf@tndh.net>]

Fred,

There is nothing here that a well implemented stack that included
isatap, 6to4, & teredo wouldn't provide. If the sending rules are
followed, your nomad node would in fact work fine without further
effort. If that node wanted to be called, it would need to use mipv6
anyway, because its ipv4 address would be changing as it moved. So
putting that in the iid doesn't help the dns update problem. Finding a
provider for a home agent of a node that is only using transition
technologies would be a bit of a challenge, but there is no technical
reason for that to be a problem as long as the HA was accessable to it
over each of the technologies.

Tony


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred L. Templin
> Sent: Monday, September 16, 2002 11:48 AM
> To: v6ops@ops.ietf.org
> Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)]
> 
> 
> 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
> 
> 
> 
>