Subject: [v6ops] discussion of transition technologies

From: Lee Howard <[email-masked]>
Date: Fri, 19 Jan 2018 15:15:48 -0500

The WG Chairs were discussing the various transition technologies at some
length today.
I mentioned a previous conversation in another forum that led to this list
of networks and their mechanisms:
https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK
9vcVApc/edit#gid=0
(Corrections and additions encouraged, especially with links)

Our impression was that of the 26+ transition mechanisms defined, only a few
have any modern relevance (editorial comments are mine, not consensus
positions):
6rd.   It may be that its light is waning, with early deployments moving to
native IPv6, and no new deployments.
DS-Lite.   Widely deployed, existing support among home gateway
manufacturers.
NAT64/464xlat.   Implies NAT64, SIIT, which may be used elsewhere. Handset
CLATs. No home gateway CLAT yet.
MAP-T.   Announced trials and lots of buzz, but no large-scale deployments,
no home gateway support yet.
MAP-E.   Some buzz, no announced trials or deployments, no home gateway
support yet.
Native dual-stack.   Still the gold standard, but doesn’t solve IPv4 address
shortage.

(Note that “yet” may change at any time).
As a matter of discussion, do you agree?
To guide our work, is there work we should do to document or deprecate any
of these?

Thanks,

Lee

---

From: Fred Baker <[email-masked]>
Date: Fri, 19 Jan 2018 16:22:12 -0800

At least part of this commentary wound up in https://tools.ietf.org/html/rfc6180
     Guidelines for Using IPv6 Transition Mechanisms during IPv6
     Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=49679 bytes)
     (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180)

I think Jari's view in that was that we needed to rein in the plethora of transition technologies, and "if one has to translate, can we please do so above the IP layer?" I added SIIT/NAT64, because I think there is market relevance including several deployments of various kinds; any mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic recommendation of RFC 6180 was:
  - first choice, deploy native IPv6
  - for scenarios in which IPv6 islands are connected across IPv4 space, use dslite (a tunneling design).
  - for scenarios in which IPv6 systems have to talk with IPv4 systems, translate. Please consider doing so above the IP layer.

I would argue that 464XLAT, MAP-E, and MAP-T are "ways that an ISP might use SIIT/NAT64 in its network", and are therefore not fundamental transition technologies as much as ISP services built using them.

I think I might also argue that the market has more or less followed that advice. Your spreadsheet seems to suggest that.

> On Jan 19, 2018, at 12:15 PM, Lee Howard <[email-masked]> wrote:
> 
> 
> The WG Chairs were discussing the various transition technologies at some length today.
> I mentioned a previous conversation in another forum that led to this list of networks and their mechanisms:
> https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0
> Our impression was that of the 26+ transition mechanisms defined, only a few have any modern relevance (editorial comments are mine, not consensus positions):
> 6rd.   It may be that its light is waning, with early deployments moving to native IPv6, and no new deployments.
> DS-Lite.   Widely deployed, existing support among home gateway manufacturers.
> NAT64/464xlat.   Implies NAT64, SIIT, which may be used elsewhere. Handset CLATs. No home gateway CLAT yet.
> MAP-T.   Announced trials and lots of buzz, but no large-scale deployments, no home gateway support yet.
> MAP-E.   Some buzz, no announced trials or deployments, no home gateway support yet.
> Native dual-stack.   Still the gold standard, but doesn’t solve IPv4 address shortage.
> 
> To guide our work, is there work we should do to document or deprecate any of these?
> 
> Thanks,
> 
> Lee

---

From: Sander Steffann <[email-masked]>
Date: Sun, 21 Jan 2018 13:48:35 +0100

Hi Fred,

>  - for scenarios in which IPv6 islands are connected across IPv4 space, use dslite (a tunneling design).

DS-Lite connects IPv4 islands over IPv6 infra, and 6rd connects IPv6 islands over IPv4 infra.

Cheers!
Sander

---

From: Fred Baker <[email-masked]>
Date: Sun, 21 Jan 2018 11:19:48 -0800

