[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Hi Jim,
May be I worded it in the wrong way. My assumption right now is that you have always IPv4 connectivity.
The original goal was to ensure the best IPv6 connectivity in any situation (today's reality with most of the networks being only IPv4).
But I can see the auto-transition idea being applied also to ensure the best IPv4 connectivity if this is required (in the ideal world when we have most of the networks, or at least a good number of them, with IPv6). In this case is clear that DSTM is a very good option, I believe.
Initially we haven't considered this send option, but now I'm wondering if we should ? What is the opinion of others ? (just in case, to make it clear, when we have only IPv6 connectivity and want to ensure also IPv4).
Anyway, we will re-read DSTM documents to see if we missed something.
Will be happy to get your inputs on this, of course.
Regards,
Jordi
----- Original Message -----
From: "Bound, Jim" <jim.bound@hp.com>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>; <v6ops@ops.ietf.org>
Sent: Friday, April 30, 2004 2:37 PM
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
Jordi,
Your words from below:
>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.
Assumption 1 from your words:
There is an IPv6 Native Network.
Assumption 2 from your words.
There is an IPv4 network the packet can use for better performance.
Then DSTM is in fact an option and here is why:
DSTM Assumption 1:
As DSTM postulates it is possible that the user has deployed only IPv6
applications on a network.
DSTM Assumption 2:
There is an IPv4 routable address within the network scope of
communications that can be used by obtaining it from DHCPv6 or IPv6
Tunnel Broker.
Then the dual stack approach is used or Native IPv4.
Given your words you need to add DSTM or remove discussion of Native
IPv6 is my input.
I am now going to review your draft in depth to give you hard core
technical input as IPv6 engineering expert because your response was to
casual and not technical enough for me anyway.
/jim
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ
> Sent: Friday, April 30, 2004 8:27 AM
> To: v6ops@ops.ietf.org
> Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>
> See below, in-line.
>
> Regards,
> Jordi
>
> ----- Original Message -----
> From: "Pekka Savola" <pekkas@netcore.fi>
> To: "Bound, Jim" <jim.bound@hp.com>
> Cc: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>;
> <v6ops@ops.ietf.org>
> Sent: Friday, April 30, 2004 6:16 AM
> Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
>
>
> > On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > > 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?
> >
>
> 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.
>
> > 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 :)
> >
>
>
> 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.
>
> > --
> > Pekka Savola "You each name yourselves king, yet the
> > Netcore Oy kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> >
> >
>
>
> **********************************
> 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.
>
>
>
>
>
>
**********************************
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.