Subject: [BEHAVE] Closing the behave WG

From: "David Harrington" <[email-masked]>
Date: Wed, 3 Aug 2011 20:12:47 -0400

Hi,

As Responsible Area Director, I have received a request from the
behave WG chairs to consider closing the behave working group, rather
than rechartering to do additional work.

The chairs and the IESG agree that closing the WG after completing the
current milestones would be a good thing, to signal that the chartered
behave work items supporting transition to IPv6 have been completed.

During ietf81, the chairs discussed with the working group the
possible closing of the working group. Additional work, such as those
drafts identified in the chairs' slides, can be proposed for
completion in existing working groups (or in new working groups). None
of this would be automatic; the proponents would need to convince an
existing WG to adopt their draft, or would need to convince the IESG a
new working group is justified using the normal methods for requesting
a new working group. The behave chairs have agreed to serve as
technical advisors to working groups that take on such work, if
needed. 

In my opinion, the sense of the room was to support this closure. 

As Responsible area director, I plan to make a decision on WG closure
in the next few weeks, and would like to give the WG mailing list
members a chance to provide feedback on this proposed closure. Please
send substantive comments to the
[email-masked] mailing list by 2011-08-15, with the above Subject
line.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 4 Aug 2011 03:58:21 -0400

> than rechartering to do additional work.

I vote for rechartering. There is very important work to be done in this
area, specially given the CGN traction in the market. I would like to see at
least the following drafts published.

http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-02
https://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-00

> behave work items supporting transition to IPv6 have been completed.

I understand BEHAVE have been around for a while and if it is taking a lot
of the chairs' time maybe we could consider changing the chairs for the next
rechartering. 

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 04 Aug 2011 09:47:02 +0000

I'm also in favor of rechartering due to the same reason mentioned by Reinaldo, that is, there is still a lot of very important work to be done in this area. 

Since CGNs are usually deployed in ISP networks or large enterprise networks, rather than in home networks, and these devices usually carry a large volume of traffic and users, high availability and load-balancing are much desirable features for most CGN operators. Although proprietary solutions are available to some extent, vendor lock-in and simultaneous failure due to the same bug are two side-effects with such proprietary solutions, which are not much acceptable to some operators. Hence I do suggest the WG could reconsider these two important features for CGNs if/when rechartering.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Reinaldo Penno
> 发送时间: 2011年8月4日 15:58
> 收件人: David Harrington; [email-masked]
> 主题: Re: [BEHAVE] Closing the behave WG
> 
> 
> 
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Aug 2011 08:58:23 -0400

> In my opinion, the sense of the room was to support this closure. 

I disagree. Several people went to the mic to talk about additional work
that needs to be done. In addition, I think many authors of drafts that
were on the "potential additional work" slides were not at this meeting.

Personally, I've stated at the mic that the CGN logging issue is very
important to many people right now and that there is a need for a
standard solution. There are at least two drafts currently trying to
address this issue. We have the right people in behave right now to
address this problem. Moving this work to another working group would be
detrimental.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Stan Barber <[email-masked]>
Date: Thu, 4 Aug 2011 09:47:20 -0400

I also agree there is much work still on the table for this group.

If not done in BEHAVE, is there another place this work could be done?

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 4 Aug 2011 08:12:13 -0700

I disagree that it should be closed and suggest that the nat464 (as
described in pnat, 4v6, and bih) be properly named nat464, generalized, and
brought into this group, softwire is not the right place. It is a shame that
nat464 has such a bad name that the concept has to be veiled in various
other specs

Cb

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 04 Aug 2011 11:56:10 -0700

Hello folks,

I agree that the behave WG "SHOULD NOT" be closed.
I really think that NAT[v4-->v6] is important as
a perhaps crucial part of the transition story.
I understand the case against it to be that "we don't
support IPv6-only services for the existing Internet,
because IPv4 websites fill the need" -- an argument
that I still find to be amazing, coming from experts
in the IETF.

Regards,
Charlie P.

On 8/4/2011 8:12 AM, Cameron Byrne wrote:
> described in pnat, 4v6, and bih) be properly named nat464, generalized,
> and brought into this group, softwire is not the right place. It is a
> shame that nat464 has such a bad name that the concept has to be veiled
> in various other specs
>
> Cb
>

---

