Subject: RE: [Softwires] IPv4 over IPv6 in Hubs and Spokes?

From: "Ed Koehler Jr" <[email-masked]>
Date: Fri, 13 Jan 2006 08:02:51 -0500

Jordi,

Agreed. I did not speak to this in my response. You are referring to NAT-PT like concepts. This is cool. (Although I share your feelings on its usage) I was not referring to dual stacks in the core or access however, as the shift occurs to IPv6 only, I would envision dual stack islands and IPv4 only islands. 

When you think about it, only peer to peer sessions really require protocol translations. Apps like VoIP and videoconferencing. Many apps can work quite well with a dual stack implementation at the server that services and internally handles both IPv4 and IPv6 sessions. This way both IPv6 and IPv4 populations will have access to a given service. HTTP, FTP would be a good usage examples. 

I am not a proponent of throwing dual stack everywhere nor am I proponent of wide spread usage of protocol translation. I am however a proponent of placing the onus more and more on IPv4 as time progresses. The more this occurs the more pressure to force user populations to migrate.

I think that an intelligent combination of all of these methodologies will come into play. I also think that there will be different usage combinations. (Which I think you are implying) Since this group (I am assuming) is only focusing on tunneling, my response was focused to that extent.

Regards

Ed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Friday, January 13, 2006 7:35 AM
To: [email-masked]
Subject: Re: [Softwires] IPv4 over IPv6 in Hubs and Spokes?

Hi Ed,

Actually there are already some networks with are already *only* IPv6 in the access and the backbone (not in the LAN, which I will never recommend at lest for tens of years). When we started the v6tc work, which somehow is the precursor of softwires, we had this cases in mind.

Right now I can name 3 networks on this situation and they are big, from 5.000 to 8.500 end sites.

This seems to be also the case for the scenarios coming for some defense networks.

