Subject: We can change the world in a 1000 ways (IPv4 over IPv6)

From: Ole Troan <[email-masked]>
Date: Tue, 12 Nov 2013 12:33:20 +0100

In the context of http://xkcd.com/927/

See attached drawing for the current state of IPv4 over IPv6 standardisation.

Count of IPv4 over IPv6 mechanisms (conservative): 9
Number of ways to provision IPv4 addresses and other configuration information: ~6
(Number of ways to carry DHCPv4 packets over softwires: 3)

This is a call for action to get to 14!
Reaching that the IESG has promised (yeah, right) to charter a new working group
to develop the one true universal standard.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 12 Nov 2013 10:06:30 -0500

> This is a call for action to get to 14!

I'm doing my part as we speak. I'm writing a new version of LW4o6 that 
uses translation instead of encapsulation. I'll call it LW4o6-T.

(Am I joking? That is the question.)

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2013 11:06:40 -0500

> In the context of http://xkcd.com/927/

this comic part is pretty important context, but many might not have gotten it.

    > This is a call for action to get to 14!

So Ole is saying that we need a 14th specification/standard in order to
bind the existing 13 (although I'm not sure how he got 13)

I'm also dismayed at the number of efforts.
It would be nice to convene a summit of operators (at RIPE or NANOG) and 
describe the various mechanisms and rather than ask them which one they like,
ask them which one they would *NEVER* consider.  That might reduce the
field by half...

My gut is that until we have a unified story and some fielded product on
deploying v4 over v6, that for a number of ISPs, adding v6 is just added cost
with no savings.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Nov 2013 16:22:20 +0000

> ask them which one they would *NEVER* consider.  That might reduce the

I don't think that's practical—they might all vote for a protocol that they wind up not wanting to deploy.   The models that are under consideration actually have running code and some operational experience behind them.   So asking operators to decide based on a feature list or something of that sort is not a good idea.   What we really want is for operators who have realistic intentions of deploying this stuff to weigh in.   And they are doing so, in the working group, so we don't really need to go to RIPE or NANOG to get this feedback.

---

From: Cong Liu <[email-masked]>
Date: Tue, 12 Nov 2013 20:26:44 +0800

Hi Ole,

2013/11/12 Ole Troan <[email-masked]>

> This is a call for action to get to 14!

What's "14!" ? Do you want to make priorities for all existing IPv4 over
IPv6 / provisioning mechanisms?

Thanks!
Cong

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2013 13:12:59 -0500

Ted Lemon <[email-masked]> wrote:
    >> It would be nice to convene a summit of operators (at RIPE or NANOG)
    >>and describe the various mechanisms and rather than ask them which one
    >>they like, 

    > I don't think that's practical—they might all vote for a protocol that
    > they wind up not wanting to deploy.   The models that are under

That's why I wouldn't ask them to pick a winner, but rather to pick the loser.

    > consideration actually have running code and some operational
    > experience behind them.   So asking operators to decide based on a
    > feature list or something of that sort is not a good idea.   What we
    > really want is for operators who have realistic intentions of deploying
    > this stuff to weigh in.   And they are doing so, in the working group,
    > so we don't really need to go to RIPE or NANOG to get this feedback. 

a) I'm not convinced the operators we have are very representative of the
   whole.  (But those that show up at a NOG might not be either. sadly)

b) I'm more interested in reasons operators who are not deploying anything,
   have for not wanting to.

I'll bet if we had a single IPv4 over IPv6 solution which had a clear
operating cost savings over Dual-Stack, and also over IPv4-only+CGN, that
we'd be at universal deployment of IPv6 already.

I don't really understand why we have so many mechanisms... Perhaps we could
have an IAB plenary presentation on it... or maybe someone could do an ISOC
video like Kathleen did for MILE.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Nov 2013 08:38:41 +1300

On 13/11/2013 07:12, Michael Richardson wrote:
...
> video like Kathleen did for MILE.

Because we've been playing a game of "my solution is better than your
solution" in softwire for several years. We should stop. Now.

   Brian

---

From: Chris Grundemann <[email-masked]>
Date: Tue, 12 Nov 2013 12:48:33 -0700

