Re: [v6ops] Operational Consensus on deployment

[Ca By <[e-mail]>]

On Aug 7, 2014 5:42 AM, "Lee Howard" <[e-mail]> wrote:
>
>
>
> 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?

No.

20% of my subscribers are ipv6-only and for them the majority of the
traffic is ipv6. For these subscribers, it is quantitatively most important
that ipv6 works. Qualitatively, it is most important the most impactful
services like facebook, google, and netflix work on ipv6.

I am guessing by the end of the year the 20% of subscribers number goes
closer to 50%. The 'x factor' is iPhone adopting 464xlat or not.

Apple -- please support rfc6877

Regards,

CB

PS. thanks to msft, windows phone now supports 464xlat.

https://dev.windowsphone.com/en-US/OEM/docs/Customization/Additional_Internet_APN_settings

:)

> 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
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops