Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6

From: Sheng Jiang <[email-masked]>
Date: Mon, 07 Dec 2009 11:25:20 +0800

> -----Original Message-----
> From:  Sri Gundavelli

> As I said and to repeat one more time, I'm not convinced 
> about that use-case. This is not a legacy issue, there are no 
> deployed applications currently operating in that mode. We 
> talked to many operators, every one is planning to use IPv6 
> transport for the UE to UE scenario. This argument that both 
> the hosts are IPv6-only capable, but they cant use IPv6 
> transport is not going to go any where.

Hi, Sri,

I believe you have talked to many operators and understand their
requirements. But I am also sure you have NOT talked with EVERY operators
and understand ALL requirements. From this thread, what I read is an
operator is taking about its requirement scenario, then you guys tried to
say there are different solutions meet other different requirements.

For my understanding, you can not shrug off the requirement from legacy
applications as easy as you said. Apple may be able to put considerable
efforts to update and recompile all there legacy applications since they are
in a walled garden and most of their applications are under their direct
development. That's not a general case. Actually, apple is so special, we
should consider it the last. Here, we are talking about thousands different
applications from thousands different ICPs. Could you make sure they all
have the extra budget for IPv6? I cannot. So, there are such reality
requirements.

Host-based translation approach actually helps these legacy applications be
able to extend their services to IPv6 network. It helps to convence people
IPv6 does not hurt you, it only brings you advantages. Eventually, it makes
IPv6 migration smoother.

BTW, this discuss should mainly be in behave wg, so I cc to both behave and
softwire.

Cheers,

Sheng
 
