Subject: Re: [Softwires] [dhcwg] We can change the world in a 1000 ways (IPv4 over IPv6)

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: Simon Perreault <[email-masked]>
Date: Tue, 12 Nov 2013 10:06:30 -0500

Le 2013-11-12 06:33, Ole Troan a écrit :
> 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)
>

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: Ted Lemon <[email-masked]>
Date: Tue, 12 Nov 2013 16:22:20 +0000

On Nov 12, 2013, at 11:06 AM, Michael Richardson <[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,
> ask them which one they would *NEVER* consider.  That might reduce the
> field by half...

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: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Nov 2013 08:38:41 +1300

On 13/11/2013 07:12, Michael Richardson wrote:
...
> 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.

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: Randy Bush <[email-masked]>
Date: Wed, 13 Nov 2013 05:02:11 +0900

> 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...

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

On Nov 12, 2013, at 1:12 PM, 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.

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: Ole Troan <[email-masked]>
Date: Wed, 13 Nov 2013 16:49:26 +0100

>> ...
>> 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.

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

On 11/12/13, 8:06 AM, Michael Richardson wrote:
> 
> Ole Troan <[email-masked]> wrote:
> this comic part is pretty important context, but many might not have gotten it.
> 
> 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.

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.

> 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.
>

---

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. :)