> deploying v4 over v6, that for a number of ISPs, adding v6 is just added

Agreed. And (perhaps to Brian's point just now), it may not matter all that
much which one "wins." At some point having a solution is more important
than having the best solution (especially since best is usually quite
subjective). What we need is one good-enough solution for IPv4 over IPv6
communication to be anointed THE suggested IPv4 over IPv6 mechanism so that
operators have something to deploy. Today they have a research project to
even discover what the options are - and this is not how technology gets
widely adopted in my limited experience.

$0.02
~Chris

-- 
@ChrisGrundemann
http://chrisgrundemann.com

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 Nov 2013 14:53:14 -0500

On Nov 12, 2013, at 1:12 PM, Michael Richardson <[email-masked]> wrote:

>   whole.

It is not, but a number of the operators who do participate *try* and represent the industry, and not just their employer.

A well known issue is the lack of operator involvement in the IETF. 
In general operators are focused on solving issues *today* - much of the work in the IETF is viewed as much further out  and / or detached from the operational real world.
A number of things have reinforced this view, especially some of the v6 zealotry and unwillingness to listen to what the operators actually want (see the DHCP discussions and extension / fragment discussions). Just because it works fine in IPv4 is *not* actually a good reason to change it in IPv6...

Very rough stats:
NANOG has ~690 attendees (Phoenix), RIPE has ~570 (Dublin), APRICOT ~725 (Singapore), lacnic20 and ~291 and MENOG ~95. I was not easily able to find the attendee list for other NOGS (like PacNOG, Afrinic, etc.)

There are around 1100 organizations represented (the list formats were not identical, some folk spell their organization names differently, do you count Globenet and Globenet/Brasil as one organization or two?)

>  (But those that show up at a NOG might not be either. sadly)

Yup. But it *is* much more representative...

-- 
Eagles soar but a weasel will never get sucked into a jet engine

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Nov 2013 05:02:11 +0900

> they like, ask them which one they would *NEVER* consider.  That might
> reduce the field by half...

please please keep ds-lite.  you get to fork-lift the cpe and it has nat
in the core.  what more could i wish on my competitors?

randy

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Nov 2013 21:49:53 +0000

> we'd be at universal deployment of IPv6 already.

And if we all had ponies, we could go for a ride together!   Seriously, the various solutions that have been proposed are all reasonable technical solutions.   There's no strong technical reason to prefer one over another.   And the proponents of the solutions will not come to consensus on a single solution.   So your choices, really, are many solutions, or none, or let the IESG pick a winner, which I don't think would be a popular move.

We could just stand pat with DS-Lite and Public 4over6, but there's demand for port-sharing in locales with fewer IPv4 addresses to burn, and putting all the NAT state in boxes in the data center is expensive.

Also, "we'd be at universal deployment of IPv6 now?"   Seriously?

> video like Kathleen did for MILE.

This would just be more layer 9.   I'd rather we published some specs and got on with our lives.   The IESG does not have limitless time to burn on trivia, and I don't think the IAB does either.   It's just not that interesting to argue about it.   These are transition technologies—they'll be obsolete in ten years.

---

From: John C Klensin <[email-masked]>
Date: Wed, 13 Nov 2013 09:21:40 -0500

--On Tuesday, November 12, 2013 13:12 -0500 Michael Richardson
<[email-masked]> wrote:

>...
> I'll bet if we had a single IPv4 over IPv6 solution which had
> a clear operating cost savings over Dual-Stack, and also over
> IPv4-only+CGN, that we'd be at universal deployment of IPv6
> already.

Since we are engaged in a counterfactual guessing / betting
game, I'd bet that would be true had we defined such a solution
a decade ago, that it were realistic, and that we had stuck to
it.  At this stage, the cartoon is relevant -- not only would we
be likely to add another method to the list when existing ones
already have their advocates, but dropping two or three would
not be enough to make a significant difference.

   john

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Nov 2013 16:49:26 +0100

> not be enough to make a significant difference.

ngtrans et al, standardised somewhere in the area of 14 transition mechanisms
for IPv6 transition. the experience from that, was that it was really hard to know
a priori which mechanism would succeed (e.g. 6rd) and which would hinder
IPv6 deployment (6to4, Teredo).

we're in the same situation with the mechanisms for the IPv4 endgame,
and all we can do is throw spaghetti on the wall.
while standardising every possible solution, isn't quite standardising at all in my book,
I don't have any good proposals for what we can do better.

is there a problem here, or should we just accept that sometimes the IETF
will generate ten sets of publications solving more or less the same problem?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Nov 2013 16:05:44 +0000

> will generate ten sets of publications solving more or less the same problem?

If I'd been area director earlier in the process I might have just shut the working group when it became clear that the principals couldn't agree on a proposal, and required that they come to agreement before a BoF would be approved.   But it's much too late in the process to do that now.   And I don't even know if that would have produced a better outcome.

I don't think we should accept that this has to happen every time, and I think we should try to prevent it happening in the future.   But there is no sense crying over spilt milk.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 14 Nov 2013 12:27:32 -0800

> ask them which one they would *NEVER* consider.  That might reduce the

I'm pretty sure the "if we just get the right people in the room then
we'll get the right one's" model isn't going to work... There's a
market-place out there, that can pick one if it turns out to be
necessary. The fact that to a large degree it hasn't, might mean, it's
too early, none of extant ones are the right one, there isn't a market
need for it, or something else.

As an operator, albeit not of retail ISP networks, the fact of the
matter is I don't need transition technologies of the encapsulation or
translation variety to serve either my ipv4 or IPv6 customers, so asking
me which I find more compelling is missing the point.

---

From: [email-masked]
Date: Thu, 14 Nov 2013 20:42:19 +0000 (UTC)

>> deploying v4 over v6, that for a number of ISPs, adding v6 is just added cost

Its worse than that.  Given that v4 has been monetized by big ISPs, it is 
actaully a revenue loss for them to transition to v6 on a large scale.

---

From: Lee Howard <[email-masked]>
Date: Thu, 14 Nov 2013 17:36:14 -0800

>actaully a revenue loss for them to transition to v6 on a large scale.

Do you mean IPv6-only is a revenue loss, or dual-stack or some kind of
transition mechanism?
I'm pretty sure I don't understand your point.

Lee

---

From: Lee Howard <[email-masked]>
Date: Thu, 14 Nov 2013 17:44:20 -0800

>    >> ask them which one they would *NEVER* consider.  That might reduce

I understand ETSI has developed a document that chose 17 of the top 27
transition mechanisms to describe. I doubt the audience would sit still
for the 8 hours of description, and retain enough information to make
informed decisions.

>b) I'm more interested in reasons operators who are not deploying

