Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)
draft-ietf-pcp-nat64-prefix64-06

[Ballot comment]
4.3:

  If the PCP client
  fails to contact a given PCP server, the PCP client SHOULD clear the
  prefix(es) and suffix(es) it learned from that PCP server.

What constitutes "fails to contact"? Is there some timeout involved there? And I'm not totally clear on why I'd clear the list just because I "failed to contact" the server. Could you explain?

[Ballot comment]

- general: Is there any case where a bad actor could
use this multiple times (say after reboots/resets that
are visible to the ISP) getting different answers each
time and thus being able to infer that some prefix
similar to one received is now topologically nearby
the bad actor?  E.g. if I see Prefix#1, then reboot,
wait a while and next see Prefix#1+10, I might
conclude that 9 other nearby home gateways have
rebooted perhaps and try use that for nefarious
purposes. Can we think of any such nefarious purpose?
I can't, hence this not being a discuss:-) However,
if there were such a nefarious purpose, maybe it'd be
worth some advice to deployments about making the
prefixes unpredictable? (Just wondering.)

- general: More friendly to DNSSEC? Fantastic!

- 3.2.1: can a host synthesize AAAA records sufficient
to verify all DNSSEC? Just wondering, but I'd have
guessed some more detail might be needed. Is there
really enough specified here?

- Fig 1: Adding a "See Figure 2" below the IPv4 Prefix
List would be clearer.

- 4.3: I wasn't clear what an invalid prefix might be
here - do you mean a bogon, such as 10/8? (Sorry,
maybe I was reading too quickly.)

IESG/Authors/WG Chairs:

IANA has reviewed  draft-ietf-pcp-nat64-prefix64-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has a question about the request made in the IANA Considerations section of this document.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document there is a single action which IANA must complete.

In the PCP Options subregistry of the Port Control Protocol (PCP) Parameters registry located at:

http://www.iana.org/assignments/pcp-parameters/

a single value from the optional-to-process range is to be registered as follows:

Name: PREFIX64
Reference: [ RFC-to-be ]

1) IANA Question: What entries should be added for PREFIX64 in the following fields of the PCP Options registry as defined in RFC6887?

Purpose
Valid for Opcodes
Length
May Appear in
Maximum Occurances

2) IANA wants to point out the URL in the IANA Considerations section:

Please change the URL:

FROM:
http://www.iana.org/
assignments/pcp-parameters/pcp-parameters.xml#option-rules

TO:
http://www.iana.org/assignments/pcp-parameters

This will ensure the URL will always work and point to the most current
version/extension.

IANA understands that this action is the only one required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Learning NAT64 PREFIX64s using PCP) to Proposed Standard


The IESG has received a request from the Port Control Protocol WG (pcp)
to consider the following document:
- 'Learning NAT64 PREFIX64s using PCP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-02-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a new PCP extension to learn the IPv6
  prefix(es) used by a PCP-controlled NAT64 device to build
  IPv4-converted IPv6 addresses.  This extension is needed for
  successful communications when IPv4 addresses are used in referrals.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64/ballot/


No IPR declarations have been submitted directly on this I-D.