> We are talking about four lines of code change to use an IPv6 
> socket. As some one pointed out, when Apple released the new 
> 3GS, all most 80K applications required a re-compile. I don't 
> get the point that you have an
> IPv4 app, binaries only, but that will run on some future 
> platform with out recompile and talk to a future IPv6 
> application. May be your app development process is broken, 
> this is not a technical or a industry problem.
> 
> I'm not deviating from this point, as I said many times, we 
> don't deal with this case, its not realistic and there is a 
> work around. If you have any advantages in the host-based 
> translation approach that help in IPv6 migration besides this 
> artificial use-case, let me know.
> 
> 
> Regards
> Sri
> 
> 
> 
> On 12/5/09 6:39 AM, "Hui Deng" <[email-masked]> wrote:
> 
> > Hi Sri,
> > 
> > 2009/12/5 Sri Gundavelli <[email-masked]>:
> >> Hi Hui,
> >> 
> >> 
> >>>> 
> >>>> 1. DS-lite has an important property, making IPv4 
> address some what 
> >>>> irrelevant in the context of IP routing and just make it 
> a simple 
> >>>> state in two places, the mobile node and the NAT44 gateway. Its 
> >>>> allowing the network to migrate to IPv6 day-1, remove traces of 
> >>>> IPv4 in the core and access network, but continue to 
> offer IPv4 services.
> >>> DS-Lite is providing unlimited IPv4 address to the UE, 
> partly modify 
> >>> the small part of the bear network which could be constructed by 
> >>> multiple technologies such as GRE, L2TP,
> >>> IPv6 tunnel. I don't see
> >>> those tunnels have big difference.
> >>> 
> >>>> If this is not migration what is it ? Now, if the technology is 
> >>>> also
> >>> It is "Save IPv4" as Bo said before,
> >> 
> >> Hmm ... I cant beat this defense.
> >> 
> >> I don't see you disagreeing with my technical points and the 
> >> similarities I have shown in both the approaches. But, I 
> see that you 
> >> do not want to agree and so you summarize it to say, its 
> still just a 
> >> solution for IPv4-exhaust and not a step towards 
> migration, with no 
> >> backing by any technical arguments. That is fine. We agree or not, 
> >> its just translation vs., tunneling, a scheme that was 
> adopted in the 
> >> earlier versions of DS-lite and made a conscious decision 
> not to go with host-based translation scheme.
> > We are discussing 4-6 scenario here, it sounds strange that it is 
> > always deviated to another direction.
> > I don't see how it is related to translation vs tunneling.
> > 
> >> 
> >> Bottom line, we touched about the core aspects and also 
> one use-case 
> >> that you say is the key motivation for your chosen approach, which 
> >> the use-case itself is debatable and a clear solution 
> exists as many 
> >> folks pointed out, enable dual-stack on the server, or use 
> IPv6. We 
> >> also talked about the key resulting benefits in each of the 
> >> solutions. As far I see it, when
> > As far as I can see, the technical argument about our motivation 
> > hasn't been questioned any more.
> > And for solutions, you already agreed that you are no 
> supporting that.
> > 
> >> DS-lite/GI-DS-lite is applied to mobile architectures, we have all 
> >> the required tools for migration.
> > I guess that this is only said by one people, every other 
> people has 
> > different opinion on this.
> > 
> > -Hui
> > 
> >> 
> >> 
> >> Regards
> >> Sri
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On 12/4/09 6:46 AM, "Hui Deng" <[email-masked]> wrote:
> >> 
> >>> Hi, Sri,
> >>> 
> >>> Thanks for the discussion, inline please
> >>> 
> >>> 2009/12/4 Sri Gundavelli <[email-masked]>:
> >>>> Hi Hui:
> >>>> 
> >>>> You and Bo touched a very important point. Your point is that 
> >>>> DS-lite is just about IPv4 address exhaust and not about 
> migration. 
> >>>> You already heard from Alain and that's the best source. 
> But, I'll 
> >>>> comment in the context of mobile architectures and 
> application of GI-DS-lite.
> >>>> 
> >>>> 1. DS-lite has an important property, making IPv4 
> address some what 
> >>>> irrelevant in the context of IP routing and just make it 
> a simple 
> >>>> state in two places, the mobile node and the NAT44 gateway. Its 
> >>>> allowing the network to migrate to IPv6 day-1, remove traces of 
> >>>> IPv4 in the core and access network, but continue to 
> offer IPv4 services.
> >>> DS-Lite is providing unlimited IPv4 address to the UE, 
> partly modify 
> >>> the small part of the bear network which could be constructed by 
> >>> multiple technologies such as GRE, L2TP,
> >>> IPv6 tunnel. I don't see
> >>> those tunnels have big difference.
> >>> 
> >>>> If this is not migration what is it ? Now, if the technology is 
> >>>> also
> >>> It is "Save IPv4" as Bo said before,
> >>> 
> >>>> allowing multiplicity assignment of the same IPv4 address to all 
> >>>> mobile nodes (since, the address is just a state on the 
> gateway and 
> >>>> is not used for IP routing), that's a side affect and solves the 
> >>>> address exhaust problem to some extent. But, there is still 
> >>>> limitation w.r.t the public address usage on the NAT44 gateway.
> >>> yes, this is really a smart technology which could save IPv4.
> >>> 
> >>>> 
> >>>> 2. Lets look at PNAT. Your single biggest motivation is to allow 
> >>>> your legacy
> >>>> IPv4 applications to work on an IPv6 host that has only IPv6 
> >>>> transport and on IPv6-only core network. How are you 
> achieving this 
> >>>> ? Your IPv4
> >>> It has already happened, and you already see our slides.
> >>> 
> >>>> application is using an IPv4 address (valid or invalid) 
> and there 
> >>>> is a socket and translation state that is getting created on the 
> >>>> host and on the
> >>>> NAT44 gateway, your routing is all based on IPv6. You are making 
> >>>> IPv4 just a state in the host and on the gateway.
> >>>> 
> >>>> What is the difference between #1 and #2 ? PNAT is 
> solving all that 
> >>>> DS-lite solves and also has an indirect property of solving the 
> >>>> IPv4 address exhaust issue. But, its coming at a huge cost and 
> >>>> baggage i.e., Host changes.
> >>> We spend two weeks here, and you admit that you don't support our 
> >>> first scenario.
> >>> do u need I point out the mailing list link about what you said?
> >>> everybody is changing his host everyday by installing new 
> software, 
> >>> you may be scared to change your laptop, but I am not that afraid.
> >>> 
> >>>> 3. When I apply DS-lite to mobile architectures which 
> already have 
> >>>> good support for dual-stack and the ability to carry 
> both IPv4 and 
> >>>> IPv6 on mobility tunnels, its allowing an operator to 
> migrate their 
> >>>> network to IPv6-only and is also solving the address 
> exhaust issue.
> >>>> 
> >>>> - No changes to UE
> >>>> - UE can be IPv4-only or IPv6-only
> >>>> - Access network can IPv6-only
> >>>> - Core network (PGW-CGN) can be IPv6-only
> >>>> - Allow IPv6 for UE to UE communication. Allow IPv4 to 
> IPv4 UE to 
> >>>> communication when using non-overlapping IP addresses. 
> Allow IPv6 
> >>>> applications to communicate with IPv4 end node using NAT64.
> >>>> - Allow access network and core network to migrate to IPv6 at 
> >>>> different point of time.
> >>> I would say that you made a fantastic invention which 
> really saves 
> >>> IPv4, good work.
> >>> I come out of a good idea that during next IETF, we would 
> better to 
> >>> propose a BoF about "Save IPv4"
> >>> Bo could become the BoF chair (if AD allows), then invite 
> >>> GW-Init-DS-Lite ... to join.
> >>> 
> >>>> But, its missing one hypothetical case, which the 
> scenario is not 
> >>>> realistic and even otherwise, one can always enable 
> dual-stack on 
> >>>> the other peer, or use IPv6 transport.
> >>>> 
> >>>> So, my friend, Dear Hui, there is no difference between what you 
> >>>> want to solve and what is on the table. Tell me, what 
> I'm missing.
> >>> Dear Sri, I really don't want to point to that link where 
> you said a 
> >>> few days ago that you don't support it.
> >>> 
> >>> Thanks
> >>> 
> >>> -Hui
> >>> 
> >>>> 
> >>>> 
> >>>> Regards
> >>>> Sri
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> On 12/3/09 4:43 AM, "Hui Deng" <[email-masked]> wrote:
> >>>> 
> >>>>> Hi, Sri,
> >>>> 
> >>>>>> But, don't deal with the case of IPv4 legacy application 
> >>>>>> communicating with a IPv6 future application using IPv4. By 
> >>>>>> allowing that one case which has no justification, you have to 
> >>>>>> deal with the resulting baggage of host translation and UE 
> >>>>>> changes. Instead use IPv6 for host to host as you say.
> >>>>>> This is not a legacy issue.
> >>>>> You are making two different seperated world, it won't success.
> >>>>> You didn't answer my previous two emails in seperated line.
> >>>>> I could ask here again, you are assigning unlimited 
> IPv4 address 
> >>>>> to the host, and encouraging me to install IPv4 
> appliation server, 
> >>>>> I feel what you proposed is more like prolong IPv4 world and 
> >>>>> solveing the problem of IPv4 address exhaustion but not IPv6 
> >>>>> migration.
> >>>>> Based on your proposal, IETF would better to setup a 
> working group 
> >>>>> about
> >>>>> IPv4 address exhaustion about it, other than IPv6 migration.
> >>>>> 
> >>>>> thanks
> >>>>> 
> >>>>> -Hui
> >>>>> 
> >>>> 
> >>>> 
> >> 
> >> 
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 06 Dec 2009 20:34:33 -0800