From: Dean cheng <[email-masked]>
Date: Thu, 04 Aug 2011 17:44:29 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David Harrington
> Sent: Wednesday, August 03, 2011 5:13 PM
> To: [email-masked]
> Subject: [BEHAVE] Closing the behave WG
> 
> Hi,
> 

I disagree with this since actually several people spoke at the mic
at the time encouraged the other way around.

Dean

---

From: Dave Thaler <[email-masked]>
Date: Fri, 5 Aug 2011 17:01:07 +0000

Most were people who argued for doing specific work.

The discussion in the meeting was not about *not* doing the work.
The discussion was about whether they should be in behave or elsewhere.

Any arguments for "this work is important" are not arguments for "in behave" per se.

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean cheng
Sent: Thursday, August 04, 2011 10:44 AM
To: David Harrington; [email-masked]
Subject: Re: [BEHAVE] Closing the behave WG

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David Harrington

I disagree with this since actually several people spoke at the mic at the time encouraged the other way around.

Dean

> send substantive comments to the [email-masked] mailing list by 
> 2011-08-15, with the above Subject line.
> 
> David Harrington

---

From: Simon Perreault <[email-masked]>
Date: Fri, 05 Aug 2011 13:08:52 -0400

> Any arguments for "this work is important" are not arguments for "in behave" per se.

Right. This should be added: the work that people at the mic argued for
doing in behave really should be done in behave. We already have the
right people here. Other existing working groups are currently busy
focusing on other important issues. Chartering a new working group would
be useless. Rechartering for the new work seems to me like the best way
to make progress.

Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Aug 2011 13:32:41 -0400

Dear colleagues,

On Thu, Aug 04, 2011 at 08:58:23AM -0400, Simon Perreault wrote:
 
> standard solution.

I think that it is quite likely to be important work.  I do not see,
however, that it is BEHAVE's problem, and rechartering to make it so
seems to me to do violence to the idea of IETF areas.

Logging is an operational concern.  That problem belongs in the OPS
area, where you have some hope of getting the consumers who need this
work to participate.

The reason I argue this way is motivated by my own experience: DNS64
got _almost no_ review from the DNS community, even though it sorely
needed it.  There was a last-minute review from the DNS directorate
(after months of me yanking as hard as I could on strings to get that
review) that turned up several issues that, quite frankly, should have
been handled better.  But we didn't get that review in time.

Logging is even more user-directed than the DNS.  Don't do that work
here.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Aug 2011 13:44:42 -0400

Dear colleagues,

> a perhaps crucial part of the transition story.

I would like to see the argument for this.  So far, I haven't seen one
that I find compelling, and the fact that the chairs received only
late submissions for inclusion in the Québec meeting strikes me, at
least, as additional evidence for the view that there's nothing anyone
really really needs to pursue.

The longer a WG lives, the harder it gets to shut it down (I am
speaking from really bitter experience here).  I have no interest per
se in shutting working groups down.  But I'd be a lot more convinced
that there's urgent work to do here if I saw something that I didn't
think was a pipe dream (generalized NAT46 falls into this category in
all the forms I've so far seen) or better undertaken elsewhere (such
as the logging stuff that I think is indeed important).  So a
carefully-reasoned argument (I promise to read it and rescind my
opinion if it convinces me!) would give me a reason to change my mind.
Alternatively, a pointer to some archived message I no doubt missed
would provide the clue-bat.  But otherwise, I am inclined to support
the AD's expressed view that it's time to wind things up.  (For my
next windmill-trick, I'll lean at DNSEXT.)

Curmudgen to the end, 

A

-- 
Andrew Sullivan
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Fri, 05 Aug 2011 13:52:32 -0400

> area, where you have some hope of getting the consumers who need this

I would also be fine with a dedicated working group in the OPS area. I
see at least logging, bulk port allocation, and MIB stuff that would be
appropriate for the OPS area, probably others I'm forgetting.

Actually, is it possible to "move" a working group from one area to
another? We're done with the protocol work, now it's time for
operational tweaking.

Maybe rename to BEHOPS? Or OPSAVE? ;)

Simon

---

From: Dave Thaler <[email-masked]>
Date: Fri, 5 Aug 2011 19:59:18 +0000

Right, having a dedicated WG in the OPS area is the same model followed
for multicast (IDMR -> MBoneD) and then for IPv6 (ipng -> v6ops).
The difference with IPv6 is that 6man was chartered in addition to v6ops.
But in both cases, idmr and ipng closed and new WGs were opened.

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Friday, August 05, 2011 10:53 AM
To: [email-masked]
Subject: Re: [BEHAVE] Closing the behave WG

