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

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 16 Sep 2002 11:47:56 -0700

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
[email-masked]

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

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 16 Sep 2002 12:11:14 -0700

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred L. Templin
> Sent: Monday, September 16, 2002 11:48 AM
> To: [email-masked]
> 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.
> 
>  >>>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
> 
> 
> 
>