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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 29 Apr 2004 22:35:47 -0400

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
> Sent: Thursday, April 29, 2004 5:14 AM
> To: [email-masked]
> 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" <[email-masked]>
> To: "IPv6 Operations" <[email-masked]>
> 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.
> 
> 
> 
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 07:16:05 +0300 (EEST)

> Your missing DSTM in this analysis why is that?

I think the document is focused on obtaining _IPv6_ connectivity in 
IPv4-only networks, not the other way around.

...

FWIW, I personally agree with Brian's concern of too ambitious goals.  
Too ambituous goals often result in nothing getting done, instead of
what might have been realistic.  So, if it stays, it probably needs
"health warnings" or th like :)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Fri, 30 Apr 2004 14:27:29 +0200

See below, in-line.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "Bound, Jim" <[email-masked]>
Cc: "JORDI PALET MARTINEZ" <[email-masked]>; <[email-masked]>
Sent: Friday, April 30, 2004 6:16 AM
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt

> > Your missing DSTM in this analysis why is that?

Yes, Pekka is right, that's the point. We are assuming that the host is already dual stack, and we are looking for ensuring IPv6 connectivity, so we consider only scenarios where you have IPv6 native connectivity (but the performance is poor for whatever reason and we can improve it with a transition mechanism, for example to a nearer tunnel server) or where you have IPv4 convexity and want to get IPv6.

The document is focusing in the evaluation of those mechanism that we consider today have a better chance to provide better results. A follow up document will work on solutions, and possibly protocol description, and those documents could take care of more alternatives, even new transition mechanism that today don't exist, however we believe is difficult it happens (difficult to see mechanism that offer "more" that what we have now).

Anyway, we will improve the text in the next release to clarify this.

> "health warnings" or th like :)

As I already indicated replying to Brian, we will make sure to be more realistic and/or clear on this point in the next release.

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.