Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-why64-01.txt>

From: Steven Blake <[email-masked]>
Date: Sun, 03 Aug 2014 00:38:44 -0400

I have reviewed draft-ietf-6man-why64-01.txt, and, modulo a few nits, I
think it is ready for publication.
 
The document endeavors to list the advantages of a fixed-size IID (Sec.
2), and to identify many of the issue which would arise if
variable-sized IIDs were allowed (Sec. 4).  I think it accomplishes
both.  Further, it is thorough in identifying many of the places in the
IPv6 specifications where a fixed-sized 64-bit IID is baked in (Secs. 1,
2, & 4).

In addition to the above, I believe the document does a good job of
defending 64 bits as a reasonable IID size (Secs. 3 & 5).

Comments:

Sec. 3.1: To elaborate, using a conservative HD-ratio = 0.94 (RFC4692),
there are ~5 trillion /48 prefixes available for allocation under
2000::/3.  ~1 trillion /48s are available with a relaxed HD-ratio =
0.89.  "There is no objective risk" indeed.

In cases where providers may not allocate sufficient space to number all
of a site's subnets with /64 prefixes, enabling the site to operate with
> /64 subnet prefixes (e.g., smaller IIDs) will not solve the problem in
the long run; such providers are likely to start allocating even less
address space to sites.  This would be an instance of a
social/commercial problem, not a technical one.

Sec. 3.2: If a campus site or enterprise gets a /48 allocation (or
shorter), then that provides quite a bit of space for hierarchical
allocation.  Compare to IPv4, where an organization with a /8 allocation
(e.g, Apple, AT&T, DOD, GE, HP, IBM, etc.) and with /24 subnets has the
same 16 bits for internal hierarchical allocation.

Sec. 4.2: CGA: "has defined a detailed algorithm how to generate"
                                                ^for

          ILNP: ILNP has Node Identifiers (RFC6741), not interface
identifiers.  The Node Identifiers are encoded in the IID field.

Regards,

// Steve