> On Jan 21, 2018, at 4:48 AM, Sander Steffann <[email-masked]> wrote:
> 
> Hi Fred,
> 

Shows how much I know. So 6rd had to be mentioned as well.

---

From: Fred Baker <[email-masked]>
Date: Sun, 21 Jan 2018 11:28:09 -0800

Restated. Close?

> On Jan 19, 2018, at 4:22 PM, Fred Baker <[email-masked]> wrote:
> 
>  - first choice, deploy native IPv6 - for scenarios in which IPv6 islands are connected across IPv4 space, use dslite (a tunneling design).
>  - for scenarios in which IPv4 islands are connected across IPv6 space, use dslite (a tunneling design).
  - for scenarios in which IPv6 islands are connected across IPv4 space, use 6rd (a tunneling design).
> I would argue that 464XLAT, MAP-E, and MAP-T are "services in which an ISP might use SIIT/NAT64 in its network", and are therefore not fundamental transition technologies as much as ISP services built using them.
> 

The interesting thing is that 6rd, which is a way of appearing to have an IPv6 network without actually having one, is not what one might call "prevalent". It has in fact been used for *transition*, in places like Free - which used to connect IPv6 customers using 6rd and (I understand) has recently announced native IPv6 deployment. The places I know that have used it used it for a while and then have gone native.

Would you agree with that?

