Subject: [v6ops] Operational Consensus on deployment

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 4 Aug 2014 16:55:43 +0000

I changed the subject line.

On Aug 4, 2014, at 9:18 AM, Ross Chandler <[email-masked]> wrote:
> Section 7, discussions,  says “dual-stack deployment is recommended in most cases”. Is that still the consensus position?  Going straight to single-stack IPv6 is looking very viable now when the UE supports a method of providing translated IPv4 access over the IPv6 PDP/PDN connection. 

I would agree that there are a number of operators moving in that direction - DTAG Terastream, Google, Facebook, and several mobile operators come quickly to mind. The number of operators that still don’t have a customer-facing IPv6 offering still dwarfs them, and the IETF has not itself changed that position. So I would say that we have not changed our fundamental consensus - and at the same time agree that it isn’t as steady as it once was. There are cracks in the glacier.

Let me say this, though. The fundamental question that we have to answer, if we want to change the consensus, is (1) how we safely move a business from IPv4 to IPv6, shutting IPv4 down, and (2) how we deal with the residual IPv4 Internet. As with 464xlat or softwire's MAP, the latter comes down to some variation on translation and/or encapsulation. What I would like to see - consider this an invitation to an operator or an operator and a vendor that have implemented it and want to collaborate - is:

   - a short draft, counterpart to RFC 6540, stating a change in the operational consensus toward IPv6-only deployment
   - a practical approach on “how to get there” (probably more than one draft, addressing differing operational requirements)
   - a practical translation solution (possibly more than one draft)

I still tend to think that dual stack is the most reasonable “how to get there” approach; you have to have a running IPv6 network to move customers to before you can shut down the IPv4 network. The question is how long IPv4 stays up once you have a viable IPv6 network. If someone has a better idea, that is something to discuss.

I’m copying Tore, because I think http://tools.ietf.org/html/draft-anderson-siit-dc might very well be that “practical translation solution” for at least some environments. For an enclosed environment such as a data center, it enables the implementation of an IPv6-only environment, maintains IPv4 access to it, and maintains geolocation capabilities across that translation. At the point where the business requirement for IPv4 accessibility falls off, the translator simply becomes a vestigial capability, as opposed to requiring a dramatic and costly change. That seems pretty attractive. I’d invite discussion on that and on the draft (which is long expired, but Tore could resurrect it as draft-anderson-v6ops-siit-dc if he wanted to). If it now has a consensus behind it, publish as an RFC.

We would also need recommendations for residential broadband, which John Brzozowski might be in a position to make, and for enterprise networks, which someone from Google or Facebook might be in a position to do, or someone else.

I’ll channel Lorenzo, here. Lorenzo, correct me if I get this wrong. We want any statement along these lines to come from someone that has implemented it in their network.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 04 Aug 2014 20:51:32 +0200

* Fred Baker (fred)

> I’m copying Tore, because I think
> http://tools.ietf.org/html/draft-anderson-siit-dc might very well be
> that “practical translation solution” for at least some environments.
> For an enclosed environment such as a data center, it enables the
> implementation of an IPv6-only environment, maintains IPv4 access to
> it, and maintains geolocation capabilities across that translation.
> At the point where the business requirement for IPv4 accessibility
> falls off, the translator simply becomes a vestigial capability, as
> opposed to requiring a dramatic and costly change. That seems pretty
> attractive. I’d invite discussion on that and on the draft (which is
> long expired, but Tore could resurrect it as
> draft-anderson-v6ops-siit-dc if he wanted to). If it now has a
> consensus behind it, publish as an RFC.

Eerily good timing... I just started working on this again today, as it
happens. What I'm looking at now is two drafts, the one that's already
there for a single-translation network-only implementation, plus another
one describing an extension very similar to 464XLAT that would allow
NAT-incompatible and/or IPv4-only applications to be used in an
otherwise IPv6-only data centre.

However one of the things I was unsure about when I initially submitted
the draft was which WG was the most appropriate (sunset4 or v6ops).
Following the off-list discussion you, Marc, and I had back in November
2013, I thought the conclusion was sunset4. But now I see you saying
v6ops, so, uhm, now I'm no more certain than I initially was...

I'm in two minds about it, myself. The draft doesn't really describe
IPv6 operations per se, it deals more with the minimal backwards
compatibility glue necessary to provide service to IPv4 only users.
Score 1 for sunset4. On the other hand, an operator that wants to do
IPv6 today absolutely must have some form of IPv4 compatibility glue for
his offering to be commercially viable, thus, 1-1.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 4 Aug 2014 19:08:46 +0000

> his offering to be commercially viable, thus, 1-1.

Copying my co-chair and the two sunset4 co-chairs. If sunset4 wants it, so be it, from my perspective. It should not drop through the cracks, though.

My point in bringing this up is not that it is “useful in an IPv6 network” that might also be running IPv4 in parallel. It is that it seems useful to me in moving toward and IPv6-*only* network. Ross suggests that he sees conceptual movement - First they ignore you, then they laugh at you, then they fight you, and then you win. We may, Ross suggests, be approaching stage 4. It may be useful for us as a working group to lay out the game plan for that movement - not just to document IPv6 operational practice, but to help the IETF determine whether the dual stack consensus has changed or is changing, and help operators figure out how to turn IPv4 off without individually shooting their toes off. This would be part of that game plan.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Aug 2014 08:26:20 +1200

> My point in bringing this up is not that it is “useful in an IPv6 network” that might also be running IPv4 in parallel. It is that it seems useful to me in moving toward and IPv6-*only* network. Ro…

Well, I think the operators that moved early into genuine dual
stack operation have no reason to regret it. I'm a happy customer
of one such. On the other hand it seems that other operators are of
the opinion (probably unprovable) that providing the illusion of dual
stack service to the customer over an IPv6 infrastructure is cheaper.
In any case the customer ends up with NATted IPv4 service in most
cases, so at user level it doesn't really matter.

I think we should probably not express a preference either way. It
seems like a decision for each operator to make individually. What we
probably should do is stop inventing more solutions.

(In parenthesis, I've never seen sunsetting IPv4 as a real problem.
One day somebody will notice that there are no more IPv4 packets. But
that is many years in the future.)

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 4 Aug 2014 21:03:42 +0000

Following up on my note of a bit ago. Let me walk though a bit more of my line of reasoning by saying what question I would expect these drafts to answer.

>   - a short draft, counterpart to RFC 6540, stating a change in the operational consensus toward IPv6-only deployment

The current consensus regarding dual stack transition is captured in https://tools.ietf.org/html/rfc4213
     Basic Transition Mechanisms for IPv6 Hosts and Routers. E.
     Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes)
     (Obsoletes RFC2893) (Status: PROPOSED STANDARD)

That is the third in a series; RFCs 1933 and 2893 looked at possible transition plans and suggested the approach. In short, it suggests that IPv6 be brought up in an operator’s existing IPv4 network as “ships in the night”, the two networks be operated together until the need for IPv4 goes away, and the operator then turn off IPv4.

The simplest and clearest statement I have seen of an alternative plan is Pater Lothberg and Axel Clauberg’s comments regarding what they call “Kaikaku for IP networks”. See slide 5 of https://ripe67.ripe.net/presentations/131-ripe2-2.pdf. In short, operators are today running “dual stack” on a variety of different technologies, and doing so costs money. Peter and Axel are therefore asking what it would take to make the hard choices, jettison unnecessary costs, and dramatically simplify their service infrastructure. “IPv6-only” is part of that, but only part. The game plan is, instead of bringing IPv6 up in the existing network and subsequently convincing themselves to make other parts go away, to build a network based on a very few fundamental building blocks (IPv6, DHCPv6, YANG, one overlay technology, Metro Ethernet on the fastest fiber optics they can find, one IGP, BGP, and as little else as they can convince themselves they need), and then move customers to it. The older-and-more-expensive network dies when it has no customers.

That may be the most dramatic version, but what I see in 464xlat is similar; the underlying infrastructure is dual stack, but the handsets are one or the other and use separate sets of services. If the handsets and services supporting them are all moved to the IPv6 service, nobody will notice if IPv4 is turned off. 

Facebook has been making some pretty public comments about their movement toward IPv6-only; at first, their developers apparently pushed back pretty hard against becoming version-agnostic, but now they actually ask “would anyone mind if I simply leave the IPv4 part of this code out?”. http://www.internetsociety.org/deploy360/resources/case-study-facebook-moving-to-an-ipv6-only-internal-network/

For the IETF to have this conversation, we pretty much need a draft that makes a bold statement: “the time is soon coming, or perhaps has arrived, to turn IPv4 off.” I expect that bold statement to be controversial, both on this list and during IETF Last Call. I expect it to make the press. If we think we’re ready for that conversation, let’s have it. Whenever we have it, we will need a draft to focus it. If we’re not ready for it, that’s fine too. But how do we tell when we’re ready?

>   - a practical approach on “how to get there” (probably more than one draft, addressing differing operational requirements)

You might listen to the first 35 seconds of http://www.youtube.com/watch?v=kwFvJog2dMw, which was a seminal moment in the speaker’s presidency. “We choose to go to the moon. We choose to go to the moon in this decade... not because it is easy, but because it is hard.” I see the draft I just spoke about as a similar vision statement: “we choose to turn IPv4 off...”.

Jack Kennedy’s speech, delivered when I was ten, didn’t get us to the moon. We wouldn’t have gotten there without it, though. What got us to the moon was a lot of research, and a lot of very solid engineering. We have, I think, done the research, built the products, and tested them operationally. I’m looking for that engineering in these drafts. How do we get to the moon?

The alternative is where Microsoft Azure finds itself now. They are out of IPv4 address space and do not have a publicly announced IPv6 service. To fill the gap, they are moving address space from Brazil to the US. Now, lest someone think I’m slamming them, I have little doubt that they have a long term plan; it’s just not in evidence at the moment. But where they stand, if they don’t have a plan, they’re screwed. They are only the most public of a long list of companies with that problem...

>   - a practical translation solution (possibly more than one draft)

I’m also looking for solid engineering in this...

---

From: Mark Andrews <[email-masked]>
Date: Tue, 05 Aug 2014 09:11:51 +1000

In message <[email-masked]>, "Fred Baker (fred)
" writes:
>
> The alternative is where Microsoft Azure finds itself now. They are out
> of IPv4 address space and do not have a publicly announced IPv6 service.
> To fill the gap, they are moving address space from Brazil to the US.
> Now, lest someone think I'm slamming them, I have little doubt that they
> have a long term plan; it's just not in evidence at the moment. But where
> they stand, if they don't have a plan, they're screwed. They are only the
> most public of a long list of companies with that problem...

Azure would still need the IPv4 addresses because the rest of the
world as a whole has not moved to IPv6 yet.  While datacenters may
be able to move to IPv6 only internally there is still a external
need for IPv4 addresses.  IPv6 only gives some IPv4 address saving
but not that much on the server side.  We are still a long way from
turning off IPv4 servers.

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 4 Aug 2014 23:20:28 +0000

> turning off IPv4 servers.

That’s sort of the point of Tore’s document, with the exception that you can indeed move IPv4 addresses to *only* the edge using his mechanism.

That said, if you have an IPv6-capable data center and are selling it as a service to customers, that gives you a vehicle to discuss IPv6 with the customers. “I have a scarce resource that I can charge you for, and a plentiful resource I can charge you for. Which would you like to be charged for?"

---

From: Owen DeLong <[email-masked]>
Date: Mon, 4 Aug 2014 18:12:41 -0700

> I’ll channel Lorenzo, here. Lorenzo, correct me if I get this wrong. We want any statement along these lines to come from someone that has implemented it in their network. 

I believe that Dual Stack is still the best way forward in most cases where there are existing IPv4 addresses.

In the case where IPv4 addresses are unavailable, I think there is no clear winner and it is very situational and subjective to choose an appropriate translation/mapping solution for the given situation. Ideally, we should be working as hard as possible to get to a point where the solution to a lack of IPv4 addresses is clearly ideally IPv6 only.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 4 Aug 2014 18:35:14 -0700

> his offering to be commercially viable, thus, 1-1.

I would argue it doesn’t really fit either group, but there’s no place better
to put it.

Really, it’s about v4-life-support, but there’s on IPv4-Life-Support working
group. (perhaps there should be).

To my thinking, sunset4 is really about what we need to do to get ready to
turn off IPv4. A technology for continuing IPv4 in a v6-dominant world really
doesn’t fit that mission.

OTOH, this really is about continuing IPv4 operations, not v6ops, so it doesn’t
fit that charter well, either.

Of the two, I think it belongs more in v6ops than sunset4, simply because it
really has little (nothing) to do with getting rid of IPv4 and is the opposite, if
anything.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 4 Aug 2014 19:07:21 -0700

> turning off IPv4 servers.

We may be a long way from turning the existing ones off.

The address situation seems to suggest we may not be all that far from not turning on very many more new ones, however.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 4 Aug 2014 19:08:48 -0700

On Aug 4, 2014, at 4:20 PM, Fred Baker (fred) <[email-masked]> wrote:

> That said, if you have an IPv6-capable data center and are selling it as a service to customers, that gives you a vehicle to discuss IPv6 with the customers. “I have a scarce resource that I can charge you for, and a plentiful resource I can charge you for. Which would you like to be charged for?”

FWIW, Hurricane Electric charges for IPv4. We do not charge for IPv6. We apply ARIN compliant needs tests to all North American customer allocations/assignments and appropriate RIPE/APNIC criteria in those regions.

Owen

---

From: Ca By <[email-masked]>
Date: Mon, 4 Aug 2014 20:09:56 -0700

