Re: IPv6 only host NAT64 requirements?

james woodyatt <> Thu, 16 November 2017 00:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C63E124319 for <>; Wed, 15 Nov 2017 16:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YoRuUe4ZytF6 for <>; Wed, 15 Nov 2017 16:28:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1F59120227 for <>; Wed, 15 Nov 2017 16:28:24 -0800 (PST)
Received: by with SMTP id p9so19233971pgc.8 for <>; Wed, 15 Nov 2017 16:28:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Pi77uB+WpIthVFtdwpr4k+OTmwMZK6gAbBrpBx5lrqE=; b=iwKxEF7/diO7dmh0SBtYiLPThmgpKsXoIl2neOCQV+sfOtOZycbjgxffZMH268mJWm JBZHotI2BBIebpUg/eK0jgOKE6zESb54D2igNksphrjGdTsdzXUZaa86RC3CahYqbd1A JOg32lsjvcOV6zW7i+ZIPcOpqgRUGKRgBJfh/VZA2qtlj2aZFwBVpEaablAcI8HwqTyy Vj09E5sSrI1eL2trD5gVbvWGvN10c/ij8dXc6v7jphb+4eRU5hQ/+N5Iy/iF8dg6dZKN PD7YgQj8FYauzPuV0IttNwaIjG7yGPh406afnf35noX4M/EAuiYpsrOLCH5F8LkqcKs4 DDLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Pi77uB+WpIthVFtdwpr4k+OTmwMZK6gAbBrpBx5lrqE=; b=P2eMrbkD1iiln/ApC/XQJDgqDXW5PDf/4xteVofdaQvTm/iKWp2PkBL26r1hkT5e2K 18b7xIXTRuTgTkhncojm9GNzU0KEL007JvnfkmxZzwrFgMjNe+2QG3vutYfAzpc5TLZL uAHBlu0xdFGon3JF0R0ZqDm6C74fDHgP0+KH8DZCuPPuxwALVi2Zkdvf/vxqxvanoGJx o9bIC2YUeI+WDrA5YInb9FYG6CIdAGUMTpuidJAJxj4JljHglCEjwcDyDM8gcfye3c1i UmkqxF7HNg49aftPvKB1cS3i2SdCRctoSUG9HJkDKQYhaKdn9NGDEC4EPzbPOxmOXiu2 buFw==
X-Gm-Message-State: AJaThX4DkpsHKWczwuIpcnbcc8yvmuRAAqghKJ+edjOzeVKSmeuBUHRY BXA8oqaomXsFjMJQ+ig5l2B2oQ==
X-Google-Smtp-Source: AGs4zMZHsPC/QZliJTZUx0kGteaxA0aEpAyjqN0v8rL9aDnDt0yNeS0c4XBQH8GznN4ay0JbWhV+bQ==
X-Received: by with SMTP id t11mr19560781pfk.210.1510792104217; Wed, 15 Nov 2017 16:28:24 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:788d:282:9de1:e7b9? ([2620:0:10e7:10:788d:282:9de1:e7b9]) by with ESMTPSA id c1sm41240095pfa.12.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 16:28:23 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_99EB5C14-0D26-49BC-AAAB-80D480E1AFC2"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Wed, 15 Nov 2017 16:28:22 -0800
In-Reply-To: <>
Cc: Jen Linkova <>, 6man WG <>, Mark Andrews <>
To: Ole Troan <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Nov 2017 00:28:27 -0000

On Nov 15, 2017, at 15:24, Ole Troan <> wrote:
>>>>> IMHO the optimal solution is:
>>>>> - the network SHOULD provide a host with NAT64 prefix information in RA;
>>>> Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye gods, this is the very last thing that should be jammed into RA messages.
>>> Do we really want PCP in IPv6?
>> If we have any kind of NAT, then we need PCP. Using NAT without PCP considered harmful. That goes for NAT64 and NAT66.
> It's not for the lack of trying that IPv6 isn't adopted everywhere.
> As IPv4 address sharing ratio's increase, say good bye to endpoint independent NATs, IP fragmentation...
> But now I have to first implement a PCP client, discover the PCP server address, and then finally get the NAT64 prefix. ;-)

Having implemented a PCP client, I can say from experience that it is a lot easier than implementing a DHCPv6 client.

Oh, and you have to discover all the PCP server addresses (in addition to the PCP server anycast address by RFC 7723) before you can use RFC 7225 to discover the NAT64 network-specific prefix (NSP) for each one. If you’re really married to DHCPv6, then I suppose you could use RFC 7291 for that. But if you want to add those data to RA messages too, why not? (Oh right, I remember why not: because it’s a bad idea. Just use the anycast address.)

>>> Is PCP successful in IPv4?
>> Well, there was this: <>
>>> Or does it even work well with A+P based solutions?
>> Designed expressly for it.
> Ah, yes so it does.
> Doesn't work well with address and port dependent filtering though.

Is there a reason you think < <>> doesn’t work well? Seemed to work well when I implemented it.

--james woodyatt < <>>