Subject: RE: ocean: do not boil

From: "Bound, Jim" <[email-masked]>
Date: Sat, 21 Sep 2002 11:41:30 -0400

> ASP is an enterprise, IMO.

Be good to get the group to all agree about this so the Enterprise Design Team 
understands that from the beginning.  I for one was unclear whether folks felt
ASP stuff should be in the Enterprise.  I don't care either way.  Just want to 
know early on as I am sure my colleagues on the Ent Design team want to know too.

> 
> Restricted use of TCP relay is IMO a rather good transition 
> solution for 
> some services.
> 

Not sure yet either way.  But the more relays, ALGs, and parts of this nature that one puts in the network will also cause more stuff for the users and operators to manage.

Maybe we need to have matrix somewhere and possibly in each scenario a "degrees of complexity/performance" for the overall operation of the network?

E.G. (this is just for discussion making no judgements of complexity/peformance below
just view as "model" for discussion)

Legend: 

C1 == Not complex just tunnels
C2 == Medium Complex tunnels and gateways
C3 == Very Complex tunnels, gateways, relays, bump-in-apis

P1 == best performance
P2 == fair performance
P3 == least performance

Scenario1 Solution A  | Sceneario2 Solution B  | Scenario3 Solution C
     C1/P3            |     C2/P1              |   C1/P1

The scenario, solution, and methods of transition would affect the
matrix entry.

We would need template to cause the most "objetive" analysis of course so it is
not subjective or supporting any specific agenda.

Could this actually be an informational rfc for v6ops too?

regards,
/jim

/jim

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 23 Sep 2002 22:54:53 +0200

> >=> I completely agree with Bob. I don't understand how we
  > >can rule out the v6only => v4 only communication.
  > >What do we say to operators who can't get enough
  > >v4 addreses? Deploy a v4 NAT as well as IPv6?
  > 
  > Why not?  How do we think that our attempts at v6->v4
  > translation will be better than deploying an IPv4 NAT?

=> I don't understand how you could convice someone
that IPv6 is needed because of the existing problems with
IPv4 (lack of addresses, NATs ....etc) but tell them that
they need NATs anyway to deploy v6. There is something 
broken in that logic. The difference between v4 NATs and
NAT-PT is that, in time we will hopefully phase out NAT-PT
or its use will be reduced significantly. You can't 
say the same thing about v4 NATs. 

I think a fresh operator would see an advantage in deploying
v6 immediately and run a single network. I'm not sure about
the strength of the logic demanding the deployment of v6
and v4 NATs at the same time.

  > 
  > >I can understand that communication between a v4only
  > >host initiating a connection with a v6 only host
  > >is too difficult and probably should not be a priority.
  > 
  > So, perhaps we are all in agreement on that.

=> I think so.

Hesham

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 23 Sep 2002 17:19:31 -0400

>they need NATs anyway to deploy v6.

And, you think this will read differently if the "NAT" has
a "-PT" on the end?

>There is something

They phase out at the same time -- as soon as it isn't
necessary for any host within the site to communicate with
an IPv4-only host, the NAT(-PT) functionality won't be
used any more and can be removed.

There are actually some advantages to the IPv4 NAT approach:

         - IPv4 communication works inside and outside the
                 site.
         - Leverages existing infrastructure/expertise in
                 IPv4 networking.
         - Doesn't break anything that worked before you
                 installed IPv6.

The main disadvantages would seem to be:

         - Need to run dual-stack on all nodes that need to
                 access IPv4-only nodes or services.
         - Need to assign IPv4 addresses (probably requires a
                 DHCP server)

I can see why those might be bigger issues for an all-new
installation, but do you really think they are blocking issues?

Would you agree that a current site that is using IPv4 behind a
NAT should deploy IPv6 side-by-side with the current IPv4 NAT
infrastructure?

Margaret

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 23 Sep 2002 23:34:37 +0200

> And, you think this will read differently if the "NAT" has

=> It will read and deploy differently :)

  > used any more and can be removed.

=> They probably will but what is the driver for someone
building a network to deply both ? I can't see anything
getting simpler here.

  >          - Leverages existing infrastructure/expertise in