Side comment: I wrote the above and then read it back. The common meaning of the phrase "go native" is not what I meant (it's derogatory), but humorous in context. https://www.urbandictionary.com/define.php?term=go%20native

---

From: Sander Steffann <[email-masked]>
Date: Sun, 21 Jan 2018 20:44:31 +0100

Hi Fred,

> Would you agree with that?

Looks good!

Thanks,
Sander

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Jan 2018 10:46:45 +0000

> On 21 Jan 2018, at 19:44, Sander Steffann <[email-masked]> wrote:
> 
> Hi Fred,
> 

So what translation mechanisms are you recommending "above the IP layer" ?

Tim

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Jan 2018 12:05:46 +0100 (CET)

> Native dual-stack.   Still the gold standard, but doesn’t solve IPv4 address

Well, this, but with IPv4 behind CGN. I know people who do this for 
mobile.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Xing Li <[email-masked]>
Date: Mon, 22 Jan 2018 21:11:04 +0800

Lee Howard 写道:

Thanks for the summary.
> Our impression was that of the 26+ transition mechanisms defined, only 
> a few have any modern relevance (editorial comments are mine, not 
> consensus positions):
> 6rd.   It may be that its light is waning, with early deployments 
> moving to native IPv6, and no new deployments.
> MAP-T.   Announced trials and lots of buzz, but no large-scale 
> deployments, no home gateway support yet.

FYI, we deployed Stateless translators (IVI) between IPv4 and IPv6 
backbones with about 30Gbps traffic, which are used for
(1) a couple of IPv6-only servers
(2) 30+ campus networks with double translation (a variation of MAP-T)

see https://tools.ietf.org/html/draft-xli-v6ops-cernet-deployment-03 for 
more information.

Regards,

xing

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Jan 2018 09:29:46 -0800

> So what translation mechanisms are you recommending "above the IP layer" ?

The one that comes quickly to mind is a load balancer that terminates one transport connection and relays data to another. It's a transport layer gateway, and so not translation in the SIIT sense of the word. It also has interesting ramifications for ICMP and so on - they don't follow the transport connection and so are invisible to it through such a gateway. The one place that seems to be a headache is with location-based or customer-based services - load balancers will often insert an http header letting the ultimate recipient know the address of its ultimate peer in the session. That, of course, has ramifications for https etc, which might be just as happy to carry the data as some form of login cookie or REST data element.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jan 2018 07:37:58 +1300

> Well, this, but with IPv4 behind CGN. I know people who do this for 

That's certainly what we described in https://tools.ietf.org/html/rfc6264
(and it isn't restricted to mobile).

   Brian

---

From: Lee Howard <[email-masked]>
Date: Mon, 22 Jan 2018 14:00:42 -0500

On 1/21/18, 2:28 PM, "Fred Baker" <[email-masked]> wrote:

>> I think Jari's view in that was that we needed to rein in the plethora
>>of transition technologies, and "if one has to translate, can we please
>>do so above the IP layer?" I added SIIT/NAT64, because I think there is
>>market relevance including several deployments of various kinds; any
>>mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic recommendation
>>of RFC 6180 was:
>>  - first choice, deploy native IPv6 - for scenarios in which IPv6
>>islands are connected across IPv4 space, use dslite (a tunneling design).

You would argue that 464xlat, MAP-E, and MAP-T are simply implementations
of SIIT/NAT64 (which you do, below), but it seems to me that they are also
used in these scenarios. In some cases the “island” is but a single
application on a mobile phone.

For large networks, like access ISPs, mobile networks, and maybe campus
networks, the advice might be finer-grained:
- for scenarios in which IPv4 islands (e.g., households, a mobile phone,
or other stub network), consider:
 — If you need home gateway support right now, use DS-Lite
 — If you are using CGN anyway (such as mobile networks), consider
464xlat, which allows native IPv6 end to end when possible, native IPv6
end-to-translation-edge when IPv4 is needed to reach the other end, and
CLAT on the device or IPv4 edge when the local application or device
requires it.
 — If you can pressure or wait for home gateway vendors for MAP support
and would prefer stateless BRs (probably more scalable/cheaper than
stateful DS-Lite AFTR), use MAP. (One more decision branch between MAP-T
and MAP-E, but they’re pretty close).

>>  - for scenarios in which IPv6 systems have to talk with IPv4 systems,
>>translate. Please consider doing so above the IP layer.
>> 
>> I would argue that 464XLAT, MAP-E, and MAP-T are "services in which an
>>ISP might use SIIT/NAT64 in its network", and are therefore not
>>fundamental transition technologies as much as ISP services built using
>>them.
>> 
>> I think I might also argue that the market has more or less followed
>>that advice. Your spreadsheet seems to suggest that.
>
>The interesting thing is that 6rd, which is a way of appearing to have an
>IPv6 network without actually having one, is not what one might call
>"prevalent". It has in fact been used for *transition*, in places like
>Free - which used to connect IPv6 customers using 6rd and (I understand)
>has recently announced native IPv6 deployment. The places I know that
>have used it used it for a while and then have gone native.
>

I would; that is my perception. MHO is that 6rd has had its day, and while
I don’t think it needs to be deprecated, I haven’t heard any scenarios in
the past several years where it solves an actual problem.

Lee

---

From: Ole Troan <[email-masked]>
Date: Mon, 22 Jan 2018 20:17:47 +0100

> On 21 Jan 2018, at 20:28, Fred Baker <[email-masked]> wrote:
> 
> Restated. Close?
> 

No. There are active 6rd deployments with millions of users.
This email goes over 6rd.

What's the purpose of what you are trying to do?
Do you want to describe the world as you want it to be? Or as it is?
And for either case, see question 1.

Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 22 Jan 2018 20:20:07 +0100

> application on a mobile phone.

MAP-E is not an implementation of SIIT/NAT64.

> the past several years where it solves an actual problem.

Apart from giving millions of users IPv6 access?

Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Jan 2018 19:41:34 +0000

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Monday, January 22, 2018 11:18 AM
> To: Fred Baker <[email-masked]>
> Cc: [email-masked] WG <[email-masked]>
> Subject: Re: [v6ops] discussion of transition technologies
> 
> 
> 
> >> I think Jari's view in that was that we needed to rein in the plethora of transition technologies, and "if one has to translate, can we
> please do so above the IP layer?" I added SIIT/NAT64, because I think there is market relevance including several deployments of
> various kinds; any mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic recommendation of RFC 6180 was:
> >> I would argue that 464XLAT, MAP-E, and MAP-T are "services in which an ISP might use SIIT/NAT64 in its network", and are
> therefore not fundamental transition technologies as much as ISP services built using them.
> >>
> > The interesting thing is that 6rd, which is a way of appearing to have an IPv6 network without actually having one, is not what one
> might call "prevalent". It has in fact been used for *transition*, in places like Free - which used to connect IPv6 customers using 6rd
> and (I understand) has recently announced native IPv6 deployment. The places I know that have used it used it for a while and then
> have gone native.
> >

If we wanted to describe the world as it is, we would also have to use the "I*" word.

Fred

> > Side comment: I wrote the above and then read it back. The common meaning of the phrase "go native" is not what I meant (it's
> derogatory), but humorous in context. https://www.urbandictionary.com/define.php?term=go%20native
> >

---

From: Lee Howard <[email-masked]>
Date: Mon, 22 Jan 2018 14:54:03 -0500

>Apart from giving millions of users IPv6 access?

Why would anyone want to do that?

That’s a bit of a snarky question, but it’s a real one. Is there any
real-world problem for which 6rd is the best answer?
“I can’t update my network to support IPv6, but there are IPv6-only hosts
that my users need to be able to reach” is the scenario 6rd addresses. Is
that an actual case? The case “My ISP hasn’t updated to support IPv6, but
there are IPv6-only hosts I need to reach” is solved with a tunnel broker.

I don’t deny that it is deployed at scale. I’m asking whether there are
any new deployments, recent or contemplated, and what path on a decision
tree would lead one to decide “6rd.”

Lee

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Jan 2018 12:05:53 -0800

> real-world problem for which 6rd is the best answer?

I think the problem space I'm familiar with is stated in my previous note in this thread (scroll up). Imagine that you are a network operator (ISP or enterprise) and have some IPv4-dependent system (or set of systems) that you haven't replaced yet (or can't replace) that you need to jump over to create an IPv6 deployment. That might be as simple as - what I understand to have been Free's business case until recently - you have an IPv4 network and want to rapidly deploy IPv6. Or, the case I'm told another company had, that its DSL infrastructure was IPv4-only and 6rd allowed it to factor that out of the discussion until they could fix it (now, I'm told, fixed). "IPv6 islands connected by IPv4 infrastructure", which might be continents and peninsulas, who knows.

Now, to my mind and I think yours, the best answer to "I want to deploy IPv6" is "so do so". Where it becomes an issue is "but that costs money for some reason". 6rd might be a temporary measure to provide the service until the money was no longer an issue.

---

From: Sander Steffann <[email-masked]>
Date: Mon, 22 Jan 2018 21:07:35 +0100

Hi,

> real-world problem for which 6rd is the best answer?

The deployments that I worked on used 6rd because the L2 infrastructure couldn't do first-hop security for IPv6. No DHCPv6-PD snooping, no source guard etc. They refused to deploy IPv6 in a much less secure way than they deployed IPv4. And of course the switches either couldn't be software upgraded or would require newer supervisors to support the features they needed. Part of that has solved itself over the years with forklift upgrades, but not everywhere. So they couldn't do native IPv6, but still wanted to provide IPv6 service to their users: hence 6rd.

Cheers,
Sander

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Jan 2018 12:23:10 -0800

> What's the purpose of what you are trying to do?

This started out as a question among the chairs, triggered in part by an academic article that I can't share because it's not public yet. It lists 26 different transition mechanisms and tries to make recommendations, based in large part of recommendations we have made. The question started out as "can we narrow that to one such mechanism? Which ones are actually in use?" Now see the spreadsheet Lee shared, which comes from different data.

It sounds like Ole's data on 6rd needs to get reflected in Lee's spreadsheet.

After quite a bit of discussion, we think we had pretty much re-invented RFC 6180. The discussion isn't over, but I suspect we're close. So Lee asked for opinions from you guys.

And BTW, I suspect that dslite is a little long in the tooth for the same reason. The theory with both 6rd and dslite was/is that once there is a native path from here to there, even if the dslite configuration is still in the network it's unlikely to be used. That might be naive :-)

The big question among the chairs is "what is the real case for translation?" We see it in a variety of places, basically creating a way for IPv6-only devices or networks to talk with IPv4-only devices or networks, but wondering if there is a better way to proceed. My personal take is "it is what it is, no worse than IPv4/IPv4 translation" - not arguing for it, but considering it a fact of life until people become motivated to replace it with native systems and connectivity. YMMV.

---

From: Lee Howard <[email-masked]>
Date: Mon, 22 Jan 2018 15:25:07 -0500

On 1/22/18, 3:05 PM, "Fred Baker" <[email-masked]> wrote:

>>>>> The interesting thing is that 6rd, which is a way of appearing to
>>>>>have
>>>>> an
>I think the problem space I'm familiar with is stated in my previous note
>in this thread (scroll up). Imagine that you are a network operator (ISP
>or enterprise) and have some IPv4-dependent system (or set of systems)
>that you haven't replaced yet (or can't replace) that you need to jump
>over to create an IPv6 deployment. That might be as simple as - what I
>understand to have been Free's business case until recently - you have an
>IPv4 network and want to rapidly deploy IPv6. Or, the case I'm told
>another company had, that its DSL infrastructure was IPv4-only and 6rd
>allowed it to factor that out of the discussion until they could fix it
>(now, I'm told, fixed). "IPv6 islands connected by IPv4 infrastructure",
>which might be continents and peninsulas, who knows.

Yes, I’m familiar with those use cases. They had edge networks that
couldn’t do IPv6. I haven’t seen provider edge equipment shipped in the
last ten years that is IPv6-incapable. I don’t think whether they had
business reasons for wanting IPv6.

Sander’s example is similar, but was L2 switching gear that couldn’t do
security inspections at L3, and he also says, “part of that has solved
itself over the years."

>
>Now, to my mind and I think yours, the best answer to "I want to deploy
>IPv6" is "so do so". Where it becomes an issue is "but that costs money
>for some reason". 6rd might be a temporary measure to provide the service
>until the money was no longer an issue.

I’m thinking like a business person: why do you *want* to deploy IPv6?

Or as an engineer: I have twenty projects I could work on, what am I
trading off to find that 6rd is the optimal choice?

>> tree would lead one to decide “6rd.”

I’m not trying to deprecate 6rd; it is in active use, and it has been good
for the growth of the protocol, to prove that there was interest.

What I’m struggling to believe is that there is an actual case now, where
somebody was considering how to deploy IPv6, and I would advise them to
use 6rd. Has anyone here encountered that in the last couple of years? If
you had the conversation now, would you still advise 6rd?

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jan 2018 09:37:30 +1300

After watching this debate, I'm asking myself why we want to anything
other than
a) watch the market deciding for itself, and
b) formally deprecate anything we decide is broken.

   Brian

