[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)]
- To: "Tony Hain" <alh-ietf@tndh.net>
- Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)]
- From: "Fred L. Templin" <ftemplin@IPRG.nokia.com>
- Date: Mon, 16 Sep 2002 17:46:36 -0700
- Cc: v6ops@ops.ietf.org
- Delivery-date: Mon, 16 Sep 2002 17:34:02 -0700
- Envelope-to: v6ops-data@psg.com
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610
Tony,
Tony Hain wrote:
> 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
Somehow, I was inferring a "glue" layer was needed to bind everything
together. But, your message makes me believe that won't be necessary
in well implemented stacks. Thanks for the comments,
Fred
ftemplin@iprg.nokia.com
>>-----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