On Aug 4, 2014 1:26 PM, "Brian E Carpenter" <[email-masked]>
wrote:
>
>
> > My point in bringing this up is not that it is “useful in an IPv6
network” that might also be running IPv4 in parallel. It is that it seems
useful to me in moving toward and IPv6-*only* network. Ross suggests that
he sees conceptual movement - First they ignore you, then they laugh at
you, then they fight you, and then you win. We may, Ross suggests, be
approaching stage 4. It may be useful for us as a working group to lay out
the game plan for that movement - not just to document IPv6 operational
practice, but to help the IETF determine whether the dual stack consensus
has changed or is changing, and help operators figure out how to turn IPv4
off without individually shooting their toes off. This would be part of
that game plan.
> probably should do is stop inventing more solutions.

Why?

I was told the same thing about 464xlat, we did not need another solution.
If the ietf held the line against double translation i believe there would
be exactly 1 ipv6 cellular provider in the world (verizon).

With 464xlat, afaik, there are globally 3 cellular providers that offer
default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ).

It does not matter if the cat is white or black, it matters that it catches
mice.

CB

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Aug 2014 15:25:17 +1200

> default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ).

OK, but beyond a certain point vendors will want to stop adding options
and operators will want finite choices. We must be very close to that point
now.

> It does not matter if the cat is white or black, it matters that it catches

The pragmatist in me agrees with you. The former software team leader in
me is stressed out with the choices.

    Brian

---

From: Ca By <[email-masked]>
Date: Mon, 4 Aug 2014 20:44:40 -0700

Allow me to posit that the locus of internet growth is cloud, IoT, and
mobile. Growth areas are important because they drive ip address demand.
Public IPv4 as a unique host ID is dead and will never be used natively in
these high growth edge networks.

Cloud is near 100% nat, the public address is abstracted from the host.
Look at AWS, they dont have a product that gives machines a public ip
address from AWS of any sort at any cost. It is all NAT.  My guess and
Azure and Google are similar, but i dont know.

IoT -- simply cant scale on ipv4.

Mobile -- always has been ipv4 nat in most places, and now approaching all
places.

Even in old world DSL broadband like AT&T DSL, layer 2.75 is private ipv4
that moves the 6RD end to end on top.

The bigger question is -- who thinks real  public dual-stack on every node
is viable for the timescale the ietf or edge network engineering operates
at?  Not T-Mobile US, not facebook, not at&t , not Amazon AWS, not
Terastream. All these networks run at least 1 stack virtually (or
relayed/proxied) and i doubt they see a path to real dual-stack.

The better ietf i-d i would like to read is a post-mortem on why dual-stack
failed in edge networks and what the ietf can learn from this failure.  It
likely has an economic and psychological theme.

Don't get me wrong, the utopian dream of everyone turning ipv6 on over some
period of time and ipv4 slipping off unnoticed into the sunset is great...
But clearly just a dream. It did not and will not happen.

The history of ipv6 transition will not involve a distinct period of time
where a public ipv4 and ipv6 dual-stack internet happened.

CB

---

From: Ca By <[email-masked]>
Date: Mon, 4 Aug 2014 20:59:44 -0700

> Mobile -- always has been ipv4 nat in most places, and now approaching
all places.
>
> The bigger question is -- who thinks real  public dual-stack on every
node is viable for the timescale the ietf or edge network engineering
operates at?  Not T-Mobile US, not facebook, not at&t , not Amazon AWS, not
Terastream. All these networks run at least 1 stack virtually (or
relayed/proxied) and i doubt they see a path to real dual-stack.
>
> The better ietf i-d i would like to read is a post-mortem on why
dual-stack failed in edge networks and what the ietf can learn from this
failure.  It likely has an economic and psychological theme.
>
> Don't get me wrong, the utopian dream of everyone turning ipv6 on over
some period of time and ipv4 slipping off unnoticed into the sunset is
great... But clearly just a dream. It did not and will not happen.
> CB

Obligatory cross domain reference, although my wife says this theory is
bogus and gets angry when i bring it up

http://en.m.wikipedia.org/wiki/Punctuated_equilibrium

---

From: Tore Anderson <[email-masked]>
Date: Tue, 05 Aug 2014 07:12:59 +0200

* Owen DeLong

> To my thinking, sunset4 is really about what we need to do to get
> ready to turn off IPv4. A technology for continuing IPv4 in a
> v6-dominant world really doesn’t fit that mission.

The thing is that it allows an operator to completely turn of IPv4 in
99%+ of his infrastructure. All the network components inside the data
centre, all the servers, all the software applications...here we're
talking about tens of thousands of individual things, overall, and we're
not even a particularly big shop. In contrast, the number of SIIT
gateways we need you can count on one hand.

So for me, it is really about turning off IPv4 - to the extent possible
in today's IPv4-dominated Internet, leaving only behind the absolute
minimum necessary, in an as optional role as possible (i.e., shutting it
down won't impact the application stacks or service availability over IPv6).

> OTOH, this really is about continuing IPv4 operations, not v6ops, so
> it doesn’t fit that charter well, either.

Yep, that's what I was thinking too. The draft doesn't really discuss
the running IPv6 part, it just assumes that that's in place to begin
with. Though, the same could be said for 464XLAT, and that was done in
v6ops.

Tore

---

From: Tore Anderson <[email-masked]>
Date: Tue, 05 Aug 2014 07:25:29 +0200

* Ca By

> default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ).

Make that four, Telenor Norway has been doing IPv6-only/NAT64/464XLAT
since early June.

http://www.telenor.no/privat/kundeservice/mobilhjelp/internettpamobilen/feilsokingmmsoginternett.jsp

So far only one model (Samsung S5) defaults to the new IPv6-only APN,
but from what I hear they'll keep adding new models and push OTA updates
to other existing ones.

* Brian E Carpenter

>> that is many years in the future.)

The thing is, if you've built your infrastructure on IPv4, removing it
is going to be a royal pain in the arse. Even if all the IPv4 users have
left the public internet, if your application server speaks to your
database server over IPv4, and the database server speaks to the iSCSI
array over IPv4, and so on and so on, then you're simply not in a
position to easily shut IPv4 off.

Tore

---

From: Gert Doering <[email-masked]>
Date: Tue, 5 Aug 2014 08:03:12 +0200

Hi,

> that is many years in the future.)

Well, at some point you have to decide to no longer provision IPv4 on
new services, turn off IPv4 on existing services, stop the dual
monitoring needed for IPv4+IPv6 infrastructure, etc. - so "IPv4 just 
stops being there" isn't going to cut it for operators :-)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Czerwonka Michał 1 - Hurt <[email-masked]>
Date: Tue, 5 Aug 2014 09:21:52 +0000

Hi all,

I confirm this is correct. Even we went further and we do not use DNS64. Our architecture is CLAT+NAT64+DNS. So with dns and without dns ipv4 traffic always goes via CLAT. It’s perfect solution ☺ UK EE will do the same.

See more at: http://www.data.proidea.org.pl/plnog/12edycja/day2/track4/01_ipv6_implementation.pdf

Even triple translation is not bad too: CLAT+NAT64stateless+NAT44statefull.

BR,
Mcz
Orange Poland

February 1% of active PDP IPv6 ctx, now over 8%

From: v6ops [mailto:[email-masked]] On Behalf Of Ca By
Sent: Tuesday, August 05, 2014 5:10 AM
To: Brian E Carpenter
Cc: IPv6 Ops WG; Tore Anderson
Subject: Re: [v6ops] Operational Consensus on deployment

Why?

I was told the same thing about 464xlat, we did not need another solution. If the ietf held the line against double translation i believe there would be exactly 1 ipv6 cellular provider in the world (verizon).

With 464xlat, afaik, there are globally 3 cellular providers that offer default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ).

It does not matter if the cat is white or black, it matters that it catches mice.

CB

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

---

From: Tore Anderson <[email-masked]>
Date: Tue, 05 Aug 2014 13:51:36 +0200

* Tore Anderson

> otherwise IPv6-only data centre.

Here you go:

http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html
http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc-2xlat.html

XML sources and .txt formats at https://github.com/toreanderson/ietf/.

They're work in progress obviously, I haven't uploaded them to the I-D
repository yet. It would be nice if you and Lee could have a chat with
the sunset4 chairs and agree on which WG is the most appropriate first.
(I have no particular preference, but I want it done Right.)

Comments, criticisms, suggestions, pull requests would be very welcome!

Tore

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Tue, 5 Aug 2014 08:56:22 -0400 (EDT)

> position to easily shut IPv4 off.

Worse still is all the gear to workaround NAT, so it isn't just the usual 
suspects of desktops vs servers vs appilcations, but also the 
point-to-point setups (video conferecing comes to mind) I have encountered 
that require going around NATs.

(There is something to be said about a net gain in maintenace overhead in 
elminating some of that, but there's also the effort to remove it and 
test, etc.)

wfms

---

From: Owen DeLong <[email-masked]>
Date: Tue, 5 Aug 2014 07:57:04 -0700

> position to easily shut IPv4 off.

Yes and no…

Upgrading your application to be protocol agnostic about its connection
to the database server shouldn’t be very difficult these days.

Once that’s done, getting your database server to speak dual stack also
shouldn’t be very hard (you’ve been talking to your database vendor about
this for at least a couple of years now, right?).

Surely your iSCSI clients and servers are also on their way to being protocol
agnostic since you’ve been having those discussions with the appropriate vendors
as well, right?

Seems to me that your database server should speak to the iSCSI array
via configured hostname(s) and that if the client and server are dual-stack
capable, then adding IPv6 addresses to interfaces and AAAA records to
DNS should be about all that is required for the communication to move
relatively seamlessly from IPv4 to IPv6.

Likewise with your client <-> database communication.

Once that’s done, it shouldn’t be too hard to remove the A records, wait for
IPv4 to stop carrying traffic (or pick a maintenance window), and drop the
IPv4 addresses from the interfaces (with appropriate regard for quiescence
and/or restart of the various services/clients).

All of this should be achievable with 5 or fewer maintenance windows (2 or
fewer if your software is up to snuff).

Owen

---

From: Ca By <[email-masked]>
Date: Tue, 5 Aug 2014 08:08:14 -0700

> but from what I hear they'll keep adding new models and push OTA updates

This is excellent.  Well done Telenor.

CB

---

From: Owen DeLong <[email-masked]>
Date: Tue, 5 Aug 2014 08:11:07 -0700

On Aug 5, 2014, at 5:56 AM, William F. Maton Sotomayor <[email-masked]> wrote:

> Worse still is all the gear to workaround NAT, so it isn't just the usual suspects of desktops vs servers vs appilcations, but also the point-to-point setups (video conferecing comes to mind) I have encountered that require going around NATs.

Once the video conferencing setup is running over IPv6, will it care if you remove the IPv4 NAT workaround infrastructure?

Perhaps I am confused.

> 
> (There is something to be said about a net gain in maintenace overhead in elminating some of that, but there's also the effort to remove it and test, etc.)

As a general rule, once nothing is depending on something, removing it is usually fairly quick and painless, often accompanied with much celebration and the consumption of adult beverages with bubbles in the case of perpetually painful legacy infrastructure like NAT gateways and NAT workarounds.

The hard part is getting all that other stuff that depends on such infrastructure to the point that it depended on such infrastructure (past tense), but no longer does.

Owen

---

From: Ross Chandler <[email-masked]>
Date: Tue, 5 Aug 2014 16:30:06 +0100

> This is excellent.  Well done Telenor.

The APN roaming protocol setting for “telenor.mobil” listed at that URL says it is IPv6.

Is that really their setting? AFAIK the Android UE or more accurately the RIL it calls doesn’t fallback to IPv4 when IPv6 is explicitly requested.

Ross

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Aug 2014 11:40:15 -0400

> to the database server shouldn’t be very difficult these days.

Furthermore, you don't need to upgrade these parts of the application.  The only part you really need to upgrade is the part that sticks out of the data center.   The rest you can leave running IPv4 until the equipment dies: that's really your deadline.

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 5 Aug 2014 15:57:00 +0000

Hi all, EE similar, but not identical. We are hot on 464xlat (RFC6877), it is perfect for networks that already extensively use NAT44, and gets customers off IPv4 (both public and private, as neither is sufficient).
Regards,
Nick

From: v6ops [mailto:[email-masked]] On Behalf Of Czerwonka Michal 1 - Hurt
Sent: 05 August 2014 10:22
To: Ca By; Brian E Carpenter
Cc: IPv6 Ops WG; Tore Anderson; Kossut Tomasz - Hurt
Subject: Re: [v6ops] Operational Consensus on deployment

Hi all,

BR,
Mcz
Orange Poland

Why?

CB

> that is many years in the future.)

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

---

From: Ca By <[email-masked]>
Date: Tue, 5 Aug 2014 09:00:27 -0700

On Tue, Aug 5, 2014 at 8:40 AM, Ted Lemon <[email-masked]> wrote:
>.

One of the fundamental flaws with the dual-stack transition dream is
that people care and will upgrade.

Today in 2014, a young developer somewhere in the world using the best
tools is hard coding an IPv4 literal into a application.

Somewhere else in the world, the biggest and smartest companies are
investing billions of dollars into futuristic cloud platforms that
dont even have token IPv6 supports (Azure and Google Cloud)

In summary, the premise of the daul stack transition for the Internet
is faulty.  It already failed.

CB

---

From: Czerwonka Michał 1 - Hurt <[email-masked]>
Date: Tue, 5 Aug 2014 16:24:39 +0000

Hi Nick,

If you’re saying complainat with RFC6877, you will implement DHCPv6 PD and use dedicated ipv6 prefix for CLAT?

BR,
Mcz
From: Heatley, Nick [mailto:[email-masked]]
Sent: Tuesday, August 05, 2014 5:57 PM
To: Czerwonka Michał 1 - Hurt; Ca By; Brian E Carpenter
Cc: IPv6 Ops WG; Tore Anderson; Kossut Tomasz - Hurt
Subject: RE: [v6ops] Operational Consensus on deployment