---

From: Lee Howard <[email-masked]>
Date: Mon, 22 Jan 2018 16:07:09 -0500

>a) watch the market deciding for itself, and

We are the market. :-)

As Fred describes, a lot of market participants (myself included) are
overwhelmed by the number of transition mechanisms, and I have heard from
quite a few people (myself included) that I could not possibly investigate
26 different technologies well enough to understand the trade offs between
them, and some therefore become paralyzed. RFC6180 "Guidelines for Using
IPv6 Transition Mechanisms during IPv6 Deployment” is fine as far as it
goes, but it doesn’t consider all of them, and was published before
464xlat and MAP.

I don’t know that we need to publish an update to RFC6180, but maybe we do.

For my own use, I get asked a lot what transition technology people should
use. I’d like to know that my answers are good.

Lee 

>> This started out as a question among the chairs, triggered in part by
>>an academic article that I can't share because it's not public yet. It
>>lists 26 different transition mechanisms and tries to make
>>recommendations, based in large part of recommendations we have made.
>>The question started out as "can we narrow that to one such mechanism?
>>Which ones are actually in use?" Now see the spreadsheet Lee shared,
>>which comes from different data.
>> 
>> After quite a bit of discussion, we think we had pretty much
>>re-invented RFC 6180. The discussion isn't over, but I suspect we're
>>close. So Lee asked for opinions from you guys.
>> 
>> And BTW, I suspect that dslite is a little long in the tooth for the
>>same reason. The theory with both 6rd and dslite was/is that once there
>>is a native path from here to there, even if the dslite configuration is
>>still in the network it's unlikely to be used. That might be naive :-)
>> 
>> The big question among the chairs is "what is the real case for
>>translation?" We see it in a variety of places, basically creating a way
>>for IPv6-only devices or networks to talk with IPv4-only devices or
>>networks, but wondering if there is a better way to proceed. My personal
>>take is "it is what it is, no worse than IPv4/IPv4 translation" - not
>>arguing for it, but considering it a fact of life until people become
>>motivated to replace it with native systems and connectivity. YMMV.
>> 
>> 
>>