=> I'm not addressing existing infrastructures, I was
referring to a fresh operator. In our DT's scope (cellular)
there will be a lot of those since the infrastructure is 
new.

  >          - Need to assign IPv4 addresses (probably requires a

=> Need to manage IPv4 multiple NATs as well.
(I'm still talking in the context of our DT). 

  > installation, but do you really think they are blocking issues?

=> I don't know if they are blocking or not (an operator would 
need to answer that), but having to deploy IPv4 NATs certainly 
seems redundant and does not make anything simpler than deploying 
an IPv6 network with translators.

  > NAT should deploy IPv6 side-by-side with the current IPv4 NAT

=> If they have it already, yes, I agree, but that was not 
my point. Even if they already have IPv4 infrastructure
without NATs but forecast to need more IPv4 addresses in
future, I don't see the need to force them to deploy
v4 NATs.

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 23 Sep 2002 23:51:44 +0200

I can't agree more. 

Hesham

  > -----Original Message-----
  > From: Tony Hain [mailto:[email-masked]]
  > Sent: Monday, September 23, 2002 11:43 PM
  > To: 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun Hagino'; 'Margaret
  > Wasserman'
  > Cc: [email-masked]
  > Subject: RE: ocean: do not boil
  > 
  > 
  > This was the primary reason I stressed that ngtrans needed 
  > to focus on
  > the dual stack approach first. Even though that is a much simpler
  > approach, there have been a variety of situations exposed 
  > over time to
  > show that it simply not possible for everyone to take the 
  > easy road. The
  > most obvious case at the moment is the substantial deployment of
  > IPv4-only NAT CPE that for financial reasons *will not be upgraded*
  > until the ISP is ready to provide native IPv6 support (in 
  > North America
  > that is looking like ~2006, or in the case of docsis devices much
  > later). For those end sites that want to move sooner, and 
  > don't have a
  > reasonable option for an alternate ISP, just saying we only 
  > support dual
  > stack is telling them they can't use IPv6 capable apps & 
  > appliances for
  > at least 5 years. This will in turn put a damper on the app 
  > development
  > community, because to get their app deployed in that 
  > timeframe they will
  > have to figure out how to do nat traversal. Once they have gone down
  > that path, where do they find additional incentive to put in IPv6
  > support? 
  > 
  > Yes the alternative tools add complexity, but in the grand scheme of
  > things, is that complexity less than the mess we would end 
  > up with if
  > everyone came up with their own nat traversal schemes? I 
  > think it is,
  > and that we need more than dual stack.
  > 
  > Also, as a meta point, declaring an approach for transition 
  > out of scope
  > before the scenario documents are done is just a bit short sighted.
  > Indeed there are a few ISPs deploying native service today, 
  > and these
  > will simplify the global transition. To extrapolate from 
  > there that dual
  > stack is all we need is really doing a disservice to the 
  > entire effort
  > to make the transition as smooth as possible for the end 
  > site. Just as
  > there is no single network design that works for all sites, 
  > there is no
  > single transition approach that will work universally. 
  > Before deciding
  > what problem doesn't need to be solved, why don't we get 
  > working group
  > consensus on the problems that the design teams are trying 
  > to describe
  > to see what they believe (due to first-hand experience or customer
  > feedback) are the real problems existing networks will face 
  > as they try
  > to move.
  > 
  > Tony
  > 
  > 
  > 
  > > -----Original Message-----
  > > From: [email-masked] 
  > > [mailto:[email-masked]] On Behalf Of Randy Bush
  > > Sent: Saturday, September 21, 2002 6:34 AM
  > > To: Bob Fink; Jun-ichiro itojun Hagino; Margaret Wasserman
  > > Cc: [email-masked]
  > > Subject: ocean: do not boil
  > > 
  > > 
  > > first, thanks for doing a great job in sunnyvale.  i think it 
  > > was worth the effort and pains.  of course, time will tell, 
  > > as we see how the scenarios flesh out.
  > > 
  > > but, i have been rather worried by one vector.  
  > > 
  > > i don't think we should try to solve the problem of an 
  > > arbitrary user/service on a pure v6 site/host trying to 
  > > communicate with a user/service on a pure v4 site/host or 
  > vice versa.
  > > 
  > > dns is critical infrastructure, and we need to understand how 
  > > everyone will see the same namespace whether they are on v4 
  > > or v6 transport [0].  and we have some clues on how to do 
  > > that, point mono-stack resolvers at dual-stack caching servers.
  > > 
  > > but services such as http, smtp, blah, blah, blah just can't 
  > > be completely transparent, and we *vastly* increase the size 
  > > of the problem if we try to make them so.
  > > 
  > > if i want my web site seen by both v4 and v6 users, then i 
  > > can connect it to v4 and v6 space and run dual stack.  in 
  > > fact, i do so today.  as v6 deploys, folk every useful site 
  > > will do so.
  > > 
  > > if i want to send mail to v4 users and i live in a pure v6 
  > > world, then i can make an arrangement with a dual-stack relay 
  > > to provide forwarding service to me.  and to receive mail, i 
  > > can just point an MX naming an A record to a dual-stack 
  > > forwarding service.
  > > 
  > > if i want to play a net.game which is in v6-land, then i need 
  > > to be at least partially in v6-land.  no magic.  tough patooties.
  > > 
  > > trying to make pure v4 sites/hosts communicate for arbitrary 
  > > services with pure v6 sites/hosts and vice verse is a nice 
  > > way to make the problem vastly more complicated, the 
  > > solutions vastly more complex, and the net much less 
  > > reliable.  let's not go there.
  > > 
  > > randy
  > > 
  > > ---
  > > 
  > > [0] - if you're in private v6 space, i.e. site local or other
  > >       1918-envy games, use multiple views just as a v4 1918 site
  > >       does today.
  > > 
  > > 
  > 
  >

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 24 Sep 2002 01:08:39 -0400

I agree with Tony too.
/jim

> From: Hesham Soliman (EAB) [mailto:[email-masked]]
> Sent: Monday, September 23, 2002 5:52 PM
> To: [email-masked]'; 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun
> Hagino'; 'Margaret Wasserman'
> Cc: [email-masked]

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 24 Sep 2002 01:10:19 -0400

Margaret,

You keep saying trim down the scenarios.  That could be the last thing we want.

/jim

> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Monday, September 23, 2002 6:13 PM
> To: [email-masked]
> Cc: 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun Hagino';
> [email-masked]
> Hi Tony,
> >The most obvious case at the moment is the substantial deployment of
> >at least 5 years.
> I'm not sure how this follows from Randy's comments...
> 
> If a node in the end site wants to access an IPv6-only 
> service, the user
> would need to install IPv6 on that node (or buy a new appliance with
> IPv6 included, etc.).  If the IPv6 infrastructure isn't 
> present to route
> IPv6 natively, then they might use one of our several 
> tunneling mechanisms
> to tunnel the packet over the IPv4 infrastructure to an IPv6 network.
> 
> I actually think that we were discussing some prioritization of the
> scenarios, not declaring any of the solutions in or out of scope.
> 
> Once we have a full set of scenarios, I think it will make sense to
> try to trim down the set of scenarios, based on what we think is most
> likely to occur.
> 
> Margaret
> 
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 24 Sep 2002 01:12:04 -0400

yes why artificially limit the working set?  

/jim

> Sent: Monday, September 23, 2002 9:17 PM
> To: 'Margaret Wasserman'
> Margaret Wasserman wrote:
> > Hi Tony,
> > 
> > >reasonable option for an alternate ISP, just saying we 
> only support 
> > >dual stack is telling them they can't use IPv6 capable apps & 
> > >appliances for at least 5 years.
> > 
> >> if i want my web site seen by both v4 and v6 users, then i can
> connect 
> >> it to v4 and v6 space and run dual stack.  in fact, i do 
> so today.  
> >> as v6 deploys, folk every useful site will do so.
> 
> Asserts that if a content site wants to be seen as IPv6 that it is in
> control and can just advertise that and all IPv6-only nodes 
> will be able
> to reach it. The reality is that a consumer behind an 
> IPv4-only NAT CPE
> will need some form of IPv6-over-foo to get past the CPE. The 
> hidden and
> invalid assumption in Randy's comment is that the IPv6 network is
> contiguous. 
> 
> 
> > 
> > service, the user would need to install IPv6 on that node (or 
> > buy a new appliance with IPv6 included, etc.).  If the IPv6 
> > infrastructure isn't present to route IPv6 natively, then 
> > they might use one of our several tunneling mechanisms to 
> > tunnel the packet over the IPv4 infrastructure to an IPv6 network.
> 
> This is specifically what Randy's note was asserting, that we 
> don't need
> the complexity that the mechanisms bring to the table. 
> 
> > 
> > >Also, as a meta point, declaring an approach for transition out of 
> > >scope before the scenario documents are done is just a bit short 
> > >sighted.
> > 
> > I actually think that we were discussing some prioritization 
> > of the scenarios, not declaring any of the solutions in or 
> > out of scope.
> 
> >> trying to make pure v4 sites/hosts communicate for 
> arbitrary services
> with pure 
> >> v6 sites/hosts and vice verse is a nice way to make the problem
> vastly more
> >> complicated, the solutions vastly more complex, and the 
> net much less
> reliable.
> >> let's not go there.
> 
> Sounds like precluding a class of transition scenarios to me.
> 
> > 
> > Once we have a full set of scenarios, I think it will make 
> > sense to try to trim down the set of scenarios, based on what 
> > we think is most likely to occur.
> > 
> 
> This is absolutely silly. The whole exercise is designed to refocus on
> the scenarios that are actively being deployed, or currently on the
> drawing board for deployment. Claiming that we can out guess 
> the market
> acceptance of those and whittle that down further presumes access to a
> crystal ball I haven't seen yet. Prioritizing based on relative broad
> applicability would make sense if there were limited resources, but we
> seem to have plenty of interested participants. Developing them in
> parallel doesn't appear to be a problem, so why artificially restrict
> the working set? 
> 
> Tony
> 
> 
> > Margaret
> > 
> > 
> 
> 
>

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 24 Sep 2002 13:36:10 +0200

> >   > p2p applications can be designed to use intermediaries,
  > >   > just like SMTP and HTTP. If I was designing an apps
  > >   > protocol today, I would definitely make sure it could
  > >   > be relayed between address spaces at applications level.
  > > 
  > > => Are we in a position to mandate this?
  > > 
  > 
  > This is the Internet, so no. But we (or if we were lucky the IAB)
  > could make an architectural recommendation.

=> Well, we can recommend, but I don't think 
we can _assume_ that things will be done the way
we recommend them. Especially when we're talking 
about applications. I know many application developers
that don't know what v6ops is. It'll be hard to get 
this message to everyone so well that we can assume 
it will be followed.

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 24 Sep 2002 17:43:41 +0200

> >   > We're not in a position to _mandate_ anything.  
  > However, we are
  > >   > in a position to make recommendations about the best 
  > way to resolve
  > >   > certain scenarios.
  > > 
  > > => I'm not trying to be -ve, but unless we mandate
  > > that all applications will use this model, or alternatively
  > > assume that HTTP and SMTP are the only important applications
  > > for the medium term there is no point eliminating the
  > > v6 -> v4 scenarios.
  > 
  > I didn't suggest eliminating them. But since they will be even worse
  > to manage than IPv4 NAT, we should use them only when forced to.

=> I fully agree that this is something that should
only be used/deployed if people are forced to do
it. Translators in general are not pretty and don't
make life simpler, but are necessary sometimes. 
What I'm not sure about is whether running a dual
network containing IPv6 (global) and IPv4 private addresses
is simpler than just running an IPv6 network with 
v6 <=> v4 translators. 

Hesham

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 24 Sep 2002 12:08:58 -0400

Hi Hesham,

>=> I'm not trying to be -ve,

I'm not sure what "-ve" means, but I'm certain that you
aren't trying to be it :-).

>but unless we mandate

Which model?  All widely deployed IPv4 applications work with
the existing IPv4 model.  If that model continues to be the way
to reach IPv4 services (as I have suggested), there wouldn't
be any need to change existing IPv4 services.

>Clearly (at least to me), it would be pointless to start
>making "recommendation for application layer protocol
>developers" in this group. This _is_ boiling the
>ocean IMHO.

I agree.  Requiring a application-layer proxy for each type
of application is not desirable.

>   > We can suggest any one of these solutions, and people are,
>   > of course,
>   > entitled to ignore us.  Given the choice between these
>   > three, though,
>   > the third one seems simpler
>
>=> Can you please explain why it is "simpler" ?

In my opinion, the use of parallel IPv4 and IPv6 infrastructure
is simpler than IPv4<->IPv6 translation, because it doesn't
require special support from the DNS system (either servers or
resolvers), doesn't require injection of routes for special
IPv6 address prefixes, and doesn't, inherently, require any
translation.

Now, it is true that the IPv4 infrastructure may include a
NAT.  But, even in those cases, the parallel use of IPv4 avoids
complexity in the DNS and routing tables.

>and less prone to introducing new
>   > architectural and application-level issues,
>
>=> What does this mean?`what architectural issues
>are reduced by v4 NATs?

The use of parallel IPv4 and IPv6 infrastructure, even with
the use of IPv4 NATs, does not introduce any _new_
architectural issues.  Yes, there are some major architectural
issues with IPv4 NATs, but these issues are not new, and IPv4
applications have already been modified/limited to work within
this type of environment.

>since the IPv4
>   > infrastructure
>   > would be exactly the same as what many people are using today.
>
>=> Margaret, please consider my concern: I am not talking
>about networks with _existing_ IPv4 infrastructures/NATs.
>I hope my intention is clear. I know that many  ISPs
>already have v4 NATs and this is not the case I'm bringing
>up.

Yes, I understand this, Hesham.

But, I really do think that it would be wiser for a networ
operator to install parallel IPv4 and IPv6 infrastructure in a
new installation, if any of the nodes on their network will
need to access IPv4-only services.

Installing an IPv4 NAT and DHCP server won't be any harder than
installing a v4<->v6 translator with DNS and routing tie-ins.  You
won't need any more IPv4 addresses than you do in a v4<->v6
translation model (you will always need a v4 address to access
a v4 service), and using a "normal" (by today's standards)
IPv4 infrastructure will result in fewer problems accessing
IPv4 applications and services.

What am I missing?

Margaret

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 24 Sep 2002 20:36:32 +0200

> aren't trying to be it :-).

=> Good!

  > the existing IPv4 model.  

=> see below.

If that model continues to be the way
  > of application is not desirable.

=> ok, that's what I was referring too above ("the model"
suggested in an earlier email)

  > IPv6 address prefixes, and doesn't, inherently, require any

=> Depending on the solution you choose there might
not be any special addresses or special routing.
In fact, regardless of the model you choose I don't
see the need for any special routing. Translation
is already there, whether it's a v4 NAT or a NAT-PT.
The scalability issue is also there regardless.
What you mention about the DNS issues is valid, but
this kind of "simplicity" (of removing the DNS issues)
is not necessarily operationally simpler when compared
to running IPv4 NATs. Any operator can jump in about 
now and tell us what they think.

  > complexity in the DNS and routing tables.

=> I don't understand what complexity is there with
the routing tables.

  > IPv4 applications and services.

=> I don't exactly think one of us is missing 
something (except that I don't think there are
any routing issues here, unless running a dual
network involves more management of the routing 
infrastructure). I think the issue here is a matter
of assumptions. You assume that it's ok to tell a 
new operator in china or anywhere that to deploy
their new IPv6 network they need to buy and run
an IPv4 private network (well, buy the NATs anyway). I assume 
that they would rather not do that and that this extra 
infrastructure is redundant.

I also think that simplicities you mention (regarding
the DNS)are simpler for us (IETF people), but I'm not
sure that operationally it will be simpler for people
to buy and run a dual network, especially when they 
don't need it. 

I'm not pushing for NAT-PT/SIIT deployment everywhere,
but my preferences for a new operator are:

1. Run a dual stack network with public addresses
2. If public addresses are not possible (for v4)
   then just run a v6 network.

Hesham

PS: I think this discussion is a proof that we
need to get more operators involved and more 
discussions before we eliminate anything.

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 25 Sep 2002 07:42:11 +0200

> 	"10 million subscriber" scenario is nontrivial by nature.
  > 
  > 	for (a), 10.0.0.0/8 space only servers 17 million subscribers
  > 	(theoretical maximum), and since address alloation 
  > efficiency is not
  > 	that good, you can't have a single NAT cloud.  you need to split
  > 	customers into multiple NAT clouds (also I don't think 
  > any single
  > 	NAT box can take traffic from 10 million subscribers).
  > 
  > 	even for (b), I don't think single NAT-PT box (Alain, 
  > forget about
  > 	DNSSEC for now) can take traffic from 10 million 
  > subscribers, so we
  > 	at least need to split NAT-PT load to multiple NAT-PT 
  > box somehow.
  > 	(i assume the customers will want to use IPv4-only 
  > yahoo.com.cn, right?)
  > 
  > 	so if we need to take a pick, it is between (a) IPv4 
  > multiple NAT cloudm	and global IPv6, or (b) global IPv6 and 
  > multiple NAT-PT.

=> Fully agree. But there is a big difference:
The multiple NAT-PT cloud will not having overlapping
addresses, which makes for a simpler routing.

Hesham

  > itojun

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 25 Sep 2002 02:18:25 -0400

Who is we?  First Bank of USA, GM, AB Germany, Worldcom?  I can't follow what "we" your referring to so I can respond?  I am sure you don't me v6ops an IETF working group?  We are not running a network?  We have folks who build, run, deploy, them but for who?

/jim

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, September 24, 2002 11:15 AM
> To: Hesham Soliman (EAB)
> Cc: 'Margaret Wasserman'; 'Bob Hinden'; Randy Bush; Bob Fink; 
> Jun-ichiro
> itojun Hagino; [email-masked]
> Subject: Re: ocean: do not boil
> 
> 
> "Hesham Soliman (EAB)" wrote:
> > 
> >   >
> >   > We're not in a position to _mandate_ anything.  However, we are
>    Brian

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 25 Sep 2002 02:22:50 -0400

We should not declare either.  It is not IMO the working groups job to tell user how to deploy.  One user will want to use NAT and the other will want to use DS.  Our job is to make sure both are understood and the end results from both.  This will truly help the user decide maybe.  If we declare a specific mechanism as PS then we need to make sure it has no known protocol technical deficiencies.  Then we have done our job.  Anything else is absurd and borders on pure egomania.

/jim

> Sent: Tuesday, September 24, 2002 11:44 AM
> To: 'Brian E Carpenter'

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 25 Sep 2002 02:45:11 -0400

Tony,

Also add the commerical Intranets deploying IPv6.  They will not have the same needs and in some cases far different needs than ISPs.  If that is out of scope we need to support that elswhere than v6ops for transition.  If that is the case we should declare that now.  That would mean we don't care about the Enterprise too.  Important assumptions and view points to bring up.  Thanks for doing that.

/jim

> Sent: Tuesday, September 24, 2002 7:20 PM
> To: 'Randy Bush'
> Cc: [email-masked]
> Randy Bush wrote:
> > > So all content sites are held hostage until their ISP gets 
> > around to 
> > > providing IPv6 service...
> > 
> > nice hyperventilation.  but if you'll look at the beginning 
> > of this thread, the basic idea is that we should not try to 
> > provide v4<->v6 access to *all* services.  in fact, i listed 
> > the service(s) which _must_ be interoperable.
> > 
> 
> So we should provide application proxies for the services that we know
> work through IPv4 NAT. More to the point though, the *only* 
> services we
> should be worried about are the ones that are important to ISPs. If it
> is useful to an end site, but not to an ISP it doesn't matter. 
> 
> > >> a content site is not a 'consumer'.  they are provdng a
> > >> servce.  if they want to provide the service, they need 
> > >> things like mains power, the appropriate ip service(s), etc.
> > > This model precludes any consumer from providing content. 
> > Specifically 
> > > it precludes any peer-to-peer applications. I realize that 
> > many ISPs 
> > > currently don't like the idea of a consumer hosting 
> personal web or 
> > > mail services, but their business practice should not have 
> > any impact 
> > > on the range of technology standards we are developing.
> > 
> > no, but nice emotional appeal.  those evil isps just won't 
> > let good red-blooded amurikans do anything.  we should put 
> > them in jail.
> > 
> > it merely says that when you decide to provide a service you 
> > must have the tools to provide it.  if you want to provide 
> > email service, you need smtp, not http.  if you want folk to 
> > access your server over tv, you need to put it on a tv 
> > service.  if you want it on v4, you need to put it on v4.  
> > same for v6.
> 
> So now I am confused. Is the tool set we defined for providing IPv6
> service, even when intermediate ISPs do not, in scope or out? How does
> the end node know when the IPv6 service it sees is based on a real
> underlying ISP service, or is simply a translated service? Outside of
> NAT application issues, why should it know if the service is live or
> translated?
> 
> > 
> > > I can understand the desire to sort and prioritize to 
> > manage resource 
> > > constraints, but at the moment I see an abundance of people 
> > willing to 
> > > work on the problems.
> > 
> > there is an abundance of people willing to make careers at 
> > making a complex world to try to put marketing whitewash on 
> > the fact that it is still hard to have a merged v4/v6 
> > infrastructure because
> >   o few vendors make the hardware
> >   o there is no motivation to move to v6
> > 
> > it's like the failing sales force going back to engineering 
> > for an endless list of features which they hope will sell the 
> > product. a good recipe for turning a failing sales force into 
> > a failing company.  
> > 
> > but this is the engineering department, and our task is to do 
> > our job prudently and properly.  we need to make sure that 
> > the *basic* and *critical* things needed to operate v6 in a 
> > v4 world can be done, and done reliably and scalably.
> 
> Fine, but this didn't answer where the constrained resource is, and
> there appear to be different viewpoints on what the scope of the IPv4
> world is. If the scope of the working group is restricted to 
> only those
> things that are critical for an ISP to deploy service, we 
> will be seeing
> a much longer transition period, and possibly an outright 
> failure to get
> IPv6 deployed. If on the other hand the IPv4 world includes the edge
> sites, we have a much larger set of tools that are basic and critical.
> In particular for those sites who have had requests for public IPv4
> address space turned down so they decide to go straight to 
> IPv6 to avoid
> a messy 1918/nat deployment & transition, are they restricted 
> to web and
> mail proxies? 
> 
> Tony 
> 
> 
> 
> > 
> > randy
> > 
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 25 Sep 2002 03:11:40 -0400

I inherently agree with avoiding NAT (that is what DSTM is all about).  But I would like to hear discussion on Tony's mail to Rob.  I think we have a serious issue to reach a group resolution on here and Tony has stated it very well.  I believe we need to work on NAT and will work on it even though I don't like it and will avoid recommending it to any user I have to support.  But I don't like what I am hearing from some here nor that all we care about are ISPs which is what I think I am hearing from some.

Why is it some are saying "don't do as I do but do as I say".  We were told that we needed the scenarios (and ISP is only one of them) to complete analysis.  Yet I am hearing same proponents tell us we should select a default before we have them all worked out?

This is not good folks.  Or maybe I am missing intentions or assumptions?

/jim

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2002 1:36 AM
> To: Hesham Soliman (EAB)
> Cc: [email-masked]
> >=> I think we're drifting from the main issue 
> >a little bit. Here is a scenario that I'd like
> >to understand how it would work:
> >What do we recommend a new small 3g operator who only
> >has 10 million subscribers (just a small town
> >in china!) and wants to allow people to run p2p apps:
> >
> >a. Run a dual network with 1918 addresses
> >b. Just run an IPv6 network
> >
> >If people want to do a), do you really think
> >this would be simpler than b) ? Easier to manage
> >and operate? 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 25 Sep 2002 10:26:38 -0400

I agree in context usually.  What I am saying is that users in this case cannot be told to use relays.  Some may listen and some may not.  Those that don't will ignore it.

And I am not convinced we should be building relays in the IETF but I see your point.

/jim

> From: Keith Moore [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2002 5:24 AM
> To: Bound, Jim
> Cc: Brian E Carpenter; Keith Moore; Hesham Soliman (EAB); Bob Hinden;
> Margaret Wasserman; Randy Bush; Bob Fink; Jun-ichiro itojun Hagino;
> [email-masked]
> > If the v6ops even try to address this they are going to not be 
> > listened too.  Its none of the IETFs business.
> 
> oh, that's silly.  developing mechanisms to allow apps to 
> cope with a mixture
> of v4 and v6 is certainly within IETF's business.
> 
> the reason it won't be listened to is because having apps do 
> their own addressing
> and routing is simply too difficult for most implementors.    
> it will be easier to 
> arrange for v6 everywhere (by shipping 6to4 and/or Teredo 
> drivers with the app)
> than to build ad hoc networks at layer 7.
> 
> 
> Keith
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 25 Sep 2002 10:40:21 -0400

Hmmmm.  This is important assumption discussion.

> From: Randy Bush [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2002 10:17 AM
> To: Bound, Jim
> Cc: Margaret Wasserman; Hesham Soliman (EAB); Brian E Carpenter; Bob
> Hinden; Bob Fink; Jun-ichiro itojun Hagino; [email-masked]
> > The piece that I think your missing is pretty simple 
> really.  The customer
> > does not want a parallel IPv4 infrastructure and wants it 
> removed as soon
> > as possible.
> 
> hypothesis: the customer does not care.  they just want to get their
> job done.

Don't agree.  This is similar in engineering when architects tell me customers did not hire Computer Science or Software Engineering personnel that are capable of making very hard networking decisions and analysis for the enterprise.  Many customer sites do have operation expertise and engineering expertise and do develop their own visions, strategies, etc about how they approach a large networking problem like IPv6.
I have personally heard of customers telling me they believe it cheaper to kill off IPv4 as soon as possible.

I think there are many customers that have this hypothesis.  I go back to what Tony said we need to permit work and drive work that helps many customers.

I don't know how many either way and cannot say.  I am saying this case does exist.

> 
> anecdotal evidence: the low adoption rate of any of this stuff.

A lot of that now is the economy and the Internet bubble having burst.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 26 Sep 2002 04:03:57 -0400

Thats fine I suspected you did not.  Thats why we all come here to share our views and do work. 

/jim

> Sent: Wednesday, September 25, 2002 10:43 PM
> To: Bound, Jim
> Cc: [email-masked]
> 	in almost all of the installation of IPv6, they run 
> IPv4 and IPv6 in
> 	parallel - usually IPv4 is NATed, and IPv6 is globally reachable
> 	(sometimes IPv6 filtering device is in place).  i don't 
> share your
> 	view on this aspect on customer demand.
> 
> itojun
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 26 Sep 2002 04:05:26 -0400

for me it is demand.  or the customer is always right.  We will need
multiple solutions to resolve multiple demands.  I don't see necessity
as principle from my view at all.

/jim

> From: Stewart Tansley [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2002 11:11 PM
> To: [email-masked]; Bound, Jim
> Cc: [email-masked]
> Is it demand, or is it necessity.
> 
> Stewart.
> 
> > Sent: Wednesday, September 25, 2002 7:43 PM
> > To: Bound, Jim
> > Cc: [email-masked]
> really.  The 
> > >> customer does not want a parallel IPv4 infrastructure 
> and wants it 
> > >> removed as soon as possible.
> >

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 26 Sep 2002 13:36:42 +0200

> 
  > Please note that both solutions require IPv4 service at the 
  > translation
  > point, including at least one globally routable IPv4 address.
  > 
  > Once the network has been set-up, these two choices 
  > _should_ work the
  > same for IPv4 traffic sent outside the site.  However, there are a
  > few of key differences:
  > 
  >          - The IPv4 NAT solution supports the use of IPv4-only
  >                  services within the site, whereas NAT-PT only
  >                  supports IPv4 communication with the outside (there
  >                  is no internal IPv4 routing).
  > 
  >          - The NAT-PT solution does not require running a 
  > DHCP server
  >                  or assigning private IPv4 prefixes to 
  > internal networks.
  > 
  >          - The NAT-PT solution involves changes to DNS (either to
  >                  resolver on each host, or to the server), 
  > and the IPv4
  >                  NAT solution does not.
  > 
  > Are there some other technical advantages to the NAT-PT 
  > solution that I
  > am missing?
  > 

=> Are nodes inside the network capable of communicating
with each other using IPv4? I don't think that would
be possible.
Also, and if the different private address clouds are
not physically separated then we end up with
having overlapping IPv4 address spaces. This will mean
that operators need to use BGP-based MPLS vpns (eek), virtual
routers ...etc. which is definitely a disadvantage to
the v4 NAT solution.
This situation could happen if the operator starts 
with a large network or when they expand an existing 
network. Could be very messy.

The only way to go around that would be to assume that
_all_ hosts inside the network will have v6 enabled and 
can communicate using v6. I.e. no v4 only devices in the 
network. This is probably unrealistic, especially in a public
access network. 

  > How will hosts know that they are running in a NAT-PT environment,
  > and that they shouldn't send IPv4 traffic?  

=> This is part of the NAT-PT solution, whether you
use DNS ALG in the network or modify the client's
resolver this would work fine. It doesn't need 
to be a mapped address. If the DNS ALG is in the
network then it can be any IPv6 unicast prefix.
If the client's resolver is changed it can also be 
any prefix, but in this case it has to be a "well known"
prefix. A mapped prefix would work fine.

  > Who has explored this in detail, and what did you find?

=> Alain's draft addresses this. I've also explored 
an alternative that I presented in the DT. This involved
having a DNS ALG in the network. 
The advantage of Alain's altrnative is that it allows 
DNSSEC in the client's resolver (as opposed to being 
verfied in the operator's DNS). The advantage of having
the DNS ALG in the network is that we don't have to change
(or guarantee changing) resolvers in all clients. 

There are other pros and cons related to how equally
a load can be distributed between the translators but 
the DNSSEC was the most significant difference. 

I don't know if v4 NATs can be distributed for load 
sharing and I haven't looked into that, I'd be interested
in a pointer though if someone else studied it.

Hesham

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 26 Sep 2002 08:55:20 -0400

Margaret,

> Sent: Thursday, September 26, 2002 4:52 AM
> To: Bound, Jim
> Cc: [email-masked]; Stewart Tansley; [email-masked]
> At 04:07 AM 9/26/02, Bound, Jim wrote:
> >every input I get is that they don't want NAT and want it to 
> go away as 
> >soon as possible.
> 
> To be replaced by NAT-PT?

No.

> 
> What is the technical advantage to running an IPv6-only 
> internal network
> that uses NAT-PT to reach external IPv4-only services, as 
> opposed to running
> a shared IPv4/IPv6 network with IPv4 NAT?

None.

> 
> [Please give _technical_ reasons, like X works with NAT-PT, 
> but doesn't
> work with IPv4 NAT...  I understand that some folks have 
> emotional/marketing/
> other reasons for wanting to use something they think of as 
> "pure IPv6", and
> we may need to deal with that attitude in the marketplace.  
> I'd just like to
> put that aside for a moment and understand the technical 
> differences between
> these two solutions.]

Another solution is to use DSTM to avoid using NAT-PT.  Which is technically a different solution.

> 
> I've been thinking about this a lot, and I have come up with 
> the following
> thoughts:
> 
> Network set-up is fairly similar in these two cases:
> 
>          - An IPv4/IPv6 network with IPv4 NAT requires:
>                  - Setting up an IPv4 NAT box(es).  This includes
>                          providing at least one globally routable
>                          IPv4 address (to use as the source address
>                          for translated packets).
>                  - Configuring routers with IPv4 and IPv6
>                          prefixes and default routes,
>                          including IPv4 default routes
>                          that lead out through the NAT box(es)
>                  - Setting up an IPv4 DHCP server
>                  - Running dual-stack hosts and routers
> 
>          - An IPv6-only network with NAT-PT requires:
>                  - Setting up a NAT-PT box(es).  This includes
>                          providing at least one globally routable
>                          IPv4 address (to use as the source address
>                          for translated packets).
>                  - Configuring routers with IPv6 prefixes and default
>                          routes, plus static routes to send traffic
>                          addressed to IPv4 mapped addresses 
> out through
>                          the NAT-PT box(es)
>                  - Running special DNS resolver code on the 
> hosts and/or
>                          configuring DNS servers to return 
> AAAA IPv4 mapped
>                          addresses for any A records.
> 
> Once the network has been set-up, these two choices _should_ work the
>          - The NAT-PT solution does not require running a DHCP server
> and that they shouldn't send IPv4 traffic?  Will they default to
> using IPv4-mapped addresses whenever they don't have IPv4 addresses
> configured?  What would be the implications of this behaviour
> (if any) in the event of a DHCP failure on an IPv4-only or IPv4/IPv6
> network that is running these same implementations?
> 
> Is the routing set-up necessary to support multiple NAT-PT boxes the
> same as the routing set-up needed to support multiple IPv4 NATs?  What
> are the key differences, if any?
> 
> I am concerned about the DNS modifications needed to make NAT-PT work
> correctly.  We know that applications that currently work behind an
> IPv4 NAT will work properly with the IPv4 NAT choice.  Are we _sure_
> that all of those applications will work properly in the NAT-PT case?
> BTW, I think it is _very_ appropriate for the working group to be
> analyzing different solution choices at this point.  Two of 
> our scenario
> documents are nearly complete (3GPP and unmanaged) and work is already
> underway on the analysis documents.  Those analysis documents will
> contain our recommended solutions for different scenarios, so it
> makes perfect sense for us to discuss which solutions we will
> recommend and why.

This can be completely avoided when users have a large pool of IPv4 address space or can use private IPv4 address space with DSTM and then NAT-PT is NOT required.

NAT-PT breaks end-2-end security and apps just like NAT in IPv4.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 26 Sep 2002 23:06:04 -0400

yes.  this would be a cost for a network wanting to do this they would have to weigh against other approaches.  This is the kind of metric I think we need to record for each mechanism.

/jim

> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Thursday, September 26, 2002 10:16 AM
> To: Keith Moore
> Cc: Margaret Wasserman; Bound, Jim; [email-masked]; 
> Stewart Tansley;
> [email-masked]
> > it's a tradeoff - NAT-PT is probably slightly less 
> functional to apps (will 
> > cause a few more apps to break than NATs do) but in 
> exchange for using it
> > you get to get rid of all IPv4 traffic on your local network.
> 
> But you can get rid of the local IPv4 traffic (i.e. no need 
> to configure 
> local IPv4 routing) by tunneling IPv4 in IPv6 locally and 
> using the DSTM
> DHCP options for getting such tunnels configured.
> 
> This requires implementing more stuff on the nodes, and it adds
> tunneling overhead on the wire.
> 
>   Erik
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 26 Sep 2002 23:07:25 -0400

yes yes yes yes.  

And add the Cost and our best guess performance factor to it as a matrix as in mail I sent the other day.  this would be highly useful to operators and users planning v6 networks too.

/jim

> Sent: Thursday, September 26, 2002 10:20 AM
> To: Erik Nordmark
> Cc: Keith Moore; Margaret Wasserman; Bound, Jim; [email-masked];
> Stewart Tansley; [email-masked]
> yes you can, and this makes far more sense to me than using NAT-PT.  
> in most cases tunneling seems far better than messing with DNS.
> 
> it would be interesting to see all of these scenarios 
> compared side-by-side.
> 
> Keith
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 26 Sep 2002 23:14:04 -0400

Hi Bechet,

What I hear and see in the planning of ipv6 with customers is they are doing everything they can to avoid the use of NAT with IPv6.  But as Erik stated I also hear they are very worried about tunneling overhead and tunneling adds its own form of managed cost.
In the case of DSTM or ISATAP they have told me it MUST be implemented transparently to them.  But the pain from NAT is the loss of end-2-end and that is what I hear as the driving factor for them moving to ipv6 when they exist with current NAT.

Now users who don't use NAT or who were duped into using it for security (this is too bad really but it happened) they have different view as network planners.  What they would like to do is not have to suddenly use NAT when they now deploy IPv6.  This seems illogical to them.

I think if we continue the discussion of the issues of a parallel v4 with v6 and tunnels or nats within the matrix of that we can provide at least a close set of results for different network definition behaviors.

This will also as a note help implementors like me build this as transparently as possible and choose which ones to do first.  This is selfish need on my part clearly.

/jim

> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Thursday, September 26, 2002 10:59 AM
> To: Bound, Jim
> Cc: [email-masked]
> Hi Jim,
> Bound, Jim wrote:
> go away as soon as possible.  for "some" (I say some) I am 
> being told how fast can I get rid of IPv4 period at least on 
> my site.  that "some" is as important as the Lowest Common 
> Denominator or one size fits all view to me as an engineer.
> >  
> >
> 
> I would like to hope that you are right (and are in line with the 
> operators and enterprises). For Keith, I understand, in academia one 
> wants the latest.
> What are the views then on the issue of IPv6 NATs?
> 
> >/jim
> >
> >  
> >
> 
> --behcet
> 
> >>    
> >>
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 26 Sep 2002 23:21:17 -0400

Just as a note this is one of the benefits stated in DSTM and objective.  IPv6 becomes the dominant protocol.  

/jim

> From: Senthil Sivakumar [mailto:[email-masked]]
> Sent: Thursday, September 26, 2002 2:42 PM
> To: Margaret Wasserman
> Cc: Keith Moore; Bound, Jim; [email-masked]; Stewart Tansley;
> [email-masked]
> On Thu, 26 Sep 2002, Margaret Wasserman wrote:
> 
> >
> >
> > What is the advantage of getting rid of all IPv4 traffic on 
> the local
> > network, since it will just be replaced with translated 
> IPv6 traffic?
> >
> You dont have to run IPv4 routing protocols along with IPv6 routing
> protocols, which IMO, is an operational advantage.
> 
> Senthil
> > Margaret
> >
> >
> >
> >
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 26 Sep 2002 23:45:26 -0400

I was thinking Grizzly Bears as they do it quickly so it dont hurt :--)
/jim

> Sent: Thursday, September 26, 2002 11:05 PM
> To: Bound, Jim
> Cc: Keith Moore; [email-masked]; Stewart Tansley; 
> [email-masked]
> > what I am concerned about is that we don't have mechanisms 
> > for those who want to not do nat at all.
> 
> that's a rather odd statement, or at least I don't understand it.
> surely we have such mechanisms in native v4 and native v6?
> 
> the only legitimate reason to use nat is to compensate for a shortage
> of IPv4 addresses.  if a site can get enough IPv4 addresses to not
> use NAT for v4, or if the site can avoid using v4 altogether, it 
> should never need to use a NAT.
> 
> and anyone who makes a NAT for v6 should be fed to piranha fish.
> 
> Keith
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 27 Sep 2002 00:00:33 -0400

agree completely.  I completely support defining the lowest common denominators for sure.  I just don't think that should preclude discussion on other tools and topics thats all.  I can operate in a multi-threaded manner :--)

/jim

> Sent: Thursday, September 26, 2002 11:52 PM
> To: Bound, Jim
> Cc: Keith Moore; Margaret Wasserman; [email-masked]; 
> Stewart Tansley;
> [email-masked]
> I do think we will need a variety of transition tools because 
> not everyone's
> transition scenario will be the same.  At the same time, some 
> of the tools
> we have seem clearly superior and more widely applicable to others
> that cover (some of) the same spaces.  So it would be good if we could
> identify some of the less useful tools and/or concentrate on the more 
> useful tools and any missing pieces that are identified.
>

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 29 Sep 2002 20:55:09 -0400

Hi Hesham,

>this would be simpler than b) ? Easier to manage

I've been thinking about this question and trying to
come up with a good answer...

I'm actually thinking of this question a bit differently,
so please tell me if it matches what you are asking:

What is the best way to set-up a network of 10 million
nodes that all to need access both IPv6-only and IPv4-only
services?

There are two thoughts that I have about this question:

         (1) It isn't a fully qualified question.
                 Further information is needed to
                 for a complete answer, such as:

                 - Do these nodes need continuous access
                         to IPv4 and IPv6 services, or only
                         occasional access?
                 - How many simultaneous IPv4 & IPv6
                         connections are expected?
                 - What is the planned internal structure
                         of the network?  Obviously you aren't
                         planning to bridge 10 million nodes
                         on a single subnet.

         (2) Neither IPv4 nor NAT-PT will handle a 10 million
                 node network as a single address space.
                 The limitation of 32-bit addressing in IPv4
                 is a red herring, since the real limitations
                 on the size of a NAT based network is probably
                 much lower (a few hundred thousand simultaneous
                 connection?).

But, given that you've said this is a 3GPP network, I can
make some (perhaps flawed) assumptions about how this network
will be structured:

         (1) There will be internal routers (GGSNs) at a
                 density of one per ~100,000-500,000 nodes.
         (2) All nodes will have point-to-point connections
                 to a single router (PDP Contexts to the GGSN).
         (3) The nodes will only need occasional access to
                 IPv4 & IPv6 services.
         (4) IPv4 address configuration (and IPv6 address
                 configuration) of the nodes will
                 be performed on an as-needed basis
                 via the establishment of PDP contexts.

In this case, I would suggest that any address translation
(IPv4 or IPv6) be performed on a per-GGSN basis, with the
NAT either co-resident in the GGSN or sitting directly
behind it (between the GGSN and the rest of the Internet).

So, really we are comparing two things:

         (A) The complexity, effort and effectiveness of
                 configuring the GGSNs as IPv6-only routers
                 and running a NAT-PT box per GGSN to
                 translate selected IPv6 traffic into
                 IPv4 traffic.  This would allow the end-nodes
                 to be IPv6-only, but would require them to
                 have some special DNS resolution/literal
                 IPv4 address handling mechanisms.

         (B) The complexity, effort and effectiveness of
                 configuring the GGSNs as IPv4/IPv6 routers,
                 running an IPv4 NAT box per GGSN, and
                 having the GGSNs allocate RFC 1918
                 addresses on PDP contexts.  This would
                 require any nodes that need to reach
                 IPv4-only services to include IPv4 and
                 any nodes that need to reach IPv6-only
                 services to include IPv6 (nodes that need
                 to reach both would need to be dual stack).

There are a few key differences between these choices:

Choice A has the advantage that it only requires a
single stack on the end-nodes, which may save a little
bit of memory... However, IPv4 and IPv6 stacks share a
large portion of their code, so this will be a small
savings.

Choice A only supports IPv6-only end-nodes.  It won't
be possible to set-up an IPv4 PDP context, and two nodes
that are behind the same GGSN will not be able to
establish an IPv4 connection to each other.  Is that
okay?

Choice A may also have some new (i.e. not present in
the IPv4 network today) architectural issues running
IPv4 applications caused by:

         - The DNS resolver/IP address interpretation
                 machinations on the local box.
         - The availability of IPv4<->IPv6 ALGs for
                 whatever applications the host is
                 using.

Choice B will support IPv4-only, IPv4/IPv6 dual stack
and IPv6-only nodes, will allow nodes to use IPv6 and
IPv4 PDP contexts, and will support IPv4 connections
between nodes attached to the same GGSN.  Are any of
these things needed?

Choice B will also have the best chance of supporting
all IPv4-only services that work in a NAT-based network
today.

I agree that Choice B may be marginally more complex
to set-up and maintain than Choice A...

So, there is a pretty complex trade-off here, but if
I had to choose for my own network, I'd probably go
with the dual-stack parallel IPv4/IPv6 network approach.

I wish that I really understood the DSTM/DHCP choice
well enough to explain how it could/couldn't fit into
this situation...  I'm working up to that now.

Margaret

---

From: <[email-masked]>
Date: Mon, 30 Sep 2002 00:03:24 -0700

Margaret,

That's a pretty summary.  Thanks.

Speaking only for myself, not Nokia, I'm of the
opinion that DSTM doesn't add anything to the 3GPP
equation.  It's logically equivalent to having
an IPv6 PDP context always up, and bringing up
a v4 PDP context on demand.

The v4 address you get when you bring up that
PDP context may in fact be allocated via DHCP, of
course.

		--Rod

-----Original Message-----
From: ext Margaret Wasserman [mailto:[email-masked]]
Sent: Sunday, September 29, 2002 5:55 PM
To: Hesham Soliman (EAB)
Cc: [email-masked]'; [email-masked]
Subject: RE: ocean: do not boil 

Margaret

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 30 Sep 2002 10:22:47 -0400

Hi Margaret,

The DHCP DSTM choice would work as follows:

It would assume your choice B below.
At the GGSN it would be able to forward
IPv4 packets that were encapsulated in IPv6,
when the handheld wanted to speak to IPv4 apps.
But we need to discuss 1918 address and global
IPv4 address space.

If 1918 then I would argue the only use for 
DSTM is behind the GGSN to the UE device (e.g.
local 3G provider services) or if the services from
the GGSN were within a private 1918 network then
the IPv4 packets could be used to get to those
services using 1918 addresses.  But DSTM could
also provide global Ipv4 addresses if as one of 
your questions/assumptions was that IPv4 
is needed for only temporary or limited use 
of network services.

At the UE or handheld lets assume it mostly
speaks IPv6 for IM in 3G.  When it needs 
v4 address the dhcpv6 client or a more light
weight mechanisms requests a DSTM address
(private or global) to speak IPv4.

The IPv4 address then is encaped to the 
GGSN DSTM Edge Router and then forwarded..

The GGSN DSTM router would have to send the IPv4
back thru the IPv6 core network would have to have 
a mapping of how to get back to the v6 UE/handheld via
encaping v4 in v6.

This is only useful when IPv4 is being used as limited
for services or special apps that have not been ported.
DSTM assumes strongly that v6 is the dominant deployment
strategy.  Once that happens all the e2e pain can be avoided
that one gets with NAT  and e2e security/vpns are possible
with IPv6.

Now dhcpv4 could be used but that means the handheld
is running IPv4 dhcp client.  That means its running a dual
stack for services.  DSTM does not require this and why
we put DSTM options in dhcpv6 for the case where the 
client only wants to run IPv6 and IPv4 as special operation.

The overall DSTM architecture is to avoid NAT completely
where it might be used by IPv6 nodes.

DSTM does assume that nodes are dual stacked though.

regards,
/jim

> Sent: Sunday, September 29, 2002 8:55 PM
> To: Hesham Soliman (EAB)

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 30 Sep 2002 10:32:41 -0400

Hi Hesham,

>=> I believe continuous access is needed. a PDP
>context will be up when the device is turned
>on and remain up pretty much the whole time.
>Some operators will configure things differently
>(e.g. if idle for x hours remove PDP context), but
>I believe people want to be "always on and connected"
>(not meant to be a mrketing stunt!). This is simply
>because once you lose your PDP context you're not
>reachable.

"Reachable" in what sense?  I can see this argument for
the IPv6 PDP Context, since you might run a peer-to-peer
service over IPv6 for messaging, or whatever...

But, what advantage is there to having an IPv4 PDP
Context up all of the time?  If you are behind any type
of NAT (IPv4 NAT or NAT-PT), you won't be reachable
from the outside, anyway.

>=> Depends on the user, this is orthogonal to the
>PDP context(s).

Right, but this is key to the scaling issues for any NAT
solution.  The "10 million" nodes (or 100,000-500,000 nodes)
number is much less interesting, from a NAT scaling perspective,
then the number of simultaneous communication sessions for
which the NAT box will need to maintain state.

>=> NAT-PT can handle them in a single address space. Of course
>not in a single box.

Okay, I agree.  My use of the term "address space" was not correct.
I probably should have said "address pool" or "address range".

We're in agreement, though, that a single NAT box won't be able
to handle 10 million nodes.  Given that fact, I'm not sure that it
matters whether the end-hosts behind the NATs are numbered in
different ranges of the same address space (as they could be with
NAT-PT), or in private address spaces (as with IPv4 NAT).  Both
address spaces would be private from the point of view of the
IPv4 Internet, requiring translation into globally routable IPv4
addresses.

>=> Correct.

Okay, now we're talking!  This starts to bring the problem into
a range that I understand how to solve...

>=> I think continuous accessibility is required.
>We don't want to tear down PDP contexts and start
>them again too often.

Do you know how potential 3GPP operators think about this?  I have
heard different things from different equipment manufacturers...

However, I'll accept that we want a solution that can handle
always-on IPv4 and IPv6 access to every end-node, even if that
isn't how all of the networks are deployed.

Are you willing to accept that it would probably make sense, in
the 3GPP topology to position the NATs (or either type) in or
just behind the GGSNs, rather than having a single (set of) NAT
box(es) between the full 10 million node network and the rest of
the Internet?

Margaret

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 30 Sep 2002 23:02:14 -0400

agreed.  
/jim

> Sent: Monday, September 30, 2002 12:03 PM
> To: Bound, Jim; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Jim Bound wrote:
> > ...
> > If the provider service is dominant IPv6 usage then the only 
> > reason to use Ipv4 are for services that have not been 
> > migrated to IPv6.  This is where DSTM brings its value.
> > 
> > It permits a network operator to:
> > 
> > 1: conserve and manage its precious IPv4 global address space
> > 2: control the use of IPv4 global address space per usage/service
> > 3: identify a migration of services and apps that must move to IPv6
> > 4: avoid the use of any NAT paradigm at the GGSN
> > 5. Use e2e security (e.g. IPsec) inherent on the handheld.
> > 6. Use IPv6 as the dominant routing protocol.
> > 
> > The above cannot be done with NAT-PT.  In addition
> > DSTM as a solution can be used only when needed and
> > does not require the routing complexity (except coming back 
> > into the GGSN) that 6to4 does.  But a variation of DSTM is 
> > also proposed that will use 6to4 if it is part of the DSTM.
> > 
> > DSTM not only is useful for 3G but 802.11 LANs, LMMs,
> > and WANs which I  see being deployed much faster and 
> > in fact currently and I see NO 3G deployment at this time.
> > So I am testing this with 802.11 as  a note and with handheld 
> > devices.  
> > 
> 
> Rod was correct, in the sense that for a basic 3G network a 
> demand IPv4
> PDP context provides the same functionality that DSTM provides to a
> routed IPv6 network. The point I think you are trying to make is that
> DSTM also works in wireless hot-spot networks, and for an 
> operator that
> is interested in a unified mechanism for handsets that roam 
> between the
> 802.11 & 3G radios, DSTM may be the best approach. If they really are
> locked into the point-to-point association between the GGSN & the
> handset, they could use L2TP as a companion mechanism when the radio
> drops the IPv4 PDP context. 
> 
> Tony
> 
> 
> 
>