> area, where you have some hope of getting the consumers who need this 

I would also be fine with a dedicated working group in the OPS area. I see at least logging, bulk port allocation, and MIB stuff that would be appropriate for the OPS area, probably others I'm forgetting.

Actually, is it possible to "move" a working group from one area to another? We're done with the protocol work, now it's time for operational tweaking.

Simon

---

From: John Border <[email-masked]>
Date: Fri, 5 Aug 2011 16:05:31 -0400

NATOPS

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Friday, August 05, 2011 3:59 PM
To: Simon Perreault; [email-masked]
Subject: Re: [BEHAVE] Closing the behave WG

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Friday, August 05, 2011 10:53 AM
To: [email-masked]
Subject: Re: [BEHAVE] Closing the behave WG

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 5 Aug 2011 16:07:04 -0400

I would argue to do this work in BEHAVE. We already have a WG, already have
experts engaged, a lot of the work is more than just 'OPS' (logging, bis,
port block/sets, etc) and there is no need to go through all the steps to
have a new WG.

In regards to 'moving' to OPS the issue I see is that there are many draft
that are related to protocol work. Not sure if they would be served by a WG
in OPS.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 05 Aug 2011 13:48:52 -0700

Hello Andrew,

On 8/5/2011 10:44 AM, Andrew Sullivan wrote:

> I would like to see the argument for this.

If we don't have NAT[v4-->v6], then IPv6-only
services are not going to be available to most
of the Internet for a really long time.

Which, I reckon, means that all services are going
to be either IPv4-only or dual-stack for a really
long time.

It seems to me that requiring all services to
have IPv4 addresses is directly counter to the
general IETF theme of promoting IPv6 transition.

Perhaps instead you meant that there are not any
credible possibilities for NAT[v4-->v6].  I am
willing to agree that as far as I understand it
the alternatives (as of now) have problems of either
scalability or maybe vulnerability to DoS attacks.
I think these are problems that can be solved,
and they would be solved faster in a working group.

Looked at another way, if [behave] shuts down
without working on NAT[v4-->v6], then it can be
seen as sending a strong message that the IETF
believes that all services and websites really need
to maintain IPv4 addressability ad infinitum
[or at least all commercially viable ones].

Regards,
Charlie P.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 5 Aug 2011 14:19:10 -0700

> [or at least all commercially viable ones].

I would also like to add the case of NAT464, which is really baked
into PNAT, BIH, and 4V6.... but veiled and hobbled in each case.

Since the IETF values running code, NAT46 is implemented on the N900 here.

http://code.google.com/p/n900ipv6/wiki/Nat64D

And, when combined with the T-Mobile USA NAT64, it is a full NAT464
that solves a real problem and meaningfully enables IPv6-only
endpoints that have applications that have IPv4 literals or IPv4
sockets.

Cameron

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Aug 2011 17:24:49 -0400

> to be either IPv4-only or dual-stack for a really

I think I see our point of disagreement, then.  I think that both of
those claims are true regardless of whether we have some sort of
v4->v6 bag of tricks.  If you have a service that you think needs
users, you are going to try to hang it off v4 and v6 (and probably
x.25 and everything else, if it seems viable).  At some point, the v4
traffic won't be worth the cost, I think, and therefore I'm willing to
let the v4 transition take (if need be) until the heat death of the
universe.  Why do we care?

> and they would be solved faster in a working group.

But so far, nobody has actually proposed anything that would solve
them.  Instead, what we're getting is yet more spackle on top of
patches like NAT64/DNS64.  I participated in that effort precisely
because I want not-too-awful transition mechanisms to be available for
the most pressing cases; now I'm starting to wonder whether this was a
good idea.  We today have the spectacle of a WG standardizing a
special-case name in the DNS in order to get around the DNS64 mess,
primarily so that people whose protocols are broken in the first place
don't have to fix the mess they left on the carpet (since they've told
us that they're going to do this anyway).

I am not one of those protocol purist zealots who think that we have
to say no to everything because it's ugly.  But there is surely a
point at which we have to say, "Yes, that's a very hard problem, and
we don't have even the hope of a generalized solution, so we shouldn't
standardize even more half-measures."  We have plenty of
half-measures.  If someone has a whole measure, then let's hear it.
Otherwise, let's stop.  These halves are not adding up to wholes, so
more half-measures have the perverse effect of undermining
interoperability.  I'm interested in interoperability.

