IETF Logo Mail Archive

Re: IPv6 only host NAT64 requirements?

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 20 November 2017 14:04 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E07126C0F for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 06:04:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2HWI0jKzwh9 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 06:04:43 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9ABD129A9B for <ipv6@ietf.org>; Mon, 20 Nov 2017 06:04:43 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ED99120072 for <ipv6@ietf.org>; Mon, 20 Nov 2017 09:06:41 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 060AD829D1 for <ipv6@ietf.org>; Mon, 20 Nov 2017 09:04:43 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6man WG <ipv6@ietf.org>
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: <0C83562D-859B-438C-9A90-2480BB166737@employees.org>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> <m1eEIGX-0000FjC@stereo.hq.phicoh.net> <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <CAKD1Yr1aFwF_qZVp5HbRbKzcOGqn==MRe_ewaA8Qc8t3+CVu_Q@mail.gmail.com> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAFU7BARoXgodiTJfTGc1dUfQ8-ER_r8UOE1c3h-+G0KTeCgBew@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 20 Nov 2017 09:04:42 -0500
Message-ID: <29312.1511186682@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7vTScKzMK01CQs5jkk0xTAa1M5s>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 14:04:45 -0000

Ole Troan <otroan@employees.org> wrote:
    >> NAT64 "A" ----- IPv4-only servers in a data center
    >> /
    >> IPv6-only node---<
    >> \
    >> NAT64 "B" ----- IPv4 Internet

    > Firstly this seems like it is over engineered. Has anyone actually
    > deployed NAT64 this way?

Yes, it's a really good way to deal with overlapping RFC1918 ranges (used for
managing devices) in different data centers. (The boot server is always at
192.168.1.2, the serial console is always at 192.168.1.3, etc.)

I've done this as far back as 2008 (with "NAT64" being implemented by a TCP
proxy terminating the entire IPv6/32)

I didn't have to pick the right source address, but I can see how this might
be an issue.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email