Hi all,

BR,
Mcz
Orange Poland

Why?

CB

---

From: Philip Homburg <[email-masked]>
Date: Tue, 05 Aug 2014 18:29:49 +0200

> Somewhere else in the world, the biggest and smartest companies
> are investing billions of dollars into futuristic cloud platforms
> that dont even have token IPv6 supports (Azure and Google Cloud)
> 

People have been creating websites that only worked on IE6 long after it
became clear that doing so was a bad idea.

The question is if IPv4 is going to be bad enough that the pain of supporting
IPv6 will be worth it.

If so, the transition will happen and probably will even happen quickly.

The current IPv6 is mature enough that you can run it in production. Whether
people will run it in production depends on whether there is a net gain in
doing so.

That gain has to come from off-loading traffic from scarce IPv4 addresses.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Aug 2014 12:53:08 -0400

> is faulty.  It already failed.

With all due respect, I don't see how what you have said here benefits the discussion.   First of all, there's a great deal of evidence that what you've said isn't actually true, and secondly, even to the extent that it is true, it's not really actionable.  Of course there will be people who will do things the wrong way, and either limp along forever or eventually get bulldozed off the cliff.   So what?  

There are still mainframes in back offices running SNA, but that doesn't mean that IPv4 is irrelevant: quite the opposite--they are probably running SNA in IP tunnels, their 370 is probably an emulation running on an Intel box, and chances are that people are sshing in using a 3270 emulator.   So we don't care that they are still running SNA, and we don't care when they get rid of it, because it is not an "internet" protocol.   That is the future of IPv4 as well.

The question is, are there people who want to do a transition to IPv6 (or will want to), whether for altruistic or pragmatic reasons, and if so, is there additional help we can offer them, or is what we've done thus far sufficient?

---

From: Owen DeLong <[email-masked]>
Date: Tue, 5 Aug 2014 10:30:48 -0700

While this is rare, I come rely agree with Ted here. 

Well said, Ted. 

Owen

> On Aug 5, 2014, at 9:53, Ted Lemon <[email-masked]> wrote:
>

---

From: Tore Anderson <[email-masked]>
Date: Tue, 05 Aug 2014 19:42:45 +0200

* Ross Chandler

> Is that really their setting? AFAIK the Android UE or more
> accurately the RIL it calls doesn’t fallback to IPv4 when IPv6 is
> explicitly requested.

Yes, that's their setting. No need for fallback when IPv6 works, right?

To be honest I've never quite understood what all the fuss is about
regarding IPv6 and 3GPP roaming. My personal experience, having been a
customer of Tele 2 Norway (formerly Network Norway) using their IPv6
pilot for about two years, then moving to Telenor about six months ago,
is that IPv6 roaming Just Works.

I've not visited every country in the world, but I have been around a
bit, and I've made a point out of trying to establish an IPv6 data
bearer to every single PLMN I can register with. So far I've had 100%
success, including on Cameron's network... Thus enabling IPv6 roaming
doesn't seem like a scary proposition to me. I'm guessing perhaps
Telenor came to the same conclusion.

Tore

---

From: Ross Chandler <[email-masked]>
Date: Tue, 5 Aug 2014 19:22:57 +0100

Subject line change as this has turned more appropriate to the roaming-analysis draft.

> Telenor came to the same conclusion.

According to the manual my SGSN-MMEs have an “AllowIPv6ForAllVisitors” parameter that has to be set true to allow IPv6 PDP/PDN connections be set-up be visitors.

Out of the box the SGSN-MME had userplane IPv6 enabled for home users. It needed the DAF flag to be set (to allow dual-stack in a single bearer).

Proposal for  addition to the draft - it should mention “IPv6 Roaming friendly operator” settings (user plane IPv6 allowed, DAF=1 if possible) on how to make your network friendly for visitors. 

Ross

---

From: Tore Anderson <[email-masked]>
Date: Tue, 05 Aug 2014 20:33:14 +0200

* Ted Lemon

>> In summary, the premise of the daul stack transition for the
>> Internet is faulty.  It already failed.
> 
> With all due respect, I don't see how what you have said here
> benefits the discussion.   First of all, there's a great deal of
> evidence that what you've said isn't actually true, and secondly,
> even to the extent that it is true, it's not really actionable.  Of
> course there will be people who will do things the wrong way, and
> either limp along forever or eventually get bulldozed off the cliff.
> So what?

The dual stack transition has indeed already failed. If you're located
in Europe, Asia, or Latin America, chances are that you simply cannot
obtain the IPv4 addresses you need to run dual stack. North America
should be in the same situation shortly.

Any *current* recommendation to use dual stack to needs to come with a
caveat that it is only really applicable to African operators, to
operators who happens to be sitting on a large reserve of IPv4
addresses, or to operators who have no growth.

Geoff saw this coming of course, slides 27 through 29 of
http://www.potaroo.net/presentations/2007-10-23-ipv4-depletion.pdf sums
up how dual stack has failed much better than I ever could.

> There are still mainframes in back offices running SNA, but that
> doesn't mean that IPv4 is irrelevant: quite the opposite--they are
> probably running SNA in IP tunnels, their 370 is probably an
> emulation running on an Intel box, and chances are that people are
> sshing in using a 3270 emulator.   So we don't care that they are
> still running SNA, and we don't care when they get rid of it, because
> it is not an "internet" protocol.   That is the future of IPv4 as
> well.

I agree that once we're there, problem solved, nobody will care. However
we're very far from that that being reality. As Cameron rightly pointed
out, somewhere in the world right now, someone is writing a line of
code, creating a database schema, making an ACL, purchasing a piece of
hardware or service, or whatever, that creates yet another dependency on
IPv4, making it ever more difficult to demote IPv4 to a «not an
"internet protocol» à la SNA.

As Owen points out, I could weed out such dependencies in maintenance
windows. But even if that is true, with dual stack, IPv4-dependent
infrastructure will continue to be created at a much greater rate than I
can retroactively fix it to become IPv4-independent. And there is just
no way that I could possibly audit every line of code written, every
piece of software installed, or every service or piece of hardware
procured, and that way make sure that no new IPv4 dependencies are
introduced.

The way I see it, the only realistic solution to stopping the
infrastructure from acquiring more and more dependencies on IPv4 is to
remove it entirely. Cold turkey.

> The question is, are there people who want to do a transition to IPv6
> (or will want to), whether for altruistic or pragmatic reasons, and
> if so, is there additional help we can offer them, or is what we've
> done thus far sufficient?

I'm transitioning to IPv4 for pragmatic reasons, and dual stack doesn't
cut it for me, for reasons that include:

- I don't have enough IPv4 addresses to do dual stack for much longer.
- Dual stack greatly increases complexity, which in turn increases
  the OpEx and reduces service reliability.
- As mentioned above, the presence of IPv4 will inevitably cause an ever
  increasing dependency on IPv4, because of technological inertia in the
  humans that design, develop, and deploy the application stacks.

As for additional help needed, well, I'm trying to put my money where my
mouth is and coming up with a solution to these problems - you could
help by reviewing my drafts. :-) The solution works, there is already
running open-source code, so rough consensus is all that's missing...

Tore

---

From: Philip Homburg <[email-masked]>
Date: Tue, 05 Aug 2014 21:22:10 +0200

>should be in the same situation shortly.

If dual stack implies no NAT anywhere what is then the correct term for
NAT44 or NAT444 along with native IPv6?

Just curious. I would call that dual stack. But you don't appearently.

>running open-source code, so rough consensus is all that's missing...

My gut feeling is that translating IPv4 packets to IPv6 or vise versa is
bad idea. Some thing will come up to make your life miserable. In some
sense it is very similar to tunneling.

I think it is safe to say that in your model you have enough public IPv4
address to run your services. What your proposal eliminates is the need
for internal IPv4 addresses.

The question is then, why not simply run on RFC-1918 addresses internally?
Afterall, usually the goal is to provide IPv4 services. 

Maybe our setup is unique, but we have quite a few servers in remote
data centers that need to access internal servers. What we do is have
ACLs in the firewalls to only allow the addresses we know about and keep
the rest of the Internet out.

In your model, any IPv4 address in a remote data center would either have to
translated to an IPv6 address (which of course nobody recognizes) or we
need an IPv4 firewall infront of the SIIT Gateway. Leaving the dual ACL
problem in place.

If I look at our system, if we would just drop IPv4 support for all internal
communication then we would probably see a similar reduction in complexity.
Leaving only the communication between the load balancer and the actual
web front-ends as something that could be moved to IPv6.

---

From: Gert Doering <[email-masked]>
Date: Tue, 5 Aug 2014 21:54:02 +0200

Hi,

> The question is then, why not simply run on RFC-1918 addresses internally?

Why have dual everything inside, when single IPv6 is sufficient to 
achieve service delivery?  Dual everything is *dual* *work*, translating
to real money out in the real world.

Gert Doering
        -- NetMaster

---

From: Tore Anderson <[email-masked]>
Date: Tue, 05 Aug 2014 22:10:35 +0200

* Philip Homburg
> Just curious. I would call that dual stack. But you don't appearently.

The current IPv6 dual stack transition mechanism is defined in RFC 4213,
and it makes no reference to NAT whatsoever. This thread started out by
Fred asking if we needed to update the consensus that dual stack is the
IETF-recommended transition method, and in that context, no I not
consider that the current dual stack recommendation includes NAT44*.

It would certainly be possible to update RFC 4213 to mean that the new
recommendation is to do NAT44* in combination with IPv6, though. But I
don't think that's a good idea. We find ourselves in a hole, so maybe we
should stop digging instead of getting ourselves a new shovel...

> sense it is very similar to tunneling.

If you by tunneling are referring to the catastrophe that was 6to4, then
I disagree. It is more like 6RD or MAP-E as it will typically contained
within a single administrative domain.

As for other things failing, if you have some concrete examples, please
let me know. I'd certainly want to see if I can make those work, or if
not, make sure the drafts properly document the limitations causing the
failure.

> for internal IPv4 addresses.

That's right. No addresses lost due to network infrastructure,
servers/applications performing internal tasks, unused addresses on LAN
segments due to CIDR ^2 boundaries or space set aside for future growth.
One public service per IPv4 address only. I'd imagine that most internet
content providers have a much higher number of internal
applications/servers than they have public service addresses, so this
adds up to significant savings.

> Afterall, usually the goal is to provide IPv4 services.

I'd like to to it Right from the start, and actually deploy IPv6.
Changing to RFC1918 and NAT44 will do nothing to help me to deploy IPv6,
if anything it would distract me from it. When I do get around to doing
IPv6 as well, I'm stuck with the complexity of running two IP protocols
in parallel, resulting in extra OpEx and reduced reliability I'd rather
go without. (IMHO, IPv4-only is preferable to that, and it looking at
the IPv6 availability graphs it would appear most operators share this
view.)

If I ever want to actually discontinue the IPv4+NAT44 stuff in order to
get rid of that extra complexity and go IPv6-only, then that's another
very time-consuming and non-revenue-generating project to look forward
to. (Not.)

In summary, IPv4 scarcity forces us to change the way we've always done
stuff up until now. I'm not happy about it, but it is unfortunately
inevitable. Considering I need to change all this stuff now anyway I'd
much rather do it in a way that actually solves the problem long-term,
and doesn't just line me up for another big and painful migration
projects a few years down the road.

> need an IPv4 firewall infront of the SIIT Gateway. Leaving the dual ACL

Presumably you'll want a firewall inside of the SIIT gateway, to deal
with IPv6 ACLs? If so, you only need one firewall and only one ACL. If
you previously had an ACL that said something like in iptables syntax,
where 192.0.2.100 is the trusted IP address you want to allow:

--source 192.0.2.100 --protocol tcp --dport ssh -j ACCEPT

...with SIIT, you'd instead do, assuming 64:ff9b::/96 is the translation
prefix):

--source 64:ff9b::192.0.2.100 --protocol tcp --dport ssh -j ACCEPT

The above IPv6 address with the embedded IPv4 dotted quad is
syntactically valid, by the way, you don't even have to convert it to
hex (cf. RFC4291 section 2.2).

I would generally recommend locating the SIIT gateways as close to the
edge of your network as possible. Ideally as a logical function located
inside the border routers. That way, on the inside you can simply treat
everything as IPv6, and have one IPv6 firewall, one IPv6 ACL, one IPv6
IGP topology, and so on, and so on.

Tore

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2014 08:55:22 +1200

On 06/08/2014 08:10, Tore Anderson wrote:
> and it makes no reference to NAT whatsoever. 

Well, this is an interesting way of looking at things.

Since IPv4 has been routinely NATted for most users for most of
the time since broadband arrived, it had never occurred to me before
this morning that some people interpret "dual stack" to mean no NAT44.
RFC 4213 is agnostic about NAT afaik. It does assume that the ISP has
a supply of IPv4 addresses, but it doesn't assume they are globally
routeable. Also, its language doesn't say that it's *the* solution:

   The mechanisms defined here are intended to be the core of a
   "transition toolbox" -- a growing collection of techniques that
   implementations and users may employ to ease the transition.  The
   tools may be used as needed.  Implementations and sites decide which
   techniques are appropriate to their specific needs.

When I mentioned operators (including my home ISP) that happily
operate dual stack, I was certainly assuming CPE NAT, and operators
that have enough IPv4 space for one-address-per-customer.

Clearly operators that aren't in that position will make a different
trade-off. That's been driving a great deal of work in the last few
years: CGN for NAT444, 100.64.0.0/10, NAT64/DNS64, DS Lite, XLAT and more.

I just don't see the point in defining some sort of "official"
position of the IETF. Who does that help?

   Brian