> [or at least all commercially viable ones].

If businesses waited for the IETF to provide commercial blessing,
they'd have ignored NAT44.  That's not a problem we have.  We are not
the priests of the Internet.  (If anything, we're the water and sewer
division.  Let's worry about whether the relevant substances are
flowing, and to where!)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Aug 2011 09:25:18 +1200

Charlie,

> to be either IPv4-only or dual-stack for a really

Correct. I've regarded that as a given for some years now.
I wouldn't put any of my own money into an application service
provider who proposed to go IPv6-only in the near future.

> general IETF theme of promoting IPv6 transition.

I try to avoid the word "transition" and focus on co-existence.
Also, the "universal deployment of IPv6" does not imply
"deployment of IPv6-only services". So I'm not sure that this
is a current goal for the IETF. It seems like something that
lies quite some years in the future.

Regards

   Brian

---

From: Ralph Droms <[email-masked]>
Date: Fri, 5 Aug 2011 17:29:53 -0400

Brian, et al.,

> lies quite some years in the future.

Seems to me, then, we can comfortably postpone serious work on NAT[v4-->v6] until (and if) we find we really need it...

- Ralph

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 05 Aug 2011 16:28:05 -0700

Hello Andrew and all,

Follow-up below...

On 8/5/2011 2:24 PM, Andrew Sullivan wrote:
>    .........                                  both of
> v4->v6 bag of tricks.

See below, but you have to admit if we insist on not
supporting v4-->v6 then we are essentially mandating
those two results.

>                    If you have a service that you think needs
> x.25 and everything else, if it seems viable).

Unfortunately, that might include practically all websites
except the ones that wish to intentionally restrict access.
Then we end up where it's no longer so democratic to offer
a website, because the hosting site has to have a v4 address.
Oh, but wait, then the website owner can pay extra for that.
Makes a good business for prolonging the requirement for
IPv4, and moreover a business that gets better over time
as more and more people wish to have some sort of widely
available Internet communication endpoint (at least until
the heat death of the universe).

I guess I had hoped things could be better.

>                                       At some point, the v4

O.K. so I am not really concerned about how long
it takes for IPv4 traffic to disappear.  I am much
more concerned about how long the IETF will practically
mandate IPv4 addressability for all new websites (and
whatever the future paradigm for publishing content or
offering service might be).

I hope you will tell me that you do see the difference.

>> credible possibilities for NAT[v4-->v6]. ...
> them.

Ouch.

>       Instead, what we're getting is yet more spackle on top of
> patches like NAT64/DNS64.

Perhaps I am missing the point, but if an IPv4 host
wants to resolve the name of an IPv6-only host, isn't
DNS tautologically required to help out with that?

> .............................................. there is surely a
> standardize even more half-measures."

Hmmm...  Just this morning, someone quoted Mark Townsley as
saying:

  "If you have something that solves 90% of a problem for 90%
   of the population, you have a product to ship"

But your answer presumes that we don't even have the hope,
and given that of course it is futile [...case closed].

>     ...       These halves are not adding up to wholes, so

I think you will get universal agreement on the latter.
If existing efforts could not possibly add up to a better
solution that would _enhance_ interoperability, I would
be in your camp.  But I expect better results are very
likely to be achievable.

> the priests of the Internet.

I thought that the IETF neglect to specify interoperable
NAT44 was nearly universally considered to be a serious
failure, not to be repeated.  Am I wrong?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 05 Aug 2011 16:28:47 -0700

Hello Brian,

I haven't replied to any of your messages for
an extremely long time :-)

On 8/5/2011 2:25 PM, Brian E Carpenter wrote:

>>  ...                all services are going

I wouldn't either!  In fact, it would be really wrong
to go IPv6-only until after either the heat death of the
universe, or until there is a solution to the [NAT v4-->v6]
problem.  Even if we start today in [behave], we won't
have a standard for at least a year or two.  But we can
start because I think the problem is really pretty well
understood.

> lies quite some years in the future.

Well, my point is mostly if we fail to do anything today,
we are helping to push the "deployment of IPv6-only services"
even farther into the future.  Moreover, that enabling such
deployment would be very helpful to enable more and more
people to offer services/websites/webcams/content etc...
over our now-even-more-rapidly-expanding Internet.  There is
a famous IBM joke about planning for new bridges that fits here.