Hi Sheng,

Removing the cross posting. Moving it to behave as you suggested.

> have the extra budget for IPv6? I cannot. So, there are such reality

Sure, I agree, the Apple example may be an example of a very well managed
and controlled application development environment. However, the use-case
does not appear to be a common or a industry problem, its very hard to
believe any operator have to deal with it. May be its unique to only one
operator.

My argument is that, this is not a legacy issue. If there is a legacy mobile
application that you have only binaries, its hard to believe that you can
run that mobile application without even compiling on a newer platform a
year or two later which will have IPv6-only stack. If you have to re-compile
that for a platform that you will support, say a year from now, its matter
of making that 4 line change to use IPv6 sockets.

Second, you can always set a a requirement for newer applications to be able
to use sockets in a version independent manner. This is about a application
acceptance process and else these applications will be retired and cannot
run on your IPv6-only network and on a host with IPv6-only stack.

You also have the option to enable IPv4 on the peers and allow those
applications to survive till they are phased out, or migrated to IPv6. But,
brining a complex set of host stack changes for this may not a good idea.
Its too much of baggage and a very expensive solution. You are talking about
managing modified stacks on many operating systems and versions along with a
set of ALG's (assuming twice translation is required in some cases).

> IPv6 does not hurt you, it only brings you advantages. Eventually, it makes

