Re: Is NAT66 a help in migration to IPv6?

Michael

Of course, IPv4 host have a single IPv4 address (most of the time) but the network operator has to manage TWO IPv4 addresses per host: one for packets 'inside' and one for packets 'outside' and the NAT log is used to do the mapping... So, it is painful as well (this was my point expressed in a 2nd degree way -- sorry)

-éric

-----Original Message-----
From: "Ackermann, Michael" <MAckermann@bcbsm.com>
Date: Tuesday, 1 December 2020 at 16:30
To: Eric Vyncke <evyncke@cisco.com>, "otroan@employees.org" <otroan@employees.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man WG <ipv6@ietf.org>
Subject: RE: Is NAT66 a help in migration to IPv6?

    FYI
    This may just be my interpretation of the comment below, but .......
    It is not common at most enterprises that we have two IPv4 addresses per host.    Rather a single 1918 address internally and then NAT to a registered public address for external traffic. 
    Thanks
    Mike

    -----Original Message-----
    From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Eric Vyncke (evyncke)
    Sent: Tuesday, December 1, 2020 7:48 AM
    To: otroan@employees.org; Brian E Carpenter <brian.e.carpenter@gmail.com>
    Cc: 6man WG <ipv6@ietf.org>
    Subject: Re: Is NAT66 a help in migration to IPv6?

    [External email]

    Ole,

    You nailed it... I was (and still am) fan of RFC 8028 and SADR (draft-ietf-rtgwg-dst-src-routing) but there is a lot of inertia in "enterprise" networks where the catch22 game is still there: little mid-size networks deployed hence manufacturers do not implement :-( Little IPv4 addressing shortage pressure for those mid-size network

    BTW, enterprises already have 2 IPv4 addresses per host and it is a pain: the RFC 1918 one and the shared public one... ;-)

    -éric

    -----Original Message-----
    From: ipv6 <ipv6-bounces@ietf.org> on behalf of "otroan@employees.org" <otroan@employees.org>
    Date: Tuesday, 1 December 2020 at 00:12
    To: Brian E Carpenter <brian.e.carpenter@gmail.com>
    Cc: 6man WG <ipv6@ietf.org>
    Subject: Re: Is NAT66 a help in migration to IPv6?

        > Answering the question in the subject field: No [RFC2993] [RFC4864] [RFC6296].
        >
        >> IMHO: no NAT66 -> no progress for IPv6 in Enterprises. Because redundant connectivity to Carriers is needed very often.
        >
        > It is, and that's why the failure of SHIM6 is very sad. But the real failure is the reluctance of enterprise operators to do what comes naturally in IPv6: if you have two providers, run two prefixes everywhere [RFC8028]. That's why there is still, sadly enough, a case for [RFC6296]. Sadly, because [RFC2993] explains why NAT or NPT is a problem, and [RFC4864] explains how to avoid them (and needs [RFC8028], which came very late, sorry).

        The failure of SHIM6 or ILNP or even 8+8 is indeed sad.
        MPMH hasn't exactly taken off. I ran it for a while but gave up. 8028 isn't enough, SADR is a big change.
        Enterprises don't want to depend on host behaviour for exit selection.
        Ref, the slaac-renum discussion I'd imagine Enterprises also wants a level of isolation from ISP/global addressing.
        Keeping track of 4++ addresses per-host isn't a favourite with Enterprise network operators either.
        And we can't exactly say that host implementations and applications have caught up with MPMH either.

        PI or LISP MH are available solutions.
        Multi-homing with NAT66 wouldn't work nearly as well (and you could argue stick with v4 then, which I guess is what they do).

        Ole

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

    The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.

     Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.