[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt



Jordi,

> A number of transition mechanism have been defined already: Teredo,
> TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of them work when

Your missing DSTM in this analysis why is that?

Also I am not clear you can mix and match transition or automate this
because new mechanisms will be continued to be developed.

thanks
/jim


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Thursday, April 29, 2004 5:14 AM
> To: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
> 
> Hi Brian,
> 
> Yes, I agree we are too ambitious ;-) but we should try at 
> least ... Let's see how we can progress and in what 
> circumstances this is possible (for example when disruption 
> and/or keeping the same address is not a problem). We will 
> work further on this aspect to concrete the text.
> 
> Of course, we can count with multi6 and/or MIPv6, so again, 
> we will need some more work here.
> 
> Agree, we need to list TLS/SSL.
> 
> Thanks for your inputs !
> 
> Regards,
> Jordi
> 
> ----- Original Message -----
> From: "Brian E Carpenter" <brc@zurich.ibm.com>
> To: "IPv6 Operations" <v6ops@ops.ietf.org>
> Sent: Wednesday, April 28, 2004 2:36 PM
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
> 
> 
> > > 
> http://www.ietf.org/internet-drafts/draft-palet-v6ops-auto-tra
> ns-00.txt
> > 
> > This is a very interesting concept, but I have some doubt 
> about the goal
> > of spontaneously changing to a different mechanism without 
> disruption.
> > I think it is over-ambitious. As pointed out in section 
> 3.2, point 1,
> > this requires keeping the same address even if (for 
> example) changing
> > from one tunnel provider to another - that's very unlikely to
> > work (unless of course we have a fully deployed multi6 solution
> > or use mobile IP exclusively). So I would be tempted to 
> limit the scope
> > to choosing the best initial method.
> > 
> > One detail: Section 3.3.3 discusses "layer 4" tunnels but doesn't
> > list IPv6 over TLS/SSL - but that is a very real 
> possibility (in fact
> > I use IPv4 over SSL very frequently, since it gets through 
> certain NATs
> > that IPSEC over UDP cannot deal with). It looks like a better option
> > than IP over SSH to me, and certainly better than IP over HTTP.
> > 
> > I'm not sure that we should even list this class of solution
> > as discouraged. It should perhaps be lower on the list of
> > preferences, but whatever works is good.
> > 
> >      Brian
> > 
> > 
> 
> 
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be 
> privileged or confidential. The information is intended to be 
> for the use of the individual(s) named above. If you are not 
> the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, 
> including attached files, is prohibited.
> 
> 
> 
> 
>