Not sure. I agree. You really don't want to bring 464. DS-lite in the early
stages reviewed that approach and moved away from it.

Even if this is real, there can be network based approaches, or an implicit
peer to peer generic IPv6 tunneling modes, as Dan suggested. I'm not sure,
about host-based translation approaches.

> BTW, this discuss should mainly be in behave wg, so I cc to both behave and

Ok. Thanks !

Regards
Sri

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 6 Dec 2009 22:09:34 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: Sunday, December 06, 2009 7:25 PM
> To: 'Sri Gundavelli'; 'Hui Deng'
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] [Softwires] Host based translation: v4-v6
> 
> in a walled garden and most of their applications are under 
> their direct development. 

My iPhone has approximately 22 applications written by Apple.  The
other ~80,000 applications available for the iPhone are not written
by Apple.

> That's not a general case. Actually, apple is so 
> special, we
> applications from thousands different ICPs.

That is how the iTunes store works; most of the applications
are developed independently.  The source code is not owned or
seen by Apple.

Yet, when Apple changed the iPhone OS between version 2 and version
3, tens of thousands of the applications were upgraded to work
with version 3 of the iPhone OS.  Hundreds weren't, and some of
those still work fine, and some don't work anymore.

> Could you make sure they all
> IPv6 does not hurt you, it only brings you advantages. 

If the original application developer is not investing in 
their application's support for IPv6, some other organization 
has to make that investment instead.  That is, some other
organization has to "pull along" an application into the
modern IPv6 era.

That is the pushback we are seeing here:  the investment to
"pull along" an application can not be carried, successfully
and in perpetuity, by another organization.  The incentives
are in the wrong place, and there are high barriers to 
success.  

This is why the industry, as a whole, has been adding NAT
traversal to applications (e.g., SIP, Skype, RTSP, and 
others) rather than building and specifying ALG, and 
rather than solely relying on UPnP IGD / NAT-PMP.

-d

> Eventually, it makes IPv6 migration smoother.
> 
> BTW, this discuss should mainly be in behave wg, so I cc to 
> both behave and softwire.
> 
> Cheers,
> 
> Sheng
>  
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 07 Dec 2009 14:29:39 +0800

Hi, Sri,

I believe we share many common opinions and have minimum different here:
eventually, all networks, devices, applications should be IPv6-enabled, even
IPv6-only. Before that, there would be a long period of IPv6/IPv4
co-existing. That's why we are here discussing transition mechanisms. That
means we already admire some of networks, devices, applications could stay
in IPv4-only for a while.

I agree that your code change requirement can solve the issues we discuss
here. However, it is just like we say if everyone going to IPv6-only, we
won't have transition issues. My argument here is that you cannot assume
every application providers can accept your code change requirement. Between
2001 and 2004, I had experience made applications (like Grid middleware)
IPv6-enabled. It is much more complicated than your "4 line change".
Depending on the original applications, java application could be much
easier than c/c++ based application. Some of applications even need
independent driver to be IPv6-enabled.

So, as one of transition mechanisms, PNAT meets the requirements that some
applications would stay in IPv4-only but want to connect to the whole world,
include IPv6 world. For the transition period, changing protocol stacks
(embeded tens different OS) is much easier than changing all applications
(probably millions).

Cheers,

Sheng

