Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC]

["cb.list6" <[e-mail]>]

On Thu, Aug 8, 2013 at 9:31 AM, Ray Hunter <[e-mail]> wrote:
> Erik Nygren wrote:
>> It's also likely the case that at least some enterprises control
>> portions of
>> their environments well enough that mostly-IPv6 could potentially be much
>> more viable than a residential environment.  For example, a retail
>> store chain using
>> HTTP-based POS terminals and kiosks may have enough control over their
>> environment
>> that they could ideally deploy an IPv6-only environment and just use
>> NAT64/DNS64
>> to get to some of their supplier websites that still require IPv4.
>> It might also be attractive to some US Government agencies who control
>> the devices and clients within their network to use this approach as part
>> of meeting the OMB September 2014 mandate for IPv6 client support.
>> That could be simpler for those agencies than rolling out a dual-stack
>> environment.
>> (I'm very curious if either of these cases exists in production in the
>> field today...)
>>
>>       Erik
>>
>
> Why would anyone in their right mind chose to deploy NAT64/DNS64 in a
> commercial environment given the prices I've seen for that functionality?
>


If your situation is that you need a middlebox as part of an IPv4
exhaustion remediation, NAT44 and NAT64 are largely the same costs in
my experience.  YMMV.  For the particularly cost conscious and FOSS
friendly, there are FOSS options for both.

NAT64 is in-fact cheaper since only non-IPv6 flows need translation as
where NAT44 requires translation of all flows.

CB
> I can't imagine them wanting something like that in operations either.
>
> It's likely to be much cheaper to let legacy applications die off
> naturally, run dual stack or even dual servers for some systems, and
> deploy a combination of simple forward and reverse web proxies for the
> rest (assuming web based apps).
>
> AFAIK There's still stuff happily running Bisync (BSC) out there (over
> IP tunnels) and support for that was deprecated in the 1970's in favour
> of SNA. So I wouldn't hold your breathe waiting for 100% migration to
> IPv6. It's going to be pretty easy to maintain a private IPv4 - IPv4
> network over a GRE tunnel over an IPv6 Internet for a very long time yet.
>
>>
>> On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>
>>     On Aug 7, 2013 9:24 PM, "Brian E Carpenter"
>>     <[e-mail] <mailto:[e-mail]>>
>>     wrote:
>>     >
>>     > On 08/08/2013 16:08, cb.list6 wrote:
>>     > > On Aug 5, 2013 9:49 PM, "Brian E Carpenter"
>>     <[e-mail] <mailto:[e-mail]>>
>>     > > wrote:
>>     > >> On a different topic, section 5 covers IPv6-only issues.
>>     > >> I'm a bit concerned that this might need a health warning:
>>     > >> deploying NAT64/DNS64 might cause pain and suffering.
>>     > >> Perhaps after this text:
>>     > >>
>>     > >>>    Together, RFCs
>>     > >>>    6146 and RFC 6147 provide a viable method for an
>>     IPv6-only client to
>>     > >>>    initiate communications to an IPv4-only server.
>>     > >> we should add something like:
>>     > >>
>>     > >>    At enterprise level, operating NAT64 and DNS64 services for
>>     > >>    heavy usage may have significant practical implications.
>>     > >>
>>     > >
>>     > > Can you be more specific? Pratical data?
>>     >
>>     > Not really, because I've never operated one in real life. It doesn't
>>     > strike me as the sort of service that most enterprise network
>>     > managers will be familiar with, and a v6-only site needing a normal
>>     > level of access to v4-land would end up sending most of its external
>>     > traffic via NAT64 and most of its external DNS queries via DNS64.
>>     > Therefore, these would become an important single point of failure
>>     > and a potential bottleneck. The text doesn't seem to point this out.
>>     >
>>
>>     Agree with Joel, nat64 will be parity with common nat44 and
>>     firewalls in terms of availability
>>
>>     Regarding majority of traffic, i believe the scales have tipped to
>>     show v6 is the majority for campus networks, which is the best
>>     proxy in the available data
>>
>>     http://www.worldipv6launch.org/measurements/
>>
>>     These numbers also skew low since Apple has a non-deterministic
>>     happy eyeballs
>>
>>     Given that enterprises and all users of IP are out of ipv4, so
>>     they need to not use ipv4 yet have access to it, guidance against
>>     nat64 will frustrate the issue.
>>
>>     Guidance should be given to make as many flow v6 e2e. Full stop.
>>
>>     CB
>>
>>
>>     >    Brian
>>     >
>>     > > CB
>>     > >
>>     > >> Also, the last paragraph of section 5:
>>     > >>
>>     > >>>    It is worth noting that for IPv6-only access networks
>>     that use
>>     > >>>    technologies such as NAT64, the more content providers (and
>>     > >>>    enterprises) that make their content available over IPv6,
>>     the less
>>     > >>>    the requirement to apply NAT64 to traffic leaving the
>>     access network.
>>     > >> A reference to RFC 6883 would fit nicely there.
>>     > >>
>>     > >> Regards
>>     > >>    Brian
>>     > >> _______________________________________________
>>     > >> v6ops mailing list
>>     > >> [e-mail] <mailto:[e-mail]>
>>     > >> https://www.ietf.org/mailman/listinfo/v6ops
>>     > >
>>
>>     _______________________________________________
>>     v6ops mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>
>
> --
> Regards,
> RayH
>