[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.
>
>
>
>
>