---

From: Lee Howard <[email-masked]>
Date: Mon, 22 Jan 2018 16:17:26 -0500

On 1/22/18, 3:23 PM, "v6ops on behalf of Fred Baker"
<[email-masked] on behalf of [email-masked]> wrote:

>This started out as a question among the chairs, triggered in part by an
>academic article that I can't share because it's not public yet. It lists
>26 different transition mechanisms and tries to make recommendations,
>based in large part of recommendations we have made. The question started
>out as "can we narrow that to one such mechanism? Which ones are actually
>in use?" Now see the spreadsheet Lee shared, which comes from different
>data.
>

I think it is; it lists five ISPs using 6rd, though I’ve heard rumors two
of them have switched to native dual-stack.
To me, that is exactly consistent with both Ole’s point (millions of
people use 6rd; it’s what you do what your edge network can’t handle IPv6
but you want to provide it) and my point (not seeing new deployments, old
deployments are dwindling).

>
>After quite a bit of discussion, we think we had pretty much re-invented
>RFC 6180. The discussion isn't over, but I suspect we're close. So Lee
>asked for opinions from you guys.
>
>And BTW, I suspect that dslite is a little long in the tooth for the same
>reason. The theory with both 6rd and dslite was/is that once there is a
>native path from here to there, even if the dslite configuration is still
>in the network it's unlikely to be used. That might be naive :-)

