Re: [v6ops] Operational Consensus on deployment

[Owen DeLong <[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.

I would argue it doesn’t really fit either group, but there’s no place better
to put it.

Really, it’s about v4-life-support, but there’s on IPv4-Life-Support working
group. (perhaps there should be).

To my thinking, sunset4 is really about what we need to do to get ready to
turn off IPv4. A technology for continuing IPv4 in a v6-dominant world really
doesn’t fit that mission.

OTOH, this really is about continuing IPv4 operations, not v6ops, so it doesn’t
fit that charter well, either.

Of the two, I think it belongs more in v6ops than sunset4, simply because it
really has little (nothing) to do with getting rid of IPv4 and is the opposite, if
anything.

Owen