Not deploying IPv6, or not deploying transition technologies?
Operators who are not deploying either are not convinced that there's an
urgent enough problem for them.  I think they're wrong, since I think it
will take them two years to deploy, and they have less than two years
before they'll regret not having IPv6.

>we'd be at universal deployment of IPv6 already.

I doubt it.  Operators don't save money until they can return to single
stack.  Without content on IPv6, running IPv4 over IPv6 just adds
complexity, adds gear in the core, and makes your traditional service
dependent on the new protocol.  With content on IPv6, you don't need the
transition mechanism.
Of course, content doesn't want to do IPv6 until the ISPs provide
eyeballs.  I think I've had this conversation before.

>video like Kathleen did for MILE.

Because getting your name on an RFC is a career-enhancing move.

Lee

---

From: Mark Townsley <[email-masked]>
Date: Fri, 15 Nov 2013 00:35:19 +0100

On Nov 13, 2013, at 5:05 PM, Ted Lemon wrote:

> If I'd been area director earlier in the process

You rang?

> I might have just shut the working group when it became clear that the principals couldn't agree on a proposal, and required that they come to agreement before a BoF would be approved.

Not chartering work doesn't always help as it can scatter people to the winds to create their own parallel efforts. The 13+ IPv4 over IPv6 solutions you see were born from the rubble of trying to keep DS-Lite as the only chartered work softwires would look at for IPv4 over IPv6 with some kind of built-in IPv4 address sharing.

