Re: [v6ops] Operational Consensus on deployment

[Lee Howard <[e-mail]>]

On 8/5/14 3:06 PM, "Philip Homburg" <[e-mail]> wrote:

>In your letter dated Tue, 5 Aug 2014 21:54:02 +0200 you wrote:
>>On Tue, Aug 05, 2014 at 09:22:10PM +0200, Philip Homburg wrote:
>>> The question is then, why not simply run on RFC-1918 addresses
>>>internally?
>>
>>Why have dual everything inside, when single IPv6 is sufficient to
>>achieve service delivery?  Dual everything is *dual* *work*, translating
>>to real money out in the real world.
>
>I think it is safe to say that providing good IPv4 service is the most
>important requirement. In many cases, it is perfectly fine to not provide
>any IPv6 if it cannot be provided at reasonable cost / performance.

Is that safe to say?
Based on the current discussion, I can't tell if that's the consensus.
For instance, is it fine not to provide any IPv4 if it cannot be provided
at reasonable cost/performance?

I generally say, "IPv6 is not the goal--connectivity is the goal. IPv6 is
the solution."  The implication is that IPv6 is the solution when IPv4
does not acceptable connectivity (good/fast/cheap enough).

>
>So what recent proposals are doing to make providing IPv4 more complex
>under
>the assumption that it is actually important to provide IPv6.
>
>(note, looking at this from business point of view. Not as somebody who
>care about the future of the internet).

Layer 8 considerations aren't always appropriate for IETF documents, but
it is generally useful to bear them in mind when writing them. So, is
there a way to phrase this appropriately?

For instance, if growth (for example) is forcing IPv4 to become more
complex (or expensive, or to perform poorly), then a proposal that makes
IPv4 more complex than it currently is  might actually reduce complexity
in the future.  That could be included as a consideration, use case, or
recommendation, if there's consensus for it.


>
>So instead of doing a relatively straightforward NAT44 or NAT444 and then
>let IPv6 pay for itself, you now make the cost of providing IPv6 part of
>the
>cost of providing IPv4.
>
>In essence, your IPv4 network now got more expensive.
>
>In some cases, mobile operators, very big cable ISPs that run out of
>RFC-1918,
>it makes sense to translate or tunnel IPv4.
>
>In other cases, this kind of complexity is likely to backfire some time in
>future.

If, indeed, we're talking specifically about Tore's SIIT document, it
would be more useful if we could describe the cases where it does and does
not make sense. Would you find it to be useful, then?

Lee