The point is that when you have a lot of IPv6-dominant traffic, within your a given network, and only few IPv4 exchange with Internet, or only mainly for a few specific protocols, such as http, and you do that via proxy/cache devices, then is easy (as we already did), to install a proxy which does a protocol translation (and this is the only case where I will accept a translation, because the end-to-end is already lost because the proxy, so we don't break anything that is not already broken).

At this way, you operate a single stack (IPv6) core and access network, which has some advantages (cost, O&M) , and only those applications that aren't ported to IPv4 will need to use softwires (which are the minority in our specific cases).

Regards,
Jordi

> De: Ed Koehler Jr <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 13 Jan 2006 07:09:40 -0500
> Para: <[email-masked]>
> Conversación: [Softwires] IPv4 over IPv6 in Hubs and Spokes?
> Asunto: RE: [Softwires] IPv4 over IPv6 in Hubs and Spokes?
> 
> Folks:
> 
> As time progresses and IPv6 (hopefully) becomes mainstream, the 
> requirement for dual stack will shift from newer IPv6 hosts (for 
> backwards compatibility (today and near future) to IPv4 hosts that 
> wish to have connectivity to the next generation Internet (more 
> distant future). IPv4 will not be going away any time soon. It will 
> most probably be around for the rest of our lifetimes, but its 
> precedence will shift. I could even foresee ten years or more out 
> where you will find pockets of IPv4. The concept of islands 
> consequently will shift from IPv6 to IPv4. As this shift occurs (and 
> will need to be supported), there will be a corresponding shift in 
> tunneling as well as the dual stack requirements that I refer to 
> above.
> 
> As a result, I think that both aspects should be covered.
> 
> Just my thoughts...
> 
> Edwin C. Koehler
>  
> Nortel
> Real Time Networks & IPv6
> Enterprise CTO Group
> 97 Humboldt Street
> Rochester, New York  14609
> Office:  585.654.2323  ESN 432.2323
> Fax:     585.654.2500
> Mobile: 585.230.0505
> SIP and email: [email-masked]
> 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of JORDI PALET MARTINEZ
> Sent: Friday, January 13, 2006 4:27 AM
> To: [email-masked]
> Subject: Re: [Softwires] IPv4 over IPv6 in Hubs and Spokes?
> 
> 
> Hi Spencer,
> 
> I guess that's me ;-)
> 
> I believe there is no reason to not have that drawing and on the other 
> way around, if the draft includes also IPv4-in-IPv6, we must have it, 
> to make it more clear. Not ?
> 
> I only realized that we missed that when I did one of the last 
> reviews, but it should have been there since the beginning !
> 
> Regards,
> Jordi
> 
> 
> 
> 
>> De: Spencer Dawkins <[email-masked]>
>> Responder a: <[email-masked]>
>> Fecha: Thu, 12 Jan 2006 19:54:32 -0600
>> Para: Softwires Mailing List <[email-masked]>
>> Asunto: [Softwires] IPv4 over IPv6 in Hubs and Spokes?
>> 
>> One Problem Statement reviewer pointed out that all of the examples 
>> in
> 
>> Figure 1 of the problem statement transit an IPv4 network between 
>> softwire initiator and softwire consolidator, and offered a drawing 
>> of
> 
>> a fourth example that uses IPv4 over IPv6 transit.
>> 
>> Before I add this to the Problem Statement, does anyone actually have 
>> this problem? All of the the IPv4 over IPv6 discussion I've seen has 
>> been for the Mesh application - please let me know if I am missing 
>> some background here (it has happened :-)
>> 
>> Thanks!
>> 
>> Spencer
>> 
>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> [email-masked] https://www1.ietf.org/mailman/listinfo/softwires
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available 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.
> 
> 
> 
> 
> _______________________________________________
> Softwires mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/softwires
> 
> 
> _______________________________________________
> Softwires mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/softwires

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available 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.

_______________________________________________
Softwires mailing list
[email-masked] https://www1.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 13 Jan 2006 14:18:30 +0100

Hi Ed,

Well, actually I don't like to use NAT-PT. For that kind of translation
there are more simple tools, such as FFPROXY, Squid (in case you need
caching), or even Apache itself.

Regards,
Jordi

> Responder a: <[email-masked]>
> Fecha: Fri, 13 Jan 2006 08:02:51 -0500
> Para: <[email-masked]>, <[email-masked]>
> Agreed. I did not speak to this in my response. You are referring to NAT-PT
> like concepts. This is cool. (Although I share your feelings on its usage) I
> was not referring to dual stacks in the core or access however, as the shift
> occurs to IPv6 only, I would envision dual stack islands and IPv4 only
> islands. 
> 
> When you think about it, only peer to peer sessions really require protocol
> translations. Apps like VoIP and videoconferencing. Many apps can work quite
> well with a dual stack implementation at the server that services and
> internally handles both IPv4 and IPv6 sessions. This way both IPv6 and IPv4
> populations will have access to a given service. HTTP, FTP would be a good
> usage examples. 
> 
> I am not a proponent of throwing dual stack everywhere nor am I proponent of
> wide spread usage of protocol translation. I am however a proponent of placing
> the onus more and more on IPv4 as time progresses. The more this occurs the
> more pressure to force user populations to migrate.
> 
> I think that an intelligent combination of all of these methodologies will
> come into play. I also think that there will be different usage combinations.
> (Which I think you are implying) Since this group (I am assuming) is only
> focusing on tunneling, my response was focused to that extent.
> 
> Regards
> 
> Ed
> 
> Actually there are already some networks with are already *only* IPv6 in the
> access and the backbone (not in the LAN, which I will never recommend at lest
> for tens of years). When we started the v6tc work, which somehow is the
> precursor of softwires, we had this cases in mind.
> 
> The point is that when you have a lot of IPv6-dominant traffic, within your a
> given network, and only few IPv4 exchange with Internet, or only mainly for a
> few specific protocols, such as http, and you do that via proxy/cache devices,
> then is easy (as we already did), to install a proxy which does a protocol
> translation (and this is the only case where I will accept a translation,
> because the end-to-end is already lost because the proxy, so we don't break
> anything that is not already broken).
> 
> At this way, you operate a single stack (IPv6) core and access network, which
> has some advantages (cost, O&M) , and only those applications that aren't
> ported to IPv4 will need to use softwires (which are the minority in our
> specific cases).
> 
> Regards,
> Jordi
> 
> 
> 
> 
> 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.
> 
> 
> 
>