---

From: Ross Chandler <[email-masked]>
Date: Tue, 5 Aug 2014 22:05:49 +0100

> Comments, criticisms, suggestions, pull requests would be very welcome!

What’s your position on NAPT44 being put in front of an IP service address pool that used RFC1918 space?
Not advocating for that but it would inevitably be tried. 

Ross

---

From: Philip Homburg <[email-masked]>
Date: Tue, 05 Aug 2014 23:06:57 +0200

>to real money out in the real world.

I think it is safe to say that providing good IPv4 service is the most
important requirement. In many cases, it is perfectly fine to not provide
any IPv6 if it cannot be provided at reasonable cost / performance.

So what recent proposals are doing to make providing IPv4 more complex under
the assumption that it is actually important to provide IPv6.

(note, looking at this from business point of view. Not as somebody who
care about the future of the internet).

So instead of doing a relatively straightforward NAT44 or NAT444 and then
let IPv6 pay for itself, you now make the cost of providing IPv6 part of the
cost of providing IPv4.

In essence, your IPv4 network now got more expensive. 

In some cases, mobile operators, very big cable ISPs that run out of RFC-1918,
it makes sense to translate or tunnel IPv4.

In other cases, this kind of complexity is likely to backfire some time in
future.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 05 Aug 2014 23:39:57 +0200

>should stop digging instead of getting ourselves a new shovel...

The IETF has ignored NAT44 for a very long time. Most home users don't
actually have IPv4 access: they have a middle box that breaks things.

Outside the IETF (and I assume to a large extent also inside the IETF) people
will find this line of reasoning overly pedantic. To them, NAT44 is just 
part of the Internet.

We can also be pedantic about 'dual stack' and refer to v6+v4 or v6+NAT44 or
v6+NAT444.

However I think the meaning of dual stack is the concept that IPv4 and IPv6
are independent. Neither is tunneled over or translated into the other.

In that sense, whether IPv4 is native or behind a CGN is not relevant. We
matter is that IPv6 is completely independent of that.

>within a single administrative domain.

No operator likes tunnels. 6RD is not considered 'native IPv6', it is a
second class citizen. 

Personally I think tunneling IPv6 locally over IPv4 works very well. But
there seem to be very few people who agree with that point of view.

>not, make sure the drafts properly document the limitations causing the

The thing is that in the IPv4 world, probably every coding mistake you
can imagine is out there somewhere. Anything that differs from the way
IPv4 is normally done, may cause things to fail in some small fraction of
systems.

To give a concrete example. The obvious solution to a lower MTU is actually
path MTU discovery, but that doesn't work, so we do MSS clamping.

Out in the field are middle boxes that break MSS clamping. 

The reason those boxes work is that every server supports an MTU of 1500.
If your server doesn't, things break.

>adds up to significant savings.

Except that any truely internal server, you can already run on IPv6-only.
No need to change anything in your front-end to do that.

>--source 64:ff9b::192.0.2.100 --protocol tcp --dport ssh -j ACCEPT

Now we wait for somebody to type 64:ff9b::192.0.2.0/24 instead of
64:ff9b::192.0.2.0/120.

Also, this not in canonical form. So any program that outputs these address
uses a different syntax. Try grepping your firewall config for an address
you see in tcpdump and not finding it.

And I wonder howmany people understand this notation at all.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Aug 2014 17:48:17 -0400

> And I wonder howmany people understand this notation at all.

Gnaagh!   I really hope people aren't configuring their firewalls this way, but I don't have much operational involvement with firewalls, so maybe they do?   This seems hopelessly primitive and error-prone.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2014 10:36:46 +1200

> Not advocating for that but it would inevitably be tried. 

s/would be/has been/

That's exactly why 100.64.0.0/10 was reserved.

    Brian

   Brian

---

From: Tore Anderson <[email-masked]>
Date: Wed, 06 Aug 2014 08:04:55 +0200

* Ross Chandler

> What’s your position on NAPT44 being put in front of an IP service 
> address pool that used RFC1918 space? Not advocating for that but it
> would inevitably be tried.

I find this undesirable for several reasons. From the top of my head:

1) The NAPT44 device needs to maintain per-flow state for each flow.
This creates some new undesirable scaling properties, in particular
limitations on concurrent flow count and and flow initiation rate which
generally are reached long before the available interface bandwidth is
exhausted. This in turn typically makes such boxes be the first thing to
stop working under DDoS attacks, as the flow table gets filled up with
junk flow entries, and/or that new flow entries cannot be added to the
table fast enough.

2) Related to #1, NAPT44 devices tends to be much more expensive than
stateless devices, because they are much harder to implement and scale.
A normal IP router that can forward, say, 50 Gbps of mostly HTTP traffic
is quite affordable. A NAPT44 device/blade that can do the same gets
much more expensive (and that extra expense would probably come in
addition to the router that you're likely to need anyway).

3) All packets in a single flow must pass bi-directionally across a
single NAPT44 instance. This causes a new set of challenges:
3a) You cannot scale the solution horizontally by adding more NAPT44
boxes and using e.g. ECMP to balance across them. If you've reached
the limit of what your NAPT44 device can do, you'll have to buy a
bigger one.
3b) The device might rewrite the source address of the end users to a
pool assigned to the NAPT44 device itself. This ensures return traffic
is routed back to the NAPT44 device, but also means that the source
address of the end user is lost, and that the application has no way
of doing stuff like Geo-Location or otherwise track users based on IP.
3c) If the device does not rewrite the source address, then you must
point your default route at it, which means that all the traffic in
your network must pass through it (even traffic that did not need to
undergo NAT!) making it an even more attractive DDoS target. (Or, you
could avoid this at the expense of added complexity, by having a
separate VRF for NAPT44-bound traffic).
3d) You cannot do closest exit/hot potato routing, you must backhaul
the return traffic to the NAT instance that handled the initial inbound
packet. This can be avoided by buying NAPT44 devices for each location,
which in turn will add to your CapEx and OpEx.
3e) Failure events are highly disruptive. If your primary NAPT44 box
goes down and traffic is redirected onto the backup, every single flow
is reset. Or, you could have an implementation that did some form of
continuous replication of the state table from the primary to the
backup, which complicates the implementation even more and probably
makes it more expensive.

4) NAPT44 does absolutely nothing to help me deploy IPv6. Quite the
contrary, such an undertaking actually be quite damaging to IPv6
deployment - my time and budgets are finite, and any time and budget
that go into deploying and maintaining a NAPT44 solution is time and
budget that won't get spent on deploying IPv6. However, the NAPT44 does
not give me a pass on deploying IPv6, which means that I have that
ordeal to look forward to anyway. I would much rather have to do only 1
painful migration project rather than 2 (or 3, if you count the eventual
removal of IPv4 from throughout your infrastructure).

For me, deploying NAPT44 seems like a terribly shortsighted effort that
comes with a number of undesirable technical limitations. At best it
would be akin to treading water; I'd much rather be swimming for shore.

All of that said, YMMV; if you or anyone else use NAPT44 in your data
centres, and are happy with it, then that's great, I have no
philosophical/"religious" objections to that. I just need an alternative
for myself, and preferably make it into one that others could use too,
if they are in a situation similar to mine.

Tore

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Aug 2014 08:59:07 +0200 (CEST)

> is that IPv6 roaming Just Works.

I've heard reports of platforms in use in southeast asia, I don't remember 
if it was Korea or some other country, would fail when presented with 
IPv4v6 capability.

The reason why people are not going for IPv4v6 externally is because it 
breaks things, badly, it seems, due to bugs. So this is why IPv6 only 
bearer is so appealing, because it's been around for 5-10 years and very 
few things break with it.

> Telenor came to the same conclusion.

The scary part isn't enabling IPv6, it's enabling IPv4v6 or capability to 
do so. When advertised as capability to visiting SGSN it might refuse to 
bring up any bearer at all. So this is why the draft suggests it might be 
a good idea to not advertise this to roaming partners.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ross Chandler <[email-masked]>
Date: Wed, 6 Aug 2014 08:20:24 +0100

> if they are in a situation similar to mine.

Good, glad that you cleared that up. Include them in the next revision of your draft?  
FWIW I can see this stateless approach being useful to people that have chosen 
to make their DCs IPv6 only but still need to let the IPv4 Internet connect to public
facing servers in it. 

Ross

---

From: Tore Anderson <[email-masked]>
Date: Wed, 06 Aug 2014 09:29:21 +0200

(Changing the subject like Ross did.)

* Mikael Abrahamsson

> I've heard reports of platforms in use in southeast asia, I don't
> remember if it was Korea or some other country, would fail when
> presented with IPv4v6 capability.
> 

Yep, and to be clear, Telenor Norway does not support the IPv4v6 on
their IPv6-capable APN (nor does Tele2/Network Norway). Furthermore,
Telenor only supports IPv6 (not IPv4), while Tele2/NwN supports both
IPv6 and IPv4.

Which leads me to a point I forgot to mention before, if Telenor had
used Roaming Protocol = IPv4 as Ross suggested, or if the phone RIL did
a similar fallback, it would actually ascertain failure, since the APN
doesn't allow IPv4. If IPv6 fails, one would have to change to one of
the IPv4-only APNs.

> The scary part isn't enabling IPv6, it's enabling IPv4v6 or capability
> to do so. When advertised as capability to visiting SGSN it might refuse
> to bring up any bearer at all. So this is why the draft suggests it
> might be a good idea to not advertise this to roaming partners.

Yes, the -02 draft makes it much clearer than previous versions that
this concern is applicable specifically for IPv4v6 and not for IPv6.

In spite of this I see that some providers that are using IPv6 and home
routing chose to set the Roaming Protocol to IPv4. This is what I don't
quite understand the reason for. Perhaps due to a misunderstanding that
the problems IPv4v6 also apply for IPv6, or some other problem I have
yet to come across?

I don't really know much about what's going on "under the hood" in
mobile networks to be honest, but with my "dumb user" hat on I can
conclude that IPv6 roaming seems to work just fine with the way Telenor
and Tele2/NwN have implemented it. So I'm happy. :-)

Tore

---

From: Ross Chandler <[email-masked]>
Date: Wed, 6 Aug 2014 08:47:59 +0100

Subject line updated.

On 6 Aug 2014, at 07:59, Mikael Abrahamsson <[email-masked]> wrote:

> The scary part isn't enabling IPv6, it's enabling IPv4v6 or capability to do so. When advertised as capability to visiting SGSN it might refuse to bring up any bearer at all. So this is why the draft suggests it might be a good idea to not advertise this to roaming partners.

AFAIK the reports of problems that I assume the roaming-analysis draft came out of are a couple of years old.

It would be nice to have fresh measurements of how bad the problem is now. If an operator with lots of roamers in the areas previously seen affected to turn it on again for 15 minutes and see what happens.

I contacted the vendor I heard mentioned. They said they weren’t the only one but that the problem dated from 2008 code which has long since been patched.

Ross

---

From: Ross Chandler <[email-masked]>
Date: Wed, 6 Aug 2014 09:34:08 +0100

On 6 Aug 2014, at 08:29, Tore Anderson <[email-masked]> wrote:

> Furthermore, Telenor only supports IPv6 (not IPv4), while Tele2/NwN supports both
> IPv6 and IPv4.

If it is a new IPv6 only APN, without the HLR/HSS settings to allow fallback and they’ve bilaterally confirmed with all their roaming partners that IPv6 is allowed out it is more understandable. But I’m not sure that is what this is.
 
> the problems IPv4v6 also apply for IPv6, or some other problem I have

The two issues that I keep seeing mentioned are: The SGSN/MME has to allow IPv6  in the user plane for visitors. 
It isn’t certain that it will. The CDR mediation system has to be not fall over when it sees a 128-bit IPv6 address. 
I haven’t heard of anyone doing anything with the addresses in CDRs. AFAIK they are usually (always?) 
discarded by the mediation system.

Regards,
Ross

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Aug 2014 12:07:45 +0200

In your letter dated Wed, 06 Aug 2014 08:04:55 +0200 you wrote:
>* Ross Chandler
>
>> What=92s your position on NAPT44 being put in front of an IP service =
>

As far as I can tell, your proposal maps every public IPv4 address to a
unique IPv6 address.

In that context, why not just use, for example, host routes to route IPv4
traffic to the right interface of an IPv4 host.

No need for any kind of NAT, translation or anything.

I.e. in the situaiton you describe there are enough addresses that there is no
need for NAT.

---

From: Tore Anderson <[email-masked]>
Date: Wed, 06 Aug 2014 12:50:33 +0200

* Philip Homburg

> As far as I can tell, your proposal maps every public IPv4 address to a

Correct.

> traffic to the right interface of an IPv4 host.

That would work, but there's a few reasons why I don't consider that
optimal either:

- It would not help me with IPv6 deployment at all, it distracts me from
it. Having a fully IPv6-enabled infrastructure is the goal I want to be
moving towards. SIIT-DC, like MAP and DS-Lite, *requires* IPv6.

- I'd still need to maintain IPv4 throughout my infrastructure. If I'm
also doing IPv6 at the same time, this means I incur extra operational
overhead and cost compared to single stack - "dual everything", as Gert
said.

- There would be no way to aggregate all the host routes, it would
severely pollute my IGP as every single /32 route must be distributed
throughout my network. SIIT-DC, on the other hand, requires no host
routes, as IPv4 traffic will be typically be translated to the server's
primary IPv6 address, creating no extra IGP routes beyond the /64 or
whatever that's routed to the LAN segment anyway.