Regards,
Charlie P.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Aug 2011 21:50:59 -0400

> a website, because the hosting site has to have a v4 address.

This seems to be conflating "someone still has to connect via IPv4"
with "most people have to connect via IPv4".  I don't notice a large
number of people still trying to connect via X.25, even though it's
still available and was once considerably more widely supported than
IPv4. 

> mandate IPv4 addressability for all new websites (and

I just don't get how the IETF is mandating anything (never mind how
seriouslt the IETF's mandates are taken.  Given another project --
around IDNA -- I'm involved in, I gots to tell you that the IETF's
imprimatur and a nickel will get you 5 cents worth of pennies, but
only if the bank doesn't impose a service charge).

> >But so far, nobody has actually proposed anything that would solve

Perhaps I'm missing some draft, then.  Hit me with the clue-stick,
please.  I'm almost always wrong about everything, so I'm prepared to
be wrong here too.

> DNS tautologically required to help out with that?

Yes.  And my claim is that this is a problem that absolutely nobody
actually has, nor will have for some time to come.  I would be
astonished to learn otherwise.  As soon as we get to the point where
there is serious IPv6-only traffic, all the IPv4-only people will (1)
get a real clue and go dual stack or (2) do (1) only with more
invasive technology.

If you're telling me that (2) can be done cleanly and in a
well-standardized way, then please point me to the draft that doesn't
include things like, "Except Skype is broken."  Because we already
have that with NAT64, and we're about to violate every sensible bone
in my body forever in order to allow ourselves to detect that there's
a DNS64 in the way.

>   of the population, you have a product to ship"

Right.  That's not the same as, "If you have something that solves 50%
of a problem for 50% of the population, except that it breaks other
things all over the network."  Everything I've seen suggests to me
that additional proposals fall into this category, IMO, but I'm
totally prepared to be wrong.  What draft have I missed?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jiangsheng <[email-masked]>
Date: Mon, 08 Aug 2011 01:34:44 +0000

> Seems to me, then, we can comfortably postpone serious work on NAT[v4--
> >v6] until (and if) we find we really need it...

Fully agree. +1

In last year, we had some mobile providers told us they might have IPv6-only mobile devices. But now, the situation has changed. We are told all major mobile OSes support or plan to support, in short time scale, dual stack; and at their experimental measurement, running dual stack is not that computational consumption as they original thought. Without real traffic, keeping dual stack on is almost negligible. As long as there have no duplicated traffic for the same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would be dual stack. There won't be IPv6-only devices for a long while.

Sheng

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 7 Aug 2011 18:54:13 -0700

On Aug 7, 2011 6:35 PM, "Jiangsheng" <[email-masked]> wrote:
> In last year, we had some mobile providers told us they might have
IPv6-only mobile devices. But now, the situation has changed. We are told
all major mobile OSes support or plan to support, in short time scale, dual
stack; and at their experimental measurement, running dual stack is not that
computational consumption as they original thought. Without real traffic,
keeping dual stack on is almost negligible. As long as there have no
duplicated traffic for the same application, dual stack is not expensive
than IPv4/Ipv6 single stack. So, the conclusion is even mobile devices would
be dual stack. There won't be IPv6-only devices for a long while.

My understanding is different.

In fact, I am a mobile operator that has beta ipv6-only capable devices that
will be launched soon.

Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which
generally translates to 2x the cost (lincenses, signalling, mobility events,
session setup, authetication...). This case is different in LTE, but the LTE
ramp rate is still very very small compared to gsm and umts.... and dual
stack fundamentally does not solve private and public address exhaustion
that most mobile providers are currently challenged with, since dual stack
requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion
is a tactical business problem, dual stack is not the answer... and yes, the
devices are in the pipeline

Cb

---

From: Jiangsheng <[email-masked]>
Date: Mon, 08 Aug 2011 01:58:51 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cameron Byrne
Sent: Monday, August 08, 2011 9:54 AM
To: Jiangsheng
Cc: Charles E. Perkins; [email-masked]; Andrew Sullivan; Ralph Droms
Subject: Re: [BEHAVE] Closing the behave WG

In fact, I am a mobile operator that has beta ipv6-only capable devices that will be launched soon.

Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which generally translates to 2x the cost (lincenses, signalling, mobility events, session setup, authetication...). This case is different in LTE, but the LTE ramp rate is still very very small compared to gsm and umts.... and dual stack fundamentally does not solve private and public address exhaustion that most mobile providers are currently challenged with, since dual stack requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion is a tactical business problem, dual stack is not the answer... and yes, the devices are in the pipeline

Cb

> > >> [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Jiangsheng <[email-masked]>
Date: Mon, 08 Aug 2011 02:08:35 +0000

Oops... The previous email was sent with any information by wrong button.

<Sheng> Yes, we have mobile operator customers who are strategically choose IPv6-only network + Nat64. What I said above is the information I got from Handset devices perspective.

Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , which generally translates to 2x the cost (lincenses, signalling, mobility events, session setup, authetication...).

<Sheng> These cost may not necessary for the handset devices depends on how mobile provider operates the network. These abovementioned operational cost can be handled by layer 2. Then, in layer 3, dual stack has almost the same cost with single IPv4/IPv6 stack.

This case is different in LTE, but the LTE ramp rate is still very very small compared to gsm and umts....

and dual stack fundamentally does not solve private and public address exhaustion that most mobile providers are currently challenged with, since dual stack requires the ipv4 address that are ....exhausted.... so if ipv4 exhaustion is a tactical business problem, dual stack is not the answer... and yes, the devices are in the pipeline

<Sheng> From last year, when we say dual stack, we do NOT mean IPv6 + public IPv4. It can be IPv6 + private IPv4, too. This may request more operational cost at network provider for CGN. But from handset perspective, they do not care IPv4 private or public address, unless there are considerable performance different.

Sheng

Cb

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 7 Aug 2011 20:07:59 -0700

On Aug 7, 2011 7:09 PM, "Jiangsheng" <[email-masked]> wrote:
>
> Oops… The previous email was sent with any information by wrong button.
>
>
>
Of Cameron Byrne
> <Sheng> Yes, we have mobile operator customers who are strategically
choose IPv6-only network + Nat64. What I said above is the information I got
from Handset devices perspective.

We have ipv6-only handsets that work well. There is no cost difference at
the ue, but cost in the core network is the challenge for dual stack. Given
that customers will not pay more for ipv6, the network cannot cost more to
deliver the service over ipv6.

generally translates to 2x the cost (lincenses, signalling, mobility events,
session setup, authetication...).
>
> <Sheng> These cost may not necessary for the handset devices depends on
how mobile provider operates the network. These abovementioned operational
cost can be handled by layer 2. Then, in layer 3, dual stack has almost the
same cost with single IPv4/IPv6 stack.

Agreed, these are packet core cost.

I am not sure what you mean about cost in layer 2, can you be more
specific?  All those cost I outlined are essentially layer 2 costs, those
cost double in dual stack in current gsm and umts networks, and therefore
dual stack is a bad business case in gsm and umts networks.

> and dual stack fundamentally does not solve private and public address
exhaustion that most mobile providers are currently challenged with, since
dual stack requires the ipv4 address that are ....exhausted.... so if ipv4
exhaustion is a tactical business problem, dual stack is not the answer...
and yes, the devices are in the pipeline
>
> <Sheng> From last year, when we say dual stack, we do NOT mean IPv6 +
public IPv4. It can be IPv6 + private IPv4, too. This may request more
operational cost at network provider for CGN. But from handset perspective,
they do not care IPv4 private or public address, unless there are
considerable performance different.

Agreed, once again the core network is the costly part, not the ue.
Regarding core network costs, the large mobile operators have exhausted both
public and private addresses, and now in some cases use bogon addresses.
This address exhaustion in ipv4 is driving expensive architecture changes
(paritioning multiple rfc1918 realms ...) that can only be relieved by
stopping ipv4 growth.... which means growing in ipv6 only.

My only point is that ipv6-only is real in mobile, expect to see it in the
near term. I have been running it in beta for 18 months and we are going
production real soon now.

Cb

---

From: Jiangsheng <[email-masked]>
Date: Mon, 08 Aug 2011 10:07:04 +0000

I am not sure what you mean about cost in layer 2, can you be more specific?  All those cost I outlined are essentially layer 2 costs, those cost double in dual stack in current gsm and umts networks, and therefore dual stack is a bad business case in gsm and umts networks.

<Sheng> We share the same understanding of layer 2 cost. What I meant was "lincenses, signalling, mobility events, session setup, authentication" can be handled by layer 2. Then IPv6/IPv4 authentication/lincenses may not be needed. Mobility events is layer 2 events, should not increase the cost whether it is dual-stack or single. Session setup/signalling are application-initiated. As long as no duplication, session setup/signalling would actually though single stack even on dual stack platform.

Overall, my point is dual-stack does not bring too much extra cost from handset perspective. So, single-stack handset would not be one of the critic reasons any more. (Of course, provider cost would increase. Providers may choose IPv6-only network for many reasons, including cost. But it should another discuss topic, I guess.)

Sheng

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 08 Aug 2011 09:37:30 -0700

Hello folks,

On 8/5/2011 2:24 PM, Andrew Sullivan wrote:

> with "most people have to connect via IPv4".

Put simply, if someone has a website or service, and they want
it to be available to the Internet, it _HAS_ to be addressable
by IPv4 right now.  And this situation will persist until either:
- NATv4v6 exists, or
- the Internet is predominantly IPv6

No choice, resulting from IETF decisions.  Did IETF mandate the
result, or just cause it?

> seriouslt the IETF's mandates are taken.

See above.

> please.  I'm almost always wrong about everything, so I'm prepared to

I was thinking of several drafts including IVI, DIVI, SIPNAT, and
another draft from Dan Wing.

> astonished to learn otherwise.

Of course they aren't asking for it now.  There's practically
no IPv6 Internet (percentage-wise).

And, to the point, I claim that the action of neglecting NATv4v6
will lengthen the time until IPv6 Internet dominates.

>     ...........           As soon as we get to the point where

Well, we're looking at under 0.2%, and it's been over 10 years.

> include things like, "Except Skype is broken."

The above drafts all have substantial problems.  These
problems would likely be fixed by working group actions.
There is not yet a clean solution, but I think the above-
mentioned solutions can have their sins washed away.

> things all over the network."

Well, I am not promising anyone a rose garden.

Look at it this way.

We can enable some support for IPv6-only services.

IPv4 addressability will become more expensive.
IPv6 addressability will become cheaper (much cheaper).
If we can arrange it so that IPv4 access to IPv6-only
services is only slightly degraded, then we could
significantly speed up the adoption of IPv6 for
websites, services, peer-to-peer, etc.

The percentage degradation will affect the speed of
adoption for IPv6 services.  With zero degradation,
everyone would move to IPv6 that much faster.  With
large degradation, NATv4->v6 just would not help
very much.  With nonzero but small degradation,
IPv4 access will be seen as feasible but inferior
to IPv6 access --> incentive for the Internet to
move to IPv6 to get better access to the growing
population of IPv6-only websites.

Right now the achievable percentage degradation is
simply not known.  But we know that the current
percentage degradation is 100%.

Regards,
Charlie P.

PS to Andrew: This is the same as what I sent you
    earlier, with minor revisions, when I did not
    have access to this account.

---

From: Xing Li <[email-masked]>
Date: Thu, 11 Aug 2011 16:49:55 +0800

> than rechartering to do additional work.

I also vote for recharting. I was in the mic and said: "Since the IPv4 
address pool is empty and the coexistence of IPv4 and IPv6 will not be 
ended in a short time, we need additional translation solutions; no 
matter it is NAT44 or NAT46". I think Behave is a suitable place to 
continue the general translation work, we have experts and energy.

Besides, there are remaining works in the current charter, but no 
milestones (e.g. multicast). There are remaining issues mentioned in the 
Behave-WG RFCs (e.g. address extension and MIBs). I think we should at 
least have a complete set of documents.

Regards,

xing

---

From: Xing Li <[email-masked]>
Date: Thu, 11 Aug 2011 16:50:38 +0800

> result, or just cause it?

Yes, this is the situation some ICPs are facing now.

xing

---

From: Xing Li <[email-masked]>
Date: Thu, 11 Aug 2011 16:50:51 +0800

? 2011/8/8 9:54, Cameron Byrne ??:
> IPv6-only mobile devices. But now, the situation has changed. We are 
> told all major mobile OSes support or plan to support, in short time 
> scale, dual stack; and at their experimental measurement, running dual 
> stack is not that computational consumption as they original thought. 
> Without real traffic, keeping dual stack on is almost negligible. As 
> long as there have no duplicated traffic for the same application, 
> dual stack is not expensive than IPv4/Ipv6 single stack. So, the 
> conclusion is even mobile devices would be dual stack. There won't be 
> IPv6-only devices for a long while.
> >
>
> Furthermore, dual-stack in pre-release 9 networks is 2x the pdp , 
> which generally translates to 2x the cost (lincenses, signalling, 
> mobility events, session setup, authetication...). This case is 
> different in LTE, but the LTE ramp rate is still very very small 
> compared to gsm and umts.... and dual stack fundamentally does not 
> solve private and public address exhaustion that most mobile providers 
> are currently challenged with, since dual stack requires the ipv4 
> address that are ....exhausted.... so if ipv4 exhaustion is a tactical 
> business problem, dual stack is not the answer... and yes, the devices 
> are in the pipeline
>

+1.

xing

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 11 Aug 2011 12:28:07 -0700 (PDT)

>
>I disagree that it should be closed and suggest that the nat464 (as described in pnat, 4v6, and bih) be properly named >nat464, generalized, 

+1

>and brought into this group, softwire is not the right place. It is a shame that nat464 has such a bad name that the concept has to be veiled in various other specs
>Cb

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 11 Aug 2011 12:52:40 -0700 (PDT)

Hi Sheng,
  I think here the intent was more on NAT46 or 4rd. Not on NAT64.

Regards,

Behcet

> In last year, we had some mobile providers told us they might have IPv6-only 
> mobile devices. But now, the situation has changed. We are told all major mobile 
> OSes support or plan to support, in short time scale, dual stack; and at their 
> experimental measurement, running dual stack is not that computational 
> consumption as they original thought. Without real traffic, keeping dual stack 
> on is almost negligible. As long as there have no duplicated traffic for the 
> same application, dual stack is not expensive than IPv4/Ipv6 single stack. So, 
> the conclusion is even mobile devices would be dual stack. There won't be

---

From: "Perkins, Charles" <[email-masked]>
Date: Thu, 11 Aug 2011 12:55:04 -0500

Hello Rémi,

I think you are in agreement with me on all points
below -- please take a look...

> From: Rémi Després [[email-masked]]
> Le 8 août 2011 à 18:37, Charles E. Perkins a écrit :
> This isn't really true because:
> - Dual-stack routing offers IPv6 reachability without damaging IPv4 reachability.

==> destination IS addressable by IPv4.

> - There are tunneling solutions that maintain IPv4 reachability across IPv6-only routing networks without resorting to translation.

==> destination IS addressable by IPv4.

> The point on which we agree, I suppose, is:
> "IPv4 reachability has to be preserved as long as IPv4 traffic hasn't practically disappeared, being advantageously replaced by IPv6 traffic.

==> destination IS addressable by IPv4.

Perhaps you misunderstood what I was trying to say?

My point is that failing to provide NATv4->v6
practically requires all websites, services and
peer-to-peer communications to maintain IPv4
addressability.  That does NOT help to move
the Internet to IPv6, and in fact significantly
reduces IPv6's ability to solve the problem of
IPv4 address exhaustion.

Regards,
Charlie P.

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 15 Aug 2011 14:54:14 -0700

Hello Rémi,

On 8/12/2011 12:12 AM, Rémi Després wrote:

> Le 11 août 2011 à 19:55, Perkins, Charles a écrit :
>
>> addressability.
> What is needed is only to offer production quality IPv6 everywhere,
> without changing IPv4 connectivity for what it is (with NAT's, and
> NAT cascades, where shared addresses are unavoidable).
>      .........
> Web-service providers can then get rid of their IPv4 support, without
> having ever NEEDED NAT's between IPv6 and IPv4.

I agree that is a _feasible_ outcome.  But, it does not
seem to be happening very fast.  Enabling IPv6-only services
and websites will protect future businesses and netizens
from the high(er) cost of IPv4 allocation and administration,
and could play a significant role in accelerating your
scenario.

Of course I don't particularly love NAT, but I use it
every day.

The more ways we can encourage the deployment of
IPv6-only nodes (of all sorts), the faster we'll get to
where we need to go.

>     ....           many are convinced that NAT64 + DNS64 + PCP
> is better for them, and announce plans to deploy this combination.
> But this doesn't justify that one NEEDS NATv4->v6 for IPv6 to be
> generalized, with the end result that IPv4 traffic vanishes.

The disappearance of IPv4 traffic is not at all relevant,
and should not factor in the discussion.

Regards,
Charlie P.