Re: [v6ops] Operational Consensus on deployment

["Fred Baker (fred)" <[e-mail]>]

On Aug 4, 2014, at 11:51 AM, Tore Anderson <[e-mail]> wrote:

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

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.