- You get interesting routing challenges if the servers need occasional
Internet access through a stateful NAT (e.g., to download software
updates). You'll want to route the traffic sourced from the public
address directly out to the Internet, while traffic from RFC1918 sources
needs to be routed through the NAT instance. But both the NAT and no-NAT
route must necessarily be represented as an IPv4 default route. I'm sure
this could be solved with the use of PBR and/or VRFs, but that incurs
extra complexity. An SIIT gateway is on the other hand reached with a
normal /96 route, and does not need to interfere with default routing at
all. Same goes for a NAT64 instance that could be used for occasional
Internet access analogous to the above.

- You'll actually need special configuration on the servers, setting up
and monitoring a secondary service address. With SIIT-DC, there is no
need to touch the servers at all, except in the case where a host agent
is needed to facilitate applications that do not support NAT and/or IPv6.

- The host routes would need to be installed on each the upstream
routers serving as default gateways for the servers' LAN segments, which
scatters these assignments all over the place. With SIIT-DC, the SIIT
gateways have a complete overview of all configured mappings and what
service addresse are available.

All in all it feels to me more like a stop-gap solution that only deals
with IPv4 depletion, rather than something that also facilitates real
progress towards an single-stack IPv6 infrastructure.

(BTW: I've made the assumption that you mean that the server's primary
IPv4 addresses is a private/RFC1918 one, which is then used as the
next-hop for a public /32 assigned to the loopback interface. Let me
know if this assumption was incorrect.)

Tore

---

From: Gert Doering <[email-masked]>
Date: Wed, 6 Aug 2014 14:32:43 +0200

Hi,

> traffic to the right interface of an IPv4 host.

Why do you find it so hard to accept that "dual-stack inside" is not
a desirable property?

Gert Doering
        -- NetMaster

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 6 Aug 2014 12:39:35 +0000

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Tore
> Anderson
> Sent: Wednesday, August 06, 2014 9:29 AM
> To: Mikael Abrahamsson
> Cc: IPv6 Ops WG
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-
> analysis-02.txt

> Yep, and to be clear, Telenor Norway does not support the
> IPv4v6 on their IPv6-capable APN (nor does Tele2/Network
> Norway). Furthermore, Telenor only supports IPv6 (not IPv4),
> while Tele2/NwN supports both
> IPv6 and IPv4.
>
> Which leads me to a point I forgot to mention before, if
> Telenor had used Roaming Protocol = IPv4 as Ross suggested,
> or if the phone RIL did a similar fallback, it would actually
> ascertain failure, since the APN doesn't allow IPv4. If IPv6
> fails, one would have to change to one of the IPv4-only APNs.

Tore,

Let me try to clarify.

The APN settings set at the UE (handset) are telling the UE
what to 'request' from the mobile network (e.g. APN name to
connect to, PDP type ipv4 or ipv6 or ipv4v6...). The mobile
network is than comparing what was 'requested' by the UE/subscriber
with subscriber's profile at the HLR/HSS. I can be that the
network will allow both IPv4/IPv6, but the UE will be configured
to request IPv6 at home and IPv4 while roaming, so it won't break.

Some UEs such as Android since some version I cannot recall
offer to specify the Home network PDP Type to control what
will the UE request while at the Home network and a dedicated
PDP Type setting for roaming, so that a different PDP Type
can be used if necessary.

> Tore

Ales

Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde  http://www.t-mobile.cz/zasady. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here http://www.t-mobile.cz/principles. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer.

---

From: Gert Doering <[email-masked]>
Date: Wed, 6 Aug 2014 14:41:45 +0200

Hi,

> any IPv6 if it cannot be provided at reasonable cost / performance.

Uh.  Welcome to 2014.  Please take a look at current internet offerings
at mass market are still growing - what you'll see is "native
IPv6 plus DS-Lite (or other NAT444) for IPv4".

If someone cares about their content, they will aim to avoid the 
instabilities added by the NAT444 box on the eyeball side.  As Lorenzo
predicted about 10 years ago.

> care about the future of the internet).

*Especially* from a business point of view, adding a focus on IPv4 is
very short sighted...

> let IPv6 pay for itself, you now make the cost of providing IPv6 part of the

... and a "relatively straightforward NAT44" on the server side *is not*,
as soon as you have a data center and traffic of any noticeable volume - 
see Tore's mail about details why that is almost always undesirable.

(You might want to check the amount of money Cisco takes for a 40G-NAT44-
Card...)

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Aug 2014 16:44:03 +0200

>Why do you find it so hard to accept that "dual-stack inside" is not

I find that very easy to accept. Except that from my point of view the
proposals presented to avoid dual stack are worse. 

The way I see it, translating IPv4 into IPv6 is just going to bite you.

Now, tunneling IPv4 over IPv6 may work, if the tunneling is local and
if the tunnel preserves a 1500 octet MTU for IPv4.

At the end of the day, all externally visible stuff still has to have IPv4.
That is dual stack, no matter how you slice it.

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 6 Aug 2014 14:53:44 +0000

> From: v6ops [mailto:[email-masked]] On Behalf Of
> Philip Homburg
> Sent: Wednesday, August 06, 2014 4:44 PM
> To: Gert Doering
> >Why do you find it so hard to accept that "dual-stack
> inside" is not a
> >desirable property?
>
> I find that very easy to accept. Except that from my point of
> view the proposals presented to avoid dual stack are worse.
>
> Now, tunneling IPv4 over IPv6 may work, if the tunneling is
> local and if the tunnel preserves a 1500 octet MTU for IPv4.

I guess you're talking about a softwire, so let me cite RFC5565:

   Transmitting a packet through a softwire always requires that an
   encapsulation header be added to the original packet.  The resulting
   packet is therefore always longer than the encapsulation payload.  As
   an operational matter, the Maximum Transmission Unit (MTU) of the
   softwire's path SHOULD be large enough so that (a) no packet will
   need to be fragmented before being encapsulated, and (b) no
   encapsulated packet will need to be fragmented while it is being
   forwarded along a softwire.  A general discussion of MTU issues in
   the context of tunneled forwarding may be found in [RFC4459].

> That is dual stack, no matter how you slice it.

I think that Tore's work is showing that there are alternatives to dual-stack.

Ales

---

From: Tore Anderson <[email-masked]>
Date: Wed, 06 Aug 2014 20:34:10 +0200

* Vízdal Aleš

> can be used if necessary.

Yes, I think I've understood this part. My point is that since Telenor's
APN does not support the IPv4 PDP type, then it won't work to use IPv4
as the Roaming PDP type, as was suggested earlier in the thread. (Nor as
the Home PDP type, for that matter.) So the only sensible setting in
this case would be to use PDP type IPv6 for both the Roaming and Home
PDP type settings.