> > requirements. But I am also sure you have NOT talked with EVERY 
> > operators and understand ALL requirements. From this thread, what I 
> > read is an operator is taking about its requirement 
> scenario, then you 
> > guys tried to say there are different solutions meet other 
> different requirements.
> > 
> > For my understanding, you can not shrug off the requirement from 
> > legacy applications as easy as you said. Apple may be able to put 
> > considerable efforts to update and recompile all there legacy 
> > applications since they are in a walled garden and most of their 
> > applications are under their direct development. That's not 
> a general 
> > case. Actually, apple is so special, we should consider it 
> the last. 
> > Here, we are talking about thousands different applications from 
> > thousands different ICPs. Could you make sure they all have 
> the extra 
> > budget for IPv6? I cannot. So, there are such reality requirements.
> > 
> 
> Sure, I agree, the Apple example may be an example of a very 
> well managed and controlled application development 
> environment. However, the use-case does not appear to be a 
> common or a industry problem, its very hard to believe any 
> operator have to deal with it. May be its unique to only one operator.
> 
> My argument is that, this is not a legacy issue. If there is 
> a legacy mobile application that you have only binaries, its 
> hard to believe that you can run that mobile application 
> without even compiling on a newer platform a year or two 
> later which will have IPv6-only stack. If you have to 
> re-compile that for a platform that you will support, say a 
> year from now, its matter of making that 4 line change to use 
> IPv6 sockets.
> 
> Second, you can always set a a requirement for newer 
> applications to be able to use sockets in a version 
> independent manner. This is about a application acceptance 
> process and else these applications will be retired and 
> cannot run on your IPv6-only network and on a host with 
> IPv6-only stack.
> 
> You also have the option to enable IPv4 on the peers and 
> allow those applications to survive till they are phased out, 
> or migrated to IPv6. But, brining a complex set of host stack 
> changes for this may not a good idea.
> Its too much of baggage and a very expensive solution. You 
> are talking about managing modified stacks on many operating 
> systems and versions along with a set of ALG's (assuming 
> twice translation is required in some cases).
> 
> 
> > Host-based translation approach actually helps these legacy 
> > applications be able to extend their services to IPv6 network. It 
> > helps to convence people
> Eventually, it 
> > makes
> Not sure. I agree. You really don't want to bring 464. 
> DS-lite in the early stages reviewed that approach and moved 
> away from it.
> 
> Even if this is real, there can be network based approaches, 
> or an implicit peer to peer generic IPv6 tunneling modes, as 
> Dan suggested. I'm not sure, about host-based translation approaches.
> 
> > BTW, this discuss should mainly be in behave wg, so I cc to both 
> > behave and softwire.
> > 
> 
> Ok. Thanks !
> 
> Regards
> Sri
> 
> 
> 
> > Cheers,
> > 
> > Sheng
> >  
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 08 Dec 2009 23:03:21 -0800

Hi Sheng,

If you decide to support such legacy IPv4 applications on future platforms,
its rather logical to go with a dual-stack network till you migrate those
applications to IPv6, or till you retire them. If your expectation is that
you will have millions of such applications that you need to carry forward
and without code recompilation on future platforms,  may be the choice of
IPv6-only network as the first step in IPv6 migration is not the right step.
A much more logical step would be to retain the IPv4 network and possibly
use Dual-stack lite to solve the IPv4 exhaust issue, then you don't have to
deal with these weird cases and introduce significant changes to all host
stacks. 

If I may ask, which out of the two is a cost affective approach ? (1)
Dealing with the development and maintenance of ALG's, modified host stacks
and translation functions on a zillion operating systems, Windows Mobile,
Linux, Android, iphone, BSD, Symbion ..., add changes to NAT64, ensure all
the roaming scenarios are not impacted, OR (2) just simply keep your
existing IPv4 network, don't turn it off on one fine morning in 2011 ? Are
the efforts even in the same order of magnitude ? May be the migration
strategy of that operator requires some re-thinking ?

Regards
Sri

---

From: Hui Deng <[email-masked]>
Date: Wed, 9 Dec 2009 23:50:12 +0800

fundamental difference here:
1) u r doing IPv4 and solving ipv4 problem
2) we are doing IPv6 and solving IPv6 problem

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 09 Dec 2009 08:17:21 -0800

You are deploying IPv6 on the network and have IPv6-only hosts:

- but your applications still use IPv4.
- they won't use IPv6 natively which is available

So, turning of IPv4, not sure, how its helping and what is migrated. And
this solution comes at a cost of making significant host stack changes and
having to maintain that code base for years to come.

And we are deploying IPv6, removing IPv4 routing from the network, but still
enabling support for IPv4 services and we are not modifying hosts.

Sri

---

From: bo zhou <[email-masked]>
Date: Thu, 10 Dec 2009 11:32:19 +0800

Dear Sri,

Reply inline.

On Wed, Dec 9, 2009 at 3:03 PM, Sri Gundavelli <[email-masked]> wrote:

> Dealing with the development and maintenance of ALG's,

