Subject: Chair's review: draft-ietf-6man-ipv6-address-generation-privacy

From: Ole Troan <[email-masked]>
Date: Fri, 6 Mar 2015 21:51:07 +0100

Here is the chair’s/document shepherd review of the draft-ietf-6man-ipv6-address-generation-privacy document.
In general this is well written document, and with these issues fixed would be ready for publication.

Issue #1:
The reference to RFC2462 in the Introduction; is that meant as a "historical" reference, then it should point to RFC1971, otherwise it should be updated to RFC4862.

Issue #2:
With regards to the use of "network" in several places, e.g
"An address that does not vary over time within the same network."

Suggest s/network/IPv6 link/
A "network" can be a larger piece of topology where addresses would change.

Issue #3 (nit):
Title: 3 . Weaknesses in IEEE-identifier-based IIDs
It might be more general to replace IEEE-identifier-based IIDs with "Constant IIDs" which you define in the terminology session? Or define it?

Issue #4 - section 3.1:
CURRENT:
  As with other identifiers, an IPv6 address can be used to correlate
  the activities of a host for at least as long as the lifetime of the
  address.  The correlation made possible by IEEE-identifier-based IIDs
  is of particular concern because MAC addresses are much more
  permanent than, say, DHCP leases.  MAC addresses tend to last roughly
  the lifetime of a device's network interface, allowing correlation on
  the order of years, compared to days for DHCP.

It’s our understanding that DHCP doesn’t change addresses when the lease expires, it just does a renew.  This means that a DHCP provided address could last for a long time and have many of the correlation problems that IEEE MAC based addresses have.  Further, we think that even for a node that leave a link and comes back later, it may be given the same IP address (if available) as it had before because the DHCP server remembered it MAC address.  We think the text in the draft overstates the differences and implies that DHCP addresses are much better in this regard.

Issue #5 - section 3.2:

OLD:
 Even if the host does not respond, the first hop router will usually respond with
 an ICMP Address Unreachable when the host is not present, and be
 silent when the host is present.

NEW:
 Even if the host does not respond, the first hop router will usually respond with
 an ICMPv6 Destination Unreachable message when the host is not present, and be
 silent when the host is present.

Issue #6 - section 3.3:
OLD:
 This erases much of the protection against address
 scanning that the larger IPv6 address space was supposed to provide
 as compared to IPv4.

NEW:
 This erases some of the protection against address
 scanning that the larger IPv6 address space could provide as compared to IPv4.

As far as we remember, the IPv6 was not designed specifically to protect against scanning attacks, it was a by product of the design.
“Erases much of the protection” seems overstated and we suggest replacing “much” with “some”.

Issue #7- section 4:
OLD:
 The idea was for temporary addresses to be used
 for outgoing connections (e.g., web browsing) while maintaining the
 ability to use a stable address when more address stability is
 desired (e.g., in DNS advertisements).

NEW:
 The idea was for temporary addresses to be used
 for outgoing connections (e.g., web browsing) while maintaining the
 ability to use a stable address when more address stability is
 desired (e.g., published in DNS).

Issue #8 - section 5.2:
s/MAC-derived suffixes/IEEE-identifier-based IIDs

Issue #9 - section 5.3:
There is nothing actionable here, we suggest this section is removed.

Issue #10 - References:
The references section may need more review. There are very few references that this document depends on.
For the Normative references it might be prudent to move obsoleted document references out of the normative secion. RFC1972, RFC2462, RFC3041, RFC3484.
RFC3314 and RFC6265 may also go in the Informative section.

Best regards,
Ole and Bob

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 9 Mar 2015 08:57:25 +0000 (UTC)

<snip>

Issue #4 - section 3.1:
CURRENT:

/ Actually, looking at the DHCPv6 text in the draft, it is probably necessary to state that DHCPv6 address selection is influenced by whether the client requests an IA_NA (Identity association for non-temporary addresses) or an IA_TA (
Identity association for temporary addresses) (discussed in section 12. of RFC3315)

<snip>