If on the other hand the APN supports both IPv4 and IPv6 (like
Tele2/NwN's does), then that is a different story, and having the UE use
IPv4 when roaming makes sense (if the roaming partners break IPv6 for
some reason).

At least that's how I understand it...

Tore

---

From: Ross Chandler <[email-masked]>
Date: Wed, 6 Aug 2014 19:55:42 +0100

> IGP topology, and so on, and so on.

Another reason why the firewall should normally be on the IPv6 side is that asymmetric traffic might be flowing through the stateless SIIT gateway. Assuming that there’s more than one of them in different parts of the network.

Ross

---

From: Ross Chandler <[email-masked]>
Date: Wed, 6 Aug 2014 20:46:04 +0100

On 6 Aug 2014, at 19:34, Tore Anderson <[email-masked]> wrote:

> At least that’s how I understand it...

It might be that when the UE visits a network that doesn’t allow IPv6 in the user-plane Android behaviour is kicking in.

I’ve been told that Android treats all APNs as “roughly equal”. 

If the new IPv6-only-without-IPv4-fallback APN fails then Android might be trying the IPv4 one.

BR
Ross

---

From: Ross Chandler <[email-masked]>
Date: Wed, 6 Aug 2014 21:23:30 +0100

> If the new IPv6-only-without-IPv4-fallback APN fails then Android might be trying the IPv4 one.

If this is what’s going on in Telenor case the plus is it maximises the number of roaming partners that come up with IPv6 but at the possible cost of indeterminism on which APN the UE settles on using when it gets back home.

Ross

---

From: Tore Anderson <[email-masked]>
Date: Thu, 07 Aug 2014 07:28:20 +0200

* Ross Chandler

>> It might be that when the UE visits a network that doesn’t allow
>> IPv6 in the user-plane Android behaviour is kicking in.
>> 
> If this is what’s going on in Telenor case the plus is it maximises
> the number of roaming partners that come up with IPv6 but at the
> possible cost of indeterminism on which APN the UE settles on using
> when it gets back home.

I'm fairly certain there is no such indeterminism.

Basically the UEs get set up to request IPv6 PDP type both home and when
roaming. So when they establish a data bearer they get IPv6 (+464XLAT)
no matter where in the world they are, or they get no data bearer at all
(if there's some sort of problem somewhere).

That Telenor feels confident in doing it in this manner is very good
news, I think. It reminds me of the World IPv6 Launch, actually - where
it was decided that the bugs and issues that had previously made it
unsafe to deploy IPv6 on a global scale (as opposed to a select few
known good networks, corresponding well to "the home PLMN only" in the
mobile case), has been sufficiently solved so that IPv6 can be made
generally available instead.

I guess now it's up to Cameron and Michał to follow suit. ;-)

Tore

---

From: GangChen <[email-masked]>
Date: Thu, 7 Aug 2014 13:58:57 +0800

2014-08-06 2:22 GMT+08:00, Ross Chandler <[email-masked]>:
> According to the manual my SGSN-MMEs have an “AllowIPv6ForAllVisitors”
> parameter that has to be set true to allow IPv6 PDP/PDN connections be
> set-up be visitors.
>
> Out of the box the SGSN-MME had userplane IPv6 enabled for home users. It
> needed the DAF flag to be set (to allow dual-stack in a single bearer).
>
> Proposal for  addition to the draft - it should mention “IPv6 Roaming
> friendly operator” settings (user plane IPv6 allowed, DAF=1 if possible) on
> how to make your network friendly for visitors.

It make sense. I guess the meaning of “AllowIPv6ForAllVisitors”
parameter is to enable SGSN validating the Activate PDP Context
Request with IPv6-only PDP type and sending a Create PDP Context
Request with IPv6-only PDP to GGSN/PGW.

Gang

---

From: Ross Chandler <[email-masked]>
Date: Thu, 7 Aug 2014 07:50:39 +0100

> Request with IPv6-only PDP to GGSN/PGW.

Yes. That command is from an Ericsson SGSN-MME.  It is set with the modify_ne command.  It would be good if the vendors now make this on by default.
It is also necessary to have IPv6 user-plane allowed for home users but that is already on by default. 

The draft should also clearly make the point that the operator doesn’t have to yet be at the stage of offering IPv6 or IPv4v6 based Internet through their own GGSN/PGW.
Ironically it is easier to let others use your RANs for IPv6 than it is to do it yourself.

BR
Ross

---

From: GangChen <[email-masked]>
Date: Thu, 7 Aug 2014 15:18:05 +0800

> the problems IPv4v6 also apply for IPv6, or some other problem I have

Setting roaming APN with IPv4 is recommended in local breakout mode.
As described in
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-02#section-5.3,
IPv6-only PDP/PDN can't be failed over to IPv4. In your case, I guess
traffic is home routed. When a Telenor customer roams Tele2/NwN, All
PDP/PDN request and traffic will back to Telenor network. Therefore,
it works. However, it increases the international data roaming fees to
customers, since Telenor has to pay GRX/IPX carrier for the
international traffic transit. In order to reduce the cost, local
breakout is an optimized approach. It will save the charge for GRX/IPX
transit and improve data service performance. In that case, I guess
the Telenor customer has to check if roaming APN set to IPv4-only,
since the visited network may not able to allocate IPv6 to customers.

BRs

Gang

---

From: GangChen <[email-masked]>
Date: Thu, 7 Aug 2014 15:28:04 +0800

2014-08-07 14:50 GMT+08:00, Ross Chandler <[email-masked]>:
>
> The draft should also clearly make the point that the operator doesn’t have
> to yet be at the stage of offering IPv6 or IPv4v6 based Internet through
> their own GGSN/PGW.

You mean apps could use ipv6 over ipv4 to use RAN? In my experience,
it may not be able to get good performance compared to native
implementation of IPv6 support in the mobile phone. For example, RAN
performs IPv6 header compression to optimize the performance. apps
can't get those benefits.

Gang

---

From: Tore Anderson <[email-masked]>
Date: Thu, 07 Aug 2014 09:37:33 +0200

* GangChen

> In your case, I guess traffic is home routed. When a Telenor customer
> roams Tele2/NwN, All PDP/PDN request and traffic will back to Telenor
> network. Therefore, it works.

Yep, exactly. I am assigned addresses from Telenor's prefixes when I
roam (both for IPv4 and IPv6 APNs). Same thing for Tele2/NwN.

> However, it increases the international data roaming fees to 
> breakout is an optimized approach.

I don't think any of the Norwegian providers allow/support their
subscribers to do local breakout. I assume this is a service the visited
network cannot offer to the roamer without the home network's blessing?

[ If the visited network can do this without the home network's
blessing, that would have made for a extremely nice product for
travelers. Imagine if I could just have entered a new APN name
"internet.gangchen" when I visit your country and roam in your PLMN,
punch in my credit card details in a captive portal and from then on
been able to use mobile internet at reasonable local rates... No more
bothering with getting pre-paid data SIMs from local providers and such
anymore..! ]

> It will save the charge for
> GRX/IPX transit and improve data service performance.

I think Telenor (and all the other providers around here for that
matter) are happily enjoying near-criminal profit margins on those
expenses, so I'm kind of doubting I'll see local breakout being offered
or encouraged anytime soon...but I guess time will tell.

Tore

---

From: GangChen <[email-masked]>
Date: Thu, 7 Aug 2014 16:27:08 +0800

> network cannot offer to the roamer without the home network's blessing?

It's a business matter more than technical concern. Most operators
adopt home routed because it facilitates charging. GGSN/PGW in the
home land could get precise traffic volume a customer generates. Other
consideration is for lawful interception.

> bothering with getting pre-paid data SIMs from local providers and such

That is exact experience EU-Roaming-III would like to achieve.

> or encouraged anytime soon...but I guess time will tell.

Voice traffic based on IMS does local breakout mode as per GSMA
regulation. For the data service, China Mobile adopts local breakout
mode when customers perform Intra-PLMN mobility(more detailed is
described in section 2 of the draft). There is also ongoing effort to
promote local breakout for data roaming in Asian area. Anyway, that is
the topic mainly regarding to business perspective.

Gang

---

From: Ross Chandler <[email-masked]>
Date: Thu, 7 Aug 2014 09:39:11 +0100

> can't get those benefits.

No.  I’m noting that the first stage for a Mobile operator in adopting IPv6 in the user plane is to prepare their RANs and SGSN/MMEs for it.

When that is done an easy next step is to let visitors from other operators that are ahead in deploying IPv6 establish IPv6 PDP/PDN connections to their home GGSN/PGW.

That scenario can happen, and is happening, already, as per Tore’s and others comments.

Ross

---

From: GangChen <[email-masked]>
Date: Thu, 7 Aug 2014 17:21:39 +0800

2014-08-07 16:39 GMT+08:00, Ross Chandler <[email-masked]>:

> No.  I’m noting that the first stage for a Mobile operator in adopting IPv6
> in the user plane is to prepare their RANs and SGSN/MMEs for it.
>
> When that is done an easy next step is to let visitors from other operators
> that are ahead in deploying IPv6 establish IPv6 PDP/PDN connections to their
> home GGSN/PGW.
>

I guess I get your point. Whether the first stage can be done is
depending on the business contract. Let's say, if the SGSN in visited
networks can't support IPv6 and RAN can't do ROHC, the visited
operator have to pay for each function. I guess the business
negotiation is probably going to IPv4. But I guess we could try to add
sentences in the draft to state how to support IPv6-only roamer.

Gang

---

From: Ross Chandler <[email-masked]>
Date: Thu, 7 Aug 2014 10:41:16 +0100

> sentences in the draft to state how to support IPv6-only roamer.

Yes, I think we should.

On the commercial aspects RFC 6540 requires IPv6 support in all IP-Capable nodes. 

So I assume vendors will support the default IP protocol and not look for extra payments on top of business as usual spending.

My own experience was that all the features I need (except the HLR PDP-Ext-Type restriction) were just there.

Ross

---

From: <[email-masked]>
Date: Thu, 7 Aug 2014 12:47:40 +0200

> No.  I'm noting that the first stage for a Mobile operator in adopting IPv6 in the user plane is to prepare 
> their RANs and SGSN/MMEs for it.

> When that is done an easy next step is to let visitors from other operators that are ahead in deploying IPv6 
> establish IPv6 PDP/PDN connections to their home GGSN/PGW.

But then, ticking the correct "I am IPv6 capable" and "I am IPv4v6 capable" boxes in the IR.21 database should not be forgotten...

Holger

-- 
Holger Metschulat 
Deutsche Telekom Technik GmbH 
Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt 
+49 6151 58 - 18671 (Tel.) 
+49 160 901 35443 (Mobil) 
E-Mail: [email-masked] 
http://www.telekom.de 
Erleben, was verbindet.  
Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik
Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

---

From: Ross Chandler <[email-masked]>
Date: Thu, 7 Aug 2014 11:53:50 +0100

> But then, ticking the correct "I am IPv6 capable" and "I am IPv4v6 capable" boxes in the IR.21 database should not be forgotten...

Yes. There should be a reference to their IR.21 responsibilities. 

Ross

---

From: Tore Anderson <[email-masked]>
Date: Thu, 07 Aug 2014 12:55:57 +0200

* Ross Chandler

> Good, glad that you cleared that up. Include them in the next

Certainly - what do you think about this?

http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html#rfc.appendix.B

Tore

---

From: Ross Chandler <[email-masked]>
Date: Thu, 7 Aug 2014 12:16:30 +0100

On 7 Aug 2014, at 11:47, <[email-masked]> <[email-masked]> wrote:

> But then, ticking the correct “I am IPv6 capable" and "I am IPv4v6 capable" boxes in the IR.21 database should not be forgotten...

AFAIK the latest version of IR.21 is version 9.1 (05 July 2013)

Relevant sections look like:

Section ID: 16   on Packet Data Services Information

Section ID: 20   on LTE Roaming Information

Both are optional sections, but it is clearly good practise to update them, and seeing entries being made should help encourage other operators to also deploy IPv6.

Ross

---

From: Lee Howard <[email-masked]>
Date: Wed, 06 Aug 2014 19:52:07 -0600

>any IPv6 if it cannot be provided at reasonable cost / performance.

Is that safe to say?
Based on the current discussion, I can't tell if that's the consensus.
For instance, is it fine not to provide any IPv4 if it cannot be provided
at reasonable cost/performance?

I generally say, "IPv6 is not the goal--connectivity is the goal. IPv6 is
the solution."  The implication is that IPv6 is the solution when IPv4
does not acceptable connectivity (good/fast/cheap enough).

>care about the future of the internet).

Layer 8 considerations aren't always appropriate for IETF documents, but
it is generally useful to bear them in mind when writing them. So, is
there a way to phrase this appropriately?

For instance, if growth (for example) is forcing IPv4 to become more
complex (or expensive, or to perform poorly), then a proposal that makes
IPv4 more complex than it currently is  might actually reduce complexity
in the future.  That could be included as a consideration, use case, or
recommendation, if there's consensus for it.

>In other cases, this kind of complexity is likely to backfire some time in

If, indeed, we're talking specifically about Tore's SIIT document, it
would be more useful if we could describe the cases where it does and does
not make sense. Would you find it to be useful, then?

Lee

---

From: Philip Homburg <[email-masked]>
Date: Thu, 07 Aug 2014 14:56:22 +0200

>not make sense. Would you find it to be useful, then?

One of my replies to Tore already contains an example. Middle box implements
MSS clamping wrong. This breaks IPv4 for any service that has a path MTU of
less then the PPPoE MTU.

So this would break with the proposed SIIT solution.

---

From: Ca By <[email-masked]>
Date: Thu, 7 Aug 2014 05:56:59 -0700

> I guess now it's up to Cameron and Michał to follow suit. ;-)

I agree, for my own phone, i roam internationally with no issue on ipv6.

CB _______________________________________________

---

From: Ca By <[email-masked]>
Date: Thu, 7 Aug 2014 06:06:55 -0700

> >any IPv6 if it cannot be provided at reasonable cost / performance.

No.

20% of my subscribers are ipv6-only and for them the majority of the
traffic is ipv6. For these subscribers, it is quantitatively most important
that ipv6 works. Qualitatively, it is most important the most impactful
services like facebook, google, and netflix work on ipv6.

I am guessing by the end of the year the 20% of subscribers number goes
closer to 50%. The 'x factor' is iPhone adopting 464xlat or not.

Apple -- please support rfc6877

Regards,

CB

PS. thanks to msft, windows phone now supports 464xlat.

https://dev.windowsphone.com/en-US/OEM/docs/Customization/Additional_Internet_APN_settings

:)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Aug 2014 22:13:02 +0900

> services like facebook, google, and netflix work on ipv6.
Right. An operator cannot afford not to provide IPv4, because "that's not
Internet". But if the majority of traffic is IPv6, then the operator can
provide proportionally lower quality of service to IPv4 without disrupting
user experience.

A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45%
NAT64, and ~5% 464xlat. 464 conversion is lossy and brittle, but if it's
only used for 5% of traffic, then the operator might just say, "Who cares?
I don't; and if somebody else does, they're free to use IPv6."

---

From: Dave Michaud <[email-masked]>
Date: Thu, 7 Aug 2014 13:16:05 +0000

IPv4v6 is broken when roaming, that is a fact and I have a huge list of providers that are broken in that scenario.

As for IPv6 while roaming, it has been supported for a long time but there is still a fair share of operators who for various reasons don’t allow it.

When I’m abroad, I always make a point to test all operators on IPv6-only and always see a lot of failure. This becomes especially apparent if the home operator performs some steering of roaming targeted to an operator that doesn’t allow IPv6.

That’s why in the meantime, we are doing IPv6 at home and IPv4 while roaming (with the APN configured to support both on the core network).

Dave Michaud

From: v6ops [mailto:[email-masked]] On Behalf Of Ca By
Sent: Thursday, August 07, 2014 8:57 AM
To: Tore Anderson
Cc: IPv6 Ops WG
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-02.txt

> https://www.ietf.org/mailman/listinfo/v6ops

________________________________
This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice<http://www.rogers.com/web/content/emailnotice>

Ce message est confidentiel. Notre transmission et réception de courriels se fait strictement suivant les modalités énoncées dans l’avis publié à www.rogers.com/aviscourriel <http://www.rogers.com/aviscourriel>
________________________________

---

From: Ross Chandler <[email-masked]>
Date: Thu, 7 Aug 2014 14:17:45 +0100

> I agree, for my own phone, i roam internationally with no issue on ipv6.
Cameron,

Are you saying the support for IPv6 in the user-plane for visitors is good enough for enthuasists willing to toggle their APN protocol setting when they roam or that the position is already so good that we can all start copying Telenor?

BR
Ross

---

From: Ross Chandler <[email-masked]>
Date: Thu, 7 Aug 2014 14:35:34 +0100

> When I’m abroad, I always make a point to test all operators on IPv6-only and always see a lot of failure. This becomes especially apparent if the home operator performs some steering of roaming ta…

Steering of roaming sounds like a failure mode that should be mentioned in the draft.

BR
Ross

---

From: Ca By <[email-masked]>
Date: Thu, 7 Aug 2014 06:58:55 -0700

On Aug 7, 2014 6:17 AM, "Ross Chandler" <[email-masked]> wrote:
> Are you saying the support for IPv6 in the user-plane for visitors is
good enough for enthuasists willing to toggle their APN protocol setting
when they roam or that the position is already so good that we can all
start copying Telenor?
> Ross

If Telenor has taken this leadership position, then i expect those few
lingering issues to be resolved quickly with the problem network operators.

It is worth revisiting the data before changing default settings.

In my own network,  roaming makes up for a very small percentage of ip
address usage, so the benefit is not very high

CB

---

From: Gert Doering <[email-masked]>
Date: Thu, 7 Aug 2014 17:32:20 +0200

hi,

> MSS clamping wrong. This breaks IPv4 for any service that has a path MTU of

"Broken Middleboxes break Service Delivery", news at 11.

Gert Doering
        -- NetMaster

---

From: Ross Chandler <[email-masked]>
Date: Thu, 7 Aug 2014 17:06:33 +0100

On 7 Aug 2014, at 14:58, Ca By <[email-masked]> wrote:

> If Telenor has taken this leadership position, then i expect those few lingering issues to be resolved quickly with the problem network operators.
> 
Exciting times. This should be a further catalyst for progress.

Ross

---

From: Tore Anderson <[email-masked]>
Date: Thu, 07 Aug 2014 20:12:37 +0200

* Philip Homburg

> One of my replies to Tore already contains an example. Middle box
> implements MSS clamping wrong. This breaks IPv4 for any service that
> has a path MTU of less then the PPPoE MTU.

You're quite right that the header size difference between IPv4 and IPv6
is something one would need to consider. This consideration is similar
to that to other tunneling or translation mechanisms like GRE, DS-Lite,
MAP, 6RD, PPPoE and so forth. There are some differences though:

- It is only really a concern for packets flowing in the client->server
direction (IPv4->IPv6), as a 1500 byte large packet originated by the
IPv6 server would be translated into a 1480 byte large IPv4 packet,
which isn't problematic. (For content providers, most large packets go
in the unproblematic server->client direction.)

- All potential issues can be mitigated by raising the MTU by 20 bytes
(to 1520) in the IPv6 domain (to 1520). While this is of course true for
all the other mechanisms I mentioned too, actually doing it is likely to
be easier to do in a data centre environment than e.g. in an ISP's
access network.

- There is no need for TCP MSS clamping, as the IPv6 servers will
advertise an appropriate TCP MSS to the clients (1440). This causes the
IPv4 clients to limit their packet size to 1480, which translates into
1500 byte large IPv6 packets.