Responding to both paragraphs:
RFC6180 recommends DS-Lite in 4.3: The recommended tool for this model is
Dual Stack Lite [DS-lite
<https://tools.ietf.org/html/rfc6180#ref-DS-lite>].
I’m not sure that would still be our recommendation, and it sounds like
you’re not, either.

It has the advantage of broad residential gateway support, and the
disadvantage of being stateful. The first advantage may decline over time,
but hasn’t yet.

>motivated to replace it with native systems and connectivity. YMMV.

Well, we kind of skipped the data center use cases, I think.
1. My data center is all IPv4, but I want IPv6-enabled hosts to reach it
(reasons of performance, logging, cost, etc.).
2. My data center is all IPv6, but I want IPv4-only hosts to reach it
(because 78% of the Internet is still IPv4-only).

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jan 2018 10:23:24 +1300

> I don’t know that we need to publish an update to RFC6180, but maybe we do.

Has RFC6180 proved useful to people? If so, update it by all means.
 
> use. I’d like to know that my answers are good.

Understood. A decision tree would be ideal. I'm just not sure that this
is the ideal place to develop it.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 22 Jan 2018 22:25:02 +0100

> b) formally deprecate anything we decide is broken.

Indeed, there was consensus in the IETF to let the market decide.
(Said differently, there was no consensus on standardising fewer mechanisms).

Why would anyone think that has changed significantly enough that it would matter?
If anyone wants to reopen these discussions, may I recommend they entertain themselves by reading through the few thousand messages over the last 20 years on mailing lists like ngtrans, softwire, v6ops...

It's not for the lack of trying, ngtrans shut down, coin-tosses, deprecation etc.