[bo] I saw few words mentioned ALG inside DS-lite. And from Behave charter,
it clarified we only consider existed ALG issues, for future potential ALG
issue should be considered out of scope.

> modified host stacks
> existing IPv4 network, don't turn it off on one fine morning in 2011 ?

[bo] I guess you are talking using IPv4 forever, I agree DS-lite is a good
solution for solving IPv4 exhaustion issue, but not good for IPv6.

> Are

-- 
Regards,

Bo Zhou
China Mobile

---

From: bo zhou <[email-masked]>
Date: Thu, 10 Dec 2009 11:43:56 +0800

Hi Sri,

Reply inline.

> - they won't use IPv6 natively which is available
[bo] Can you ask application developer do something. Maybe not, what you can
do is recommend them do something. We cannot predict their behaviour, maybe
5０% follow your recommendation, 50% not.

> enabling support for IPv4 services and we are not modifying hosts.
[bo] Well, you introduce IPv6 as a tunnel, I believe it is a good solution
for IPv4 exhaustion. But I cannot see any motivation for existed IPv4
application developer upgrade their application to support IPv6, because
base on your solution, IPv4 working very well. So maybe in many ages, we
cannot see any application relies on IPv6.

-- 
Regards,

Bo Zhou
China Mobile

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 9 Dec 2009 20:21:13 -0800 (PST)

> cannot see any application relies on IPv6.

:) When PNAT is deployed, what is the motivation for the developer to use
IPv6 ? You plan to support their legacy IPv4 applications for ever. IPv4
is "working very well", and on IPv6 transport too. App developers can
continue to use IPv4-only sockets and can interact with potentially IPv6
future peers.

My point is, do not make those applications that use IPv4-only sockets
written for legacy platforms and have binaries only, to magically work
on new platforms that have IPv6-only transport. Let them migrate or
retire those applications. Let applications behave normally and don't
give special incentives there.

Sri

---

From: bo zhou <[email-masked]>
Date: Thu, 10 Dec 2009 15:02:11 +0800

Hi Sri,

I thought I caught a cold, hope it is not swine flu.
But it make my brain stop working.
But I will still reply you inline.

> continue to use IPv4-only sockets and can interact with potentially IPv6

[bo] At least, we allow 4-6 communication, allow the v4 client visit v6
server.

> give special incentives there.
[bo] Good point. But I remember you mentioned couple days ago, operators do
not want their customers experience the breakup of services. Do you think
any operator can take the risk to throw away some "already-run" services
from the network because these services  could not support new IPv6
transport platform?

-- 
Regards,

Bo Zhou
China Mobile

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Dec 2009 09:59:02 -0800

Hello Bo,

One question: why do you think DS-Lite is a good solution
for IPv4 address exhaustion?  I mean, why is it better than,
say, existing NAT solutions?

bo zhou wrote:
>     use Dual-stack lite to solve the IPv4 exhaust issue,
>
...

> [bo] I guess you are talking using IPv4 forever, I agree DS-lite is a 
> good solution for solving IPv4 exhaustion issue, but not good for IPv6.

As far as I have understood, DS-Lite doesn't really
help very much compared to existing NAT in most
cases.  But it does allow IPv6 and IPv4 applications
on the same host, and (from the standpoint of the existing
Internet) allows larger "privately addressed" domains to
be attached without the limitations of IPv4 private
address spaces.  Is there something more?

On the downside, at least in some proposals as are
being discussed in this thread, host modifications might
be required for the ALGs... right?

Regards,
Charlie P.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Dec 2009 07:17:50 +1100

> say, existing NAT solutions?

You have a million customers each with a around 5 clients machines
using 1 public address today with home CPE NAT's.

DS lite gives you 200+ client machines per public address and
puts IPv6 into the the home with without using NAT for IPv6.

In both cases this is with one level of NAT.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Dec 2009 11:16:23 +1300

> 5０% follow your recommendation, 50% not.

It rises to 100% when an application fails to work any more. That incentive
is pretty strong. But it drops to 0% if you promise to support a legacy
solution indefinitely, which guarantees long-term costs for the carriers
and avoids costs for the application developers. I don't understand the
business case for your requirement. Long term messy solution for vendors
and carriers versus simple short term work for application developers?

   Brian

> ------------------------------------------------------------------------
>