- Finally, for protocols other than TCP (and other protocols that have a
mechanism similar to TCP's MSS), there are two things that can happen
for IPv4 packets larger than 1480 bytes destined for an IPv6 server
(assuming the IPv6 domain's MTU is 1500):
  - If the DF flag is set, it's PMTUD time, as the SIIT gateway will
    emit an ICMPv4 Fragmentation Needed packet. This is likely
    unreliable.
  - If the DF flag isn't set, it results in a fragmented IPv6
    packet. This can be reliable, as the fragmented packets do not
    propagate out of the data centre, and as such the operator can
    ensure that they work.

In any case, the draft already discusses this:

http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html#rfc.section.3.8

Please let me know if you find any of the text there is incorrect,
confusing, incomplete, or if you have other suggestions on how to
improve it.

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 8 Aug 2014 09:26:22 +0900

> Telenor came to the same conclusion.

I know for sure it doesn't work with on NTT docomo. It used not to work on
Softbank either. That was 2 out of 2 GSM operators in Japan, so if you had
a GSM handset, well, no Internet for you.

---

From: GangChen <[email-masked]>
Date: Fri, 8 Aug 2014 08:51:55 +0800

2014-08-07 21:35 GMT+08:00, Ross Chandler <[email-masked]>:
>> When I’m abroad, I always make a point to test all operators on IPv6-only
>> and always see a lot of failure. This becomes especially apparent if the
>> home operator performs some steering of roaming targeted to an operator
>> that doesn’t allow IPv6.
>> Dave Michaud
>

Are you using VPLMN-Dynamic-Address-Allowed flag to steer roaming?

---

From: Ca By <[email-masked]>
Date: Thu, 7 Aug 2014 18:24:09 -0700

On Aug 7, 2014 5:26 PM, "Lorenzo Colitti" <[email-masked]> wrote:
> I know for sure it doesn't work with on NTT docomo. It used not to work
on Softbank either. That was 2 out of 2 GSM operators in Japan, so if you
had a GSM handset, well, no Internet for you.

A fix is to choose softbank as a roaming partner and to bar ntt

CB

---

From: GangChen <[email-masked]>
Date: Fri, 8 Aug 2014 09:25:12 +0800

2014-08-07 19:16 GMT+08:00, Ross Chandler <[email-masked]>:
>> But then, ticking the correct “I am IPv6 capable" and "I am IPv4v6
>> capable" boxes in the IR.21 database should not be forgotten...
>
> Both are optional sections, but it is clearly good practise to update them,
> and seeing entries being made should help encourage other operators to also
> deploy IPv6.

Yes. Uploading your IR.21 database with IPv6 capable and IPv4v6
capable is definitely helpful. Should this be encouraged in the draft?

Gang

---

From: Ross Chandler <[email-masked]>
Date: Fri, 8 Aug 2014 05:45:13 +0100

> Are you using VPLMN-Dynamic-Address-Allowed flag to steer roaming?

AFAIK in this case it is an aggressive process of snooping on Gr and rejecting networks until on you like comes up.

Ross

---

From: Jouni <[email-masked]>
Date: Fri, 8 Aug 2014 07:45:35 +0300

> Are you using VPLMN-Dynamic-Address-Allowed flag to steer roaming?

Without knowing the details in this case but steering of roaming
usually means affecting the PLMN selection the UE does.. e.g. by
purposely failing signaling on the network side until a desired
PLMN gets selected or some other means.

- Jouni

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 8 Aug 2014 12:11:49 +0000

Lorenzo

For my education, do you have a pointer for a data point on:

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
A 4G handset with 464xlat will have ~50% of traffic native IPv6, ~45% NAT64, and ~5% 464xlat. 464 conversion is lossy and brittle, but if it's only used for 5% of traffic, then the operator might just say, "Who cares? I don't; and if somebody else does, they're free to use IPv6."

---

From: Dave Michaud <[email-masked]>
Date: Fri, 8 Aug 2014 12:21:03 +0000

> From: Jouni [mailto:[email-masked]]
> Sent: Friday, August 08, 2014 12:46 AM

> PLMN gets selected or some other means.

That is exactly what I was referring to. In a given country, some operators may support IPv6 and some may not. If steering of roaming pushes me towards an operator that doesn't have IPv6 support, then I'm out of luck.

The decision on which operator gets preferential treatment is purely business driven based on commercial agreement. I have little weight into telling the business to pick IPv6-friendly operator.

Then there is the case where all the operators in a given country are not IPv6 ready. This seems to be more common in the Caribbean.

Dave

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 8 Aug 2014 21:22:12 +0900

https://www.nanog.org/sites/default/files/wednesday_general_byrne_breakingfree_11.pdf

Slide 4: "Over 50% of IPv6-user traffic is end-to-end IPv6 (no translation
needed)"

The 5% number is just a guess. If you only look at the handset, then t's
just traffic from IPv4-only apps, and at least in the Android case, it's
quite hard to write an IPv4-only app - you have to really go out of your
way to do it in Java, or use native C/C++ code via JNI. The Netflix app
used to be that way, and now I think the major one is Pandora. It sort of
depends on the market though - from what I've seen on T-Mobile's deployment
it didn't take that long for the major apps to get IPv6 support (with the
exception of Skype and maybe Google Hangouts).

Tethering is still IPv4-only on T-Mobile (and on many devices), and that's
probably more than 5%.

Cameron, do you have a better estimate of how much traffic uses 464xlat?

On Fri, Aug 8, 2014 at 9:11 PM, Eric Vyncke (evyncke) <[email-masked]>
wrote:

>   From: Lorenzo Colitti <[email-masked]>
>

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Fri, 8 Aug 2014 14:19:28 +0000

Hi,
Internet traffic for OPL ipv6 -464xlat users (3G/4G)
Traffic till mid-July:
Ipv6 -60% (78% to Google)
Nat64 -40%
Traffic from mid-July up to now:
Ipv6 - 40%* (50% to Google)
Nat64- 60%

*On W28 we noticed abnormal drop of AAAA queries generated by users. It looks like some DS servers becomes Ipv4 only, or web browser ipv4 fallback takes place more often.. (we analyzing data)

Regards,
Tomasz

From: Eric Vyncke (evyncke) [mailto:[email-masked]]
Sent: Friday, August 08, 2014 2:12 PM
To: Lorenzo Colitti
Cc: IPv6 Ops WG
Subject: Re: [v6ops] Operational Consensus on deployment

Lorenzo

---

From: Ross Chandler <[email-masked]>
Date: Sat, 9 Aug 2014 20:07:56 +0100

On 7 Aug 2014, at 11:55, Tore Anderson <[email-masked]> wrote
> what do you think about this?
> 

I’m still liking it, as the advantages of an IPv6-only DC will be high.

How about the case of an IPv6-only DC network with multiple separate SIIT-DC translation prefixes (mentioned in Sec 3.4). Which translation prefix will be used in the case where DNS64 (Sec 3.3) is also being used? It seems like DNS64 might only work easily with a single translation prefix. 

Ross

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 10 Aug 2014 03:57:37 +0000

> How about the case of an IPv6-only DC network with multiple separate SIIT-DC translation prefixes (mentioned in Sec 3.4). Which translation prefix will be used in the case where DNS64 (Sec 3.3) is…

RFC 6147 is designed for one translation prefix. One could imagine a translation prefix per tenant, and you would (at least in concept) need a DNS64 per tenant. That is unless you got smart and looked at the source address of the packet to see which tenant it came from.

---

From: Ross Chandler <[email-masked]>
Date: Mon, 11 Aug 2014 08:26:35 +0100

On 11 Aug 2014, at 07:14, Geir Egeland <[email-masked]> wrote:

> So let me try to shed some light on what we are thinking in Telenor Norway.
> 
> Even though we have launched an IPv6-only APN, our main strategy for the home network is to support the Ext. PDP type. Also, both our fixed and mobile network architectures are based on DS.
> 
> We are currently working on putting the final pieces together for enabling DS. Roaming brokeness caused by the ext. PDP is a major concern for us. DS will affect our whole customer base, so it will take a while with testing before we are comfortable launching this.
> 
> Telenor Norway has been piloting NAT64/464XLAT for some time now with no major issues. We see that we need to support all scenarios for mobile devices, i.e. IPv4-only, IPv6-only and DS. We chose to launch IPv6 on a few selected devices as a gradual introduction of IPv6 in our mobile network. 
> 
> By enabling IPv6-only on a few handsets, we can identify those mobile operators that do not support IPv6-roaming and we use this opportunity to contact them through commercial and technical channels, urging them to enable IPv6 support on their SGSN. If this is unsuccessful, we will consider steering the roaming traffic away from those operators during a transition period if necessary.
> 
IMHO this will really help the IPv6 community as it provides an easy to understand message for the business on why we need to enable IPv6 in the user plane for visitors.

The draft should probably mention this risk of being steered away from by an operator that wants IPv6. At the moment the draft just mentions this in the context of the home operator’s own business steering traffic to an operator that doesn’t support IPv6 in the user-plane. 

On enabling IPv6 in the user plane the draft currently says “it’s expected that visited network is IPv6 roaming friendly to enable the functions on SGSN/MME by default”.
Do operators with it on, have it enabled for all IMSI series or do it by IMSI series? I’d like to turn it on by default for all.

> We believe it is important to take an active stand on this instead of waiting for everyone to get around to enable IPv6. As many people on the mailing list have mentioned, there are cases where roaming on IPv6 fails. This is also our experience, but it is something we are willing to accept. 
> 
> As Tore has mentioned, our customers are free to use one of our IPv4-only APNs, however, we have not had any such requests.
> 
> BR,
> 
> Geir Egeland
> Telenor Group/Telenor Norway

BR 
Ross

---

From: Tore Anderson <[email-masked]>
Date: Mon, 11 Aug 2014 09:29:15 +0200

* Fred Baker (fred)

>> How about the case of an IPv6-only DC network with multiple
>> separate SIIT-DC translation prefixes (mentioned in Sec 3.4). Which
>> translation prefix will be used in the case where DNS64 (Sec 3.3)
>> is also being used? It seems like DNS64 might only work easily with
>> a single translation prefix.
> 
> RFC 6147 is designed for one translation prefix. One could imagine a
> translation prefix per tenant, and you would (at least in concept)
> need a DNS64 per tenant. That is unless you got smart and looked at
> the source address of the packet to see which tenant it came from.

I'm thinking that multiple instances is an advanced topic that would be
better documented in a separate draft. I'd preferably like to keep this
draft concise and to the point, thus making it easy to read and understand.

In any case, multiple SIIT instances should be relatively
straightforward. If the applications in questions are server-style ones
that are merely responding to client traffic (think HTTP) then it's
really a no-brainer, as the inbound client traffic will already have a
source IPv6 address within the appropriate SIIT instance's translation
prefix, to which the server will respond accordingly automatically.

If on the other hand it's the IPv6 application that is responsible for
initiating traffic to IPv4 destinations, then it would need to choose
the appropriate translation prefix for synthesising the IPv4-mapped IPv6
address to initiate communication to. It would have to do that even if
there is only one SIIT instance, too.)

If the application is using DNS, then DNS64 could be used for this
purpose, which could be deployed in a number of ways (locally on the
server itself, dedicated DNS64 servers per SIIT instance, one DNS64
server but with multiple views per SIIT instance, ...).

Other options would be for the application to synthesise the IPv4-mapped
addresses itself according to RFC6052, in which case the choice of
translation prefix (and thus the SIIT instance) would be a configuration
options; or finally, you could use the host agent approach, in which
case the translation prefix (and thus the SIIT instance) becomes part of
the host agent's configuration instead.

Tore

---

From: Ross Chandler <[email-masked]>
Date: Mon, 11 Aug 2014 08:58:02 +0100

On 11 Aug 2014, at 08:29, Tore Anderson <[email-masked]> wrote:

> the host agent’s configuration instead.

That approach to documenting it sounds fine to me. 

Ross

---

From: Geir Egeland <[email-masked]>
Date: Mon, 11 Aug 2014 08:14:00 +0200

Hi,

Telenor Norway has been piloting NAT64/464XLAT for some time now with no major issues. We see that we need to support all scenarios for mobile devices, i.e. IPv4-only, IPv6-only and DS. We chose to launch IPv6 on a few selected devices as a gradual introduction of IPv6 in our mobile network.  By enabling IPv6-only on a few handsets, we can identify those mobile operators that do not support IPv6-roaming and we use this opportunity to contact them through commercial and technical channels, urging them to enable IPv6 support on their SGSN. If this is unsuccessful, we will consider steering the roaming traffic away from those operators during a transition period if necessary. We believe it is important to take an active stand on this instead of waiting for everyone to get around to enable IPv6. As many people on the mailing list have mentioned, there are cases where roaming on IPv6 fails. This is also our experience, but it is something we are willing to accept. 

BR,

Geir Egeland

On 07-08-14, at 15:58 , Ca By <[email-masked]> wrote:

> In my own network,  roaming makes up for a very small percentage of ip address usage, so the benefit is not very high
> 
> CB
>

---

From: Ray Hunter <[email-masked]>
Date: Sat, 16 Aug 2014 13:36:53 +0200

> Comments, criticisms, suggestions, pull requests would be very welcome!
I see these conceptually as partner documents to 464xlat (on the server 
side, rather than the eyeballs side). I therefore think it would be 
useful to bring these documents into v6ops as I-D's, especially if 
real-world operational deployment experience could be included.

-- 
Regards,
RayH

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 19 Aug 2014 14:32:56 +0000

If I may stick my neck out.

I’d like v6ops to consider at least two items:

1.       (Carrier Grade) NAT64 vs NAT44 – a deathmatch.
IMHO NAT64 should be greater or equal to NAT44 when implemented correctly.
Only NAT64 can help with both private and public IPv4 exhaustion. (Note: In cellular networks, where NAT is prevalent, private exhaustion is a big issue today, driving IMS toward IPv6-only, and data services to 464xlat).
And as highlighted below, a major proportion of traffic goes pure IPv6, reducing the load on the NAT.
Why do some people still fear NAT64 or think that NAT44 is going to move them forward? MTU issues can be fixed. 64 ALGs can matched 44. I’ve even fixed FTP issues. Literals can be fixed at the host.
Holding on to the NAT44 architecture whether in Dual Stack+NAT44 or otherwise will keep us all in the old world. If you are a large ISP thinking about public exhaustion, and your plan is to introduce privates + NAT44, then think on, perhaps you are just exchanging one exhaustion date for another.
As it stands we don’t have a consensus here.

2.       A paper to update RFC6586 about the experiences of PCs and Mobile devices on 464xlat networks

It seems about the right time for this. RFC6586 left us with some cliff hangers. Does 464xlat finish the job off? Yes or no? Where are the gaps? (“Lossy and brittle” for IP literal destinations, what does this mean?)

What is the common theme of the above?
I have seen this written in the abstract for sunset4.

   Sunsetting IPv4 refers to the process of turning off IPv4
   definitively.  It can be seen as the final phase of the migration to
   IPv6
