Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)
draft-ietf-pcp-nat64-prefix64-06
Yes
(Ted Lemon)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Stewart Bryant)
Note: This ballot was opened for revision 05 and is now closed.
Ted Lemon Former IESG member
Yes
Yes
(for -05)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -05)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -05)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -05)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -05)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -05)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -05)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -05)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2014-02-19 for -05)
Unknown
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?
Richard Barnes Former IESG member
No Objection
No Objection
(for -05)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-02-17 for -05)
Unknown
- 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.)
Stewart Bryant Former IESG member
No Objection
No Objection
(for -05)
Unknown