Re: [v6ops] discussion of transition technologies

[Toerless Eckert <[e-mail]>]

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

On Mon, Jan 22, 2018 at 10:25:02PM +0100, Ole Troan wrote:
> > 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.
> 
> 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
> 
> 
> 
> > 
> >   Brian
> > On 23/01/2018 09:23, Fred Baker wrote:
> >> 
> >> 
> >> On Jan 22, 2018, at 11:17 AM, Ole Troan <[e-mail]> wrote:
> >>> 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.
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >> 
> 



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