I don’t think the world is ready for sunsetting IPv4, it appears an academic topic to many. I don’t think in v6ops we are quite ready for this final phase off turning off IPv4 “as a service”.
However I do think there is some gap to bridge in v6ops, some intermediary phase between where we are now (stuck in equilibrium with IPv4 dominant), and a point where v6 is the dominant address family on hosts.

So the theme would be “v6 dominant”, and in it would be the exhaustion beating technologies, the technologies that the IETF should champion because before we can even consider turning off v4 we need to get to state where the IPv6 address at the client/host is the dominant address family for connectivity.
Let’s face it, if you have a nice stockpile of public IPv4, you may not need to care about IPv6, and dualstack might even look like some radical approach.
Everyone else needs to collectively deal with exhaustion.
I do think we have a lot to do to get our collective story straight on this.
I think papers above would help. There might be more address saving techniques to add to the list for “experience” documents, perhaps?
New ideas here? If every Client OS had some inbuilt function to allow it to function when the network can only provide it an IPv6 prefix then what would that be? Could it remain dormant until required…
Thoughts?
Regards,
Nick

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 07 August 2014 14:13
To: Ca By
Cc: Tore Anderson; IPv6 Ops WG
Subject: Re: [v6ops] Operational Consensus on deployment

No.

20% of my subscribers are ipv6-only and for them the majority of the traffic is ipv6. For these subscribers, it is quantitatively most important that ipv6 works. Qualitatively, it is most important the most impactful services like facebook, google, and netflix work on ipv6.
Right. An operator cannot afford not to provide IPv4, because "that's not Internet". But if the majority of traffic is IPv6, then the operator can provide proportionally lower quality of service to IPv4 without disrupting user experience.

NOTICE AND DISCLAIMER

EE Limited

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Aug 2014 10:33:43 +1000

In message <[email-masked]
O.UK>, "Heatley, Nick" writes:
> Id like v6ops to consider at least two items:
> 
> 1.       (Carrier Grade) NAT64 vs NAT44  a deathmatch.

	Most of the problem with NAT64 vs NAT44 is getting CPE
	devices upgraded.  464xlate worked for cellular networks
	because the devices were replaced to support 4G services
	and those new devices support 464xlate.  Additionally cell
	phones are fragile devices that get stolen, lost, dropped,
	stepped on, driven over, and is some market need to be
	replaced to change carrier ... so there is a high turnover.

	For wired connections there is no incentive for the customer
	to replace the CPE device so NAT44 is a required part of
	the solution space just to share the limited IPv4 address
	space between the IPv4 only customers.  Cable and DSL modems
	work for 10+ years.  Home routers work for similar lengths
	of time.  You can still buy IPv4 only routers and they are
	cheaper than anything with IPv6 in it.  If you are on a
	limited budget a IPv4 only router with 802.11g "will do".

	Add to that ISP's not offering / promoting IPv6 there is
	no incentive for the customer to buy the IPv6 capable device
	over the IPv4 only one.  The choice of device is made on
	other factors.  If ISPs offered to do 2G of IPv6 data for
	the price of 1G of IPv4 data one might actually get customers
	to buy IPv6 capable routers.  A 12 month rebate for installing
	a IPv6 capable CPE device could offset the costs of installing
	more CGNAT boxes.  IPv6 capable 802.11n routers can be got
	for AUD80 today.  Even on a AUD$20 plan the rebates would
	cover the costs if the usual +50% taffic shift to IPv6
	occurs.

	Mark

---

From: George Michaelson <[email-masked]>
Date: Wed, 20 Aug 2014 10:38:04 +1000

Tax incentives for early depreciation and write off. For Australia and NZ,
where a lot of the deployment is self-bought this isn't going to work as
well as for other economies, but at world scale, this will enable ISPs who
own the CPE to do a deployment with some financial efficiency.

Regulators always have two tools: the carrot and the stick. We see a lot of
noise about the stick on these lists, we never see quite enough mention of
the carrot side of the equation.

-G

On Wed, Aug 20, 2014 at 10:33 AM, Mark Andrews <[email-masked]> wrote:

>
> In message
> <[email-masked]

---

From: "Heatley, Nick" <[email-masked]>
Date: Thu, 21 Aug 2014 08:48:34 +0000

Hi Mark,
If you are saying even new customers / truck rolls, end up with a legacy CPE, then I see the predicament.
But you are basically saying NAT44 is inevitable when all you have is support for IPv4. I don't intend to detract from NAT44 in that context.

The context of my rant was the across the broad family of "dual stack type technologies" in conjunction with NAT.
Some appear to move us further forward than others, what is holding us back?
BR,
Nick

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Andrews
Sent: 20 August 2014 01:34
To: IPv6 Ops WG
Subject: Re: [v6ops] Operational Consensus on deployment

	Mark

EE Limited

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Mon, 25 Aug 2014 13:57:29 +0000

HI,
Ipv6 traffic for OPL Ipv6 mobile subscribers returns to its "normal" values.
Native Ipv6=60%,NAT64=40%*

*- mainly national content, If polish national top 10 Alexa content becomes Ipv6 then 90% traffic will be Ipv6...
So if you now IPv6 readiness for your national top Alexa sites you can estimate how much NAT64 you can expect.

Regards,
TK

From: Kossut Tomasz - Hurt
Sent: Friday, August 08, 2014 4:19 PM
To: 'Eric Vyncke (evyncke)'; Lorenzo Colitti
Cc: IPv6 Ops WG
Subject: RE: [v6ops] Operational Consensus on deployment

Hi,

Regards,
Tomasz

Lorenzo

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 25 Aug 2014 14:01:40 +0000

Thanks for the update… and indeed, in non-English native countries (like mine), local content is important… but very difficult to get moving to IPv6 (I mean the business/political reason to move, not the technical move itself with the help of CDN)

-éric

From: Kossut Tomasz - Hurt <[email-masked]<mailto:[email-masked]>>
Date: lundi 25 août 2014 15:57
To: Eric Vyncke <[email-masked]<mailto:[email-masked]>>, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>, Czerwonka Michał 1 - Hurt <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] Operational Consensus on deployment

HI,
Ipv6 traffic for OPL Ipv6 mobile subscribers returns to its “normal” values.
Native Ipv6=60%,NAT64=40%*

*- mainly national content, If polish national top 10 Alexa content becomes Ipv6 then 90% traffic will be Ipv6…
So if you now IPv6 readiness for your national top Alexa sites you can estimate how much NAT64 you can expect.

Regards,
TK

Hi,
Internet traffic for OPL ipv6 -464xlat users (3G/4G)
Traffic till mid-July:
Ipv6 -60% (78% to Google)
Nat64 -40%
Traffic from mid-July up to now:
Ipv6 – 40%* (50% to Google)
Nat64- 60%

Regards,
Tomasz

Lorenzo

---

From: Owen DeLong <[email-masked]>
Date: Tue, 26 Aug 2014 17:07:53 -0700

The incentive for customers to upgrade will start to happen when ISPs start sending out notices to the following effect:

————————

Due to the aging nature of the IPv4 protocol and the increased costs of continuing to support customers on this protocol,
we will have to start adding an IPv4 surcharge to your bill if you wish to continue IPv4 service.

We recognize that today, many customers will consider IPv4 still an essential service. Unfortunately, several content providers,
such as Amazon, Twitter, Bing, Wordpress, etc. still haven’t joined the modern internet by upgrading to IPv6.

However, we do not feel that it is fair to penalize customers who no longer need IPv4 by asking them to share the costs of
continuing to support this aging protocol, so, for those customers that do, we will begin adding $5/month to your bill effective
<date>

————————

(Or something like it)

I believe this will happen sooner than many people think.

Owen

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 27 Aug 2014 16:19:12 +0000

> I believe this will happen sooner than many people think.

Speaking for myself, I would agree. Note that in this email I am wearing neither a corporate nor an IETF hat (always at least theoretically true on IETF lists, but I want to emphasize it). I am a random fly on the wall.

That said, there are a couple of steps companies need to take before they do this. If consumers don’t have a way to avoid the $5 charge, it’s simply a price increase, and will be reported and commented on as such.

Part of this is content, and therefore enterprise. I would expect that ISPs will find themselves needing to apply price differential based on IPv4-only vs dual stack access to their enterprise customers’ public sites. In essence, consumer-accessible sites need to be IPv6-capable for https/http2 and SMTP, and possibly a few other protocols. Proof of connectivity is probably that an IPv6-only endpoint can access the name of the company using the included protocols, and not just on the day the contract is signed but periodically through its lifetime. The means to achieve that could be as simple as signing up with a CDN or cloud provider, but I would expect the ISP to want it to use either dual stack connectivity on the access link to the enterprise, or CDN/cloud that is embedded with the ISP. It has to solve a problem for the ISP.

Both that and residential broadband will need an IPv6-capable upstream. Speaking for myself, AFAIK my residential provider doesn’t offer IPv6 to me. Last time I asked them, they quoted me $1000/month. I have IPv6 service via VPN to my employer. We have a few companies that are starting down that road. We need more.

And as the biggest single issue in residential IPv6 deployment is the CPE router, I suspect the ISP will need to facilitate some program in which a known-working IPv6 CPE gets into the home. That could be a managed service, a coupon at a department store, or whatever. But you will have a real headache if you tell people that they will be charged more if they don’t have IPv6 capabilities, they agree to let you put an IPv6 address on their modem, but then their CPE doesn’t actually use it. Explaining to them “but I don’t see IPv6 packets coming out of your house” will be a real sink. The ISP will need to make it Really Easy for them to have IPv6 packets coming out of their house without them having to grok the implications.

---

From: James Woodyatt <[email-masked]>
Date: Wed, 27 Aug 2014 09:29:32 -0700

I think about this a little differently.

I contend the incentive for customers to upgrade will happen when "have you
tried disabling IPv4?" and "do you have IPv6?" are the responses you start
seeing in troubleshooting forums in response to questions in the category
"Why is $APPLICATION not working / too slow / so unstable?"

On Tue, Aug 26, 2014 at 5:07 PM, Owen DeLong <[email-masked]> wrote:

> The incentive for customers to upgrade will start to happen when ISPs
> start sending out notices to the following effect:
>
> ————————
>
> Due to the aging nature of the IPv4 protocol and the increased costs of
> continuing to support customers on this protocol,
> We recognize that today, many customers will consider IPv4 still an
> essential service. Unfortunately, several content providers,
> However, we do not feel that it is fair to penalize customers who no
> longer need IPv4 by asking them to share the costs of
> continuing to support this aging protocol, so, for those customers that
> do, we will begin adding $5/month to your bill effective
> <date>
>
> ————————
>
> (Or something like it)
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 27 Aug 2014 16:54:36 +0000

On Aug 27, 2014, at 9:29 AM, James Woodyatt <[email-masked]> wrote:

> I contend the incentive for customers to upgrade will happen when "have you tried disabling IPv4?" and "do you have IPv6?" are the responses you start seeing in troubleshooting forums in response to questions in the category "Why is $APPLICATION not working / too slow / so unstable?"

True enough, but they’ll need the access problem solved first. It must be feasible to turn off IPv4.

---

From: James Woodyatt <[email-masked]>
Date: Wed, 27 Aug 2014 11:12:41 -0700

No, actually— it never needs to be feasible to turn off IPv4.  Ordinary
people, the users of Internet applications, don't really see any need to
augment IPv4 with IPv6.  And they never will until the utility of the IPv4
Internet begins to degrade noticeably in comparison to the IPv6 Internet.

If people are never exposed to the idea that "using $APPLICATION is full of
lose because IPv4, use IPv6 instead," then people will never have any
incentive to stop using IPv4 and start using IPv6.  So long as IPv4
continues to be 1) an essential service and 2) functionally equivalent to
IPv6 at the level of application visibility, there is no actual need to
solve the IPv6 access problem, because application users don't actually
need it.

If operators want ordinary people to migrate from IPv4 to IPv6, they might
try offering IPv6-only service at discount prices— which would position
IPv6 as the protocol for second-class citizens who can't pay premium prices
for the first-class Internet that rich celebrities enjoy between bites of
caviar.  Or they can offer dual-stack service and provision their networks
so that CGN44 boxes are the peak-load IPv4 bottlenecks, which would
position IPv4 as the protocol for second-class citizens who can't afford to
upgrade to the latest gear.  Which of those strategies do we think provides
more incentive to upgrade to IPv6?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Aug 2014 12:00:19 +1000

In message <[email-masked]>
> Internet begins to degrade noticeably in comparison to the IPv6 Internet.

CGN significantly degrades IPv4 for some as you no longer have working
port forwarding, a semi static public IPv4 address, and access to
protocols other that TCP, UDP and ICMP.

PCP still needs the CPE to be upgraded which hopefully will include IPv6
support.

> If people are never exposed to the idea that "using $APPLICATION is full
> of lose because IPv4, use IPv6 instead," then people will never have any
> position IPv4 as the protocol for second-class citizens who can't afford
> to> upgrade to the latest gear.  Which of those strategies do we think
> provides more incentive to upgrade to IPv6?

* Just fail 10% of connection attempts through the CGN44.
* Only allow X table entries per customer, where X decreases every month.

I think the first thing they want is to get IPv6 capable CPE devices
installed and IPv6 enabled on them.  When +50% of traffic will
switch to IPv6 immediately you get significant saving through not
having to provision the CGN44 to support all the sessions that are
going over IPv6.  Less IPv4 address are needed.  Less boxes are
needed.  With CGN44 its simultaneous sessions per IPv4 address which
is a limiting factor.

You get a bigger pool of IPv4 which can be handed out to those
customers (domestic and commercial) that really still need a public
IPv4 address possibly for a addition cost.

Mark