It isn't a choice among 26 of course. The market is deciding. And we are not the market.
The likelihood of us, as in the IETF, producing any better advice than we've already done is quite unlikely.

Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Jan 2018 09:16:58 +1100

On 23 Jan. 2018 7:37 am, "Brian E Carpenter" <[email-masked]>
wrote:

I think with so much choice, the market has trouble making a choice. It
becomes less risky to make no choice (meaning no IPv6 deployment at all)
compared to the risks of making the wrong choice.

https://en.m.wikipedia.org/wiki/Overchoice

Regards,
Mark.

   Brian
academic article that I can't share because it's not public yet. It lists
26 different transition mechanisms and tries to make recommendations, based
in large part of recommendations we have made. The question started out as
"can we narrow that to one such mechanism? Which ones are actually in use?"
Now see the spreadsheet Lee shared, which comes from different data.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 22 Jan 2018 23:24:20 +0100

RFC6180bis should be an ongoing effort with at most 2 yearly new-rfc drops
to track the state of affairs/recommendations.

Reading quickly through it, it for example does IMHO not well highlight
distinguishing between network management itself and network services.
As in: If you try to move towards IPv4 as a service and eliminating dual
stack, better not forget your own network management infra/apps.  Aka:
maybe start bothering about moving your network management to IPv6 first
like SPs have done it. Even if you're just an enterprise: With typical
dev cycles in enterprise anetwork management pps, there is no harm for
bitching to your vendors to support native IPv6 management. Then you will have
on average still 2 years or more time to start doing any IPv6 support in
your network (*sigh*).

More generally, maybe we should start to be more descriptive to such strategies
and more opinionated in rfc6180bis about what Lee called the "gold standard",
aka: inculding more recommendations instead of what i read today as mostly
neutral discussions of pro and cons. As in: IMHO we want to evolve
the "gold standard". And it should not be dual-stack, but single-stack IPv6.
And IPv4 as a service as long as you need that.

Wrt. not being able to create better outcomes with additional work (Ole):
Admittedly, i am not on top of all 26 transition mechanisms, but the way
the IETF works, my impression is that they are driven by only a subset of the
overall IPv6 community (mostly big ISPs and vendors representing them)
and they where more than happy to create stopgaps for current problems than
strategies for achieving a gold standard. And no blame to SPs for this. Thats
the problem of commercial activities. But that should not represent the overall
community. Not even experts in SPs that can manage to spend cycles beyond their
immediate business problems.

If i was looking at a strategy for the new gold standard, the last piece on
the exit strategy from IPv4 would be the question which solution is
best to provide IPv4 as a service WITHOUT BOTHERING THE NETWORK.

Is in the list of 26 any evolved version of SOCKS ? Because that IMHO the
type of solution i would be looking for. Aka: No reason to solve the problem
any lower than in socket (shim) layer (Unfortunately, this also takes it out of the
comfort realm of most network geeks).

Cheers
    Toerless

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 23 Jan 2018 10:13:45 +0100 (CET)

> tree would lead one to decide “6rd.”

I know people who seriously are still considering this, because they're 
using old access tech which will never gain native IPv6 capability. So 
it's "6RD" or "no IPv6 at all for the lifetime of the platform".

Like "we have this ethernet-over-DSL DSLAM from 2006 that seems to still 
work, aggregates a bunch of customers, everybody is in the same VLAN, and 
the vendor has EOLed this platform in 2012, we're seeing declining 
customer base but it's non-zero, and we need IPv6 SAVI functions to deploy 
IPv6 securely". Or "we buy bitstream access over ethernet to a bunch of 
customers, but the bitstream access provider is IPv4 only because <reasons 
I just described earlier, and add 
bitstream-provider-doesn't-see-business-need-to-deply-Ipv6>."

I have talked to multiple people who have pretty compelling business 
reasons not to touch old access platforms, so it's 6RD or nothing. At 
least I haven't been able to come up with something better.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 23 Jan 2018 10:23:12 +0100 (CET)