Ted, when we started softwires, I noted very clearly that I would reject every transition protocol to come my way until the WG agreed on a finite set of problem-spaces and associated solutions. Note I didn't say reject _chartering_ the work or having a BoF, I said reject the proposals that did not come via the WG (e.g., as an end-run to the chartered effort). This gave people a common place to work, and at the start that's exactly what it did. We held 3 interim meetings, and killed many more proposals than we advanced. By the time my AD tenure was up, we had identified L2TP for point-to-point stateful tunnels from hosts and such (largely because it was already in so many places already). We had a second solution for larger core networks (essentially a generalization of MPLS' 6PE). The third was 6rd, building on 6to4 in a manner that was far more palatable to an operator to deploy and had the obvious scaling properties over L2TP.  So, the happy medium for what were deployed as largely IPv6 over IPv4 solutions ended up somewhere between "one-size-fits-all" and "everything-goes". 

To my memory the 4/6 mess kicked a bit later. The mess started not because the WG allowed too much in its charter, but because it was rejecting so much work outright that it didn't give people a trusted place to come together and work towards a compromise sooner rather than later. 

My point is that sometimes we fail when we don't give people the right environment to work together and make compromises early on in the hopes of rising the tide for everyone. If groups remain in their respective corners working on their own for too long, they are bound to create their own parallel paths. The longer that is allowed to happen, the more entrenched the solutions become, until the IETF has lost its ability to do anything constructive beyond publishing everything.

- Mark

>   But it's much too late in the process to do that now.   And I don't even know if that would have produced a better outcome.
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Nov 2013 04:14:31 +0000

> You rang?

Yeah.   I meant to reply just to Ole, but basically I was saying the same thing you were, just from a less informed perspective.   I might have done things differently, but I don't know if it could have produced a better outcome.   Your analysis matches the actual results pretty well, so if Ole is trying to pick between them, I recommend he pick yours. :)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 09:23:47 -0500

On Wed, Nov 13, 2013 at 11:05 AM, Ted Lemon <[email-masked]> wrote:

> If I'd been area director earlier in the process I might have just shut
> the working group when it became clear that the principals couldn't agree
> on a proposal, and required that they come to agreement before a BoF would
> be approved.   But it's much too late in the process to do that now.   And
> I don't even know if that would have produced a better outcome.
>

I am not sure that would have worked. As with the S/MIME vs PGP standards
war there were ideological factions. Putting those two factions in a room
and requiring them to emerge with one standard would not have worked unless
there was a very skilled technical arbiter who could work with the two
sides and get them to identify the aspects that they considered essential
requirements. Phil Zimmerman has already walked out on the PEM fiasco he
had a user base and was not at all convinced that the S/MIME faction had
any technical contributions they could make.

Until relatively recently the majority of posters here would assert that I
was completely wrong about the need to embrace NAT boxes as part of the
solution rather than consider them to be a dangerous nuisance to be
eliminated at all costs. Part of the reason behind the profusion of
proposals is that many of the principals had rejected the only viable
architecture.

Forcing them to agree before having a BOF would not have worked because the
approaches were not compatible. The NOMCON scheme makes the system
dramatically worse as it makes achieving groupthink on the IAB and IESG a
goal. The people who were wrong about using NAT to transition to IPv6 the
longest were the people at the top of the IETF oligarchy. What would have
happened in that situation would be that the 'lets kill the NAT boxes'
faction would have won and either the IPv6 transition scheme would be
coming out of ETSI or W3C or not at all.

People can say what they like about the NSA, at least they listen to their
critics.

Getting back to PGP vs S/MIME, I think we have a once in a decade
opportunity to move past that deadlock due to the Snowden files. There is
also at least one documentary and a movie in the works so we have maybe 18
months to develop a scheme that combines both approaches.

The core of PGP is the peer trust model which is also its main limitation.
If I already know the recipient then PGP is the strongest way to get a
message to them because I do not need a trusted third party as an
introducer. The problem with PGP is that it really does not scale or
achieve 'viral' growth. Twenty years later the user groups are islands of a
few hundred or in rare cases a few thousand.

The S/MIME message formats don't offer any real technical advantages over
the PGP formats except that they are supported by the legacy infrastructure
to a far greater extent. Passing S/MIME unmolested is a requirement almost
every mail server has supported for a decade.

-- 
Website: http://hallambaker.com/