> business reasons for wanting IPv6.

I know edge platforms that work like this:

1. "Shared VLAN between customers, SAVI security for IPv4, drop all 
ethertypes that are not ARP or IPv4".

2. "No SAVI."

So if you chose option 1, to use this platform you have to move to a "one 
vlan per customer" type of deployment, for both IPv4 and IPv6, and use the 
upstream router to handle security. So this means changing the entire 
setup configuration, provisioning, fault finding tools etc.

Good luck finding business reasons to do that.

---

From: Lee Howard <[email-masked]>
Date: Tue, 23 Jan 2018 12:23:11 -0500

>least I haven't been able to come up with something better.

That’s a great example, thank you.

That’s also why I would describe 6rd as declining: its primary use is for
bypassing ISP edge equipment that’s 12 years old and EOL. As time passes,
the number of users behind equipment like that (where “12” continues
incrementing) will continue to decline. If my network was gradually
transitioning from old DSL or DOCSIS1.x, I might suggest enabling IPv6 on
the newer edge boxes and not bothering with the old ones. Or even doing
stateful NAT46 for the very few flows that needed to reach something on
IPv6.

But that’s just me, and I appreciate anyone who is trying to push IPv6 to
those users on older technology.

Lee

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Jan 2018 14:29:59 +0100

> those users on older technology.

A similar description you make on 6rd can be made on GTP-U protocol 
transpoprting IPv6 user data on UDP/IPv4 cellular networks.

Cellular operator does have answers about why they continue using IPv4 
to transport IPv6 (instead of using IPv6 to transport IPv6.)

For my part, I think the compute power goes so cheap that they can 
easily add layers upon layers and SDN them as they evolve their network, 
instead of designing on a clean slate.  New protocol?  Just beam up in a 
new overlaid world.

For this to change, maybe the sysadmins will complain the management is 
too complex, or some security attacks will go without possibility to 
track the cause, or maybe a completely new operator wants to deploy a 
new network with software and hardware whose price is in the range of 
small investors.

When that happes, they will be happy if an Internet Draft describing GTP 
on both IPv4 and IPv6 existed.

Alex

---

From: <[email-masked]>
Date: Wed, 24 Jan 2018 16:57:06 +0000

Hi Lee/All,
Was talking to a couple of people about the spreadsheet, and we don’t think the entry for Verizon Wireless is correct i.e. I don’t think DS-Lite is used for mobile. Is this a typo/error? Or can someone expand on this usage?
Thanks,
Nick

From: v6ops [mailto:[email-masked]] On Behalf Of Lee Howard
Sent: 19 January 2018 20:16
To: [email-masked]
Subject: [v6ops] discussion of transition technologies

Thanks,

Lee

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Jan 2018 20:54:56 +0100

Le 24/01/2018 à 14:29, Alexandre Petrescu a écrit :
[...]

> to transport IPv6 (instead of using IPv6 to transport IPv6.)

FYI, over in the 5gangip email list at IETF I am told to stop making 
such statements, and proposed counter-examples that I have no means to 
verify other than asking for packet dumps.

Until then I still believe it is worth writing an Internet Draft about 
GTP on IPv4 and on IPv6.  Such thing does not exist and I dont like that.

Alex

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Thu, 25 Jan 2018 10:12:30 +0000

>> NAT64/464xlat.   Implies NAT64, SIIT, which may be used elsewhere. Handset CLATs. No home gateway CLAT yet.
"Mobile" Home GW with CLAT exists. TCL/Alcatel/Huawei/ZTE,  implementations does not require DNS64. IPv6 CLAT software variant is upon operator request. 
Cheers,
TK

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Sunday, January 21, 2018 8:28 PM
To: Sander Steffann
Cc: [email-masked] WG; Lee Howard
Subject: Re: [v6ops] discussion of transition technologies

Restated. Close?

>> https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUT
>> NOO_7NK9vcVApc/edit#gid=0 (Corrections and additions encouraged, 
>> especially with links)
>>