Help with DHCPv6 client-identifiers

[Peter Grandi]

[ ... ]

>>> RFC reference please. As far as I'm concerned, IPv6 supports
>>> prefix lengths right up to /128. Due to various protocol
>>> brokenness, it's difficult to configure hosts with longer
>>> prefixes than /64, but that is a different issue.

>> My guess: The language in RFC 4291 which says that interface
>> identifiers are 64 bits:

 "For all unicast addresses, except those that start with the
  binary value 000, Interface IDs are required to be 64 bits
  long and to be constructed in Modified EUI-64 format."

Very agreed (0::/3 is a reserved range for "special" addresses),
other interesting quotes from RFC 4291:

 "In some cases, an interface's identifier will be derived directly from
  that interface's link-layer address."

Only in some cases...

 "The same interface identifier may be used on multiple interfaces on a
  single node, as long as they are attached to different subnets."

Does not necessarily be the interface link address.

 "Note that the uniqueness of interface identifiers is independent of
  the uniqueness of IPv6 addresses.  For example, a Global Unicast
  address may be created with a local scope interface identifier and a
  Link-Local address may be created with a universal scope interface
  identifier."

The two halves of an IPv6 address really have different roles.

 "where "u" is the universal/local bit, "g" is the individual/group
  bit,"

Bits 70 and 71 are special outside the reserved 0:/3 range.

 "The motivation for inverting the "u" bit when forming an interface
  identifier is to make it easy for system administrators to hand
  configure non-global identifiers when hardware tokens are not
  available."

Link layer addresses again not mandatory.

 "The use of the universal/local bit in the Modified EUI-64 format
  identifier is to allow development of future technology that can take
  advantage of interface identifiers with universal scope."

Ahhhh.

 "When no built-in identifier is available on a link, the preferred
  approach is to use a universal interface identifier from another
  interface or one that is assigned to the node itself. When using this
  approach, no other interface connecting the same node to the same
  subnet prefix may use the same identifier."

Weird, but IPv6 prefers but does not mandate link layer addresses.

 "If there is no universal interface identifier available for use on the
  link, the implementation needs to create a local-scope interface
  identifier. The only requirement is that it be unique within a subnet
  prefix."

If a non-linklayer address is used to make the interface id, it
must have local scope. This seems unwise to me, I guess that it is
entirely possible to use globally unique non-linklayer addresses.

To me all these mean that:

  * As stated, the MEUI-64 format requirement implies always
    interpreting the lower 64 bits as an interface address,
    which means that interpreting any leading part of the bottom
    64 bits as part of a routable subnet prefix makes little sense.

  * Bits 70-71 of an unicast address outside prefix 0::/3 MUST
    be interpreted as a U and G bits.

  * If bit 70 of an IPv6 address is zero, it is possible to
    hand-assign arbitrary ingterface addresses, even if this is
    not really recommended (there is no "MUST" or "SHOULD") if
    the 64-bit interface address can be derived from a link
    address.

  * There seems to be some forward looking plan to have IPv6
    subnet addresses be like "URL"s (denoting a [path to] place)
    with their bottom 64 bits (if outside 0::/3) and with bit 70
    as "URN"s (denoting a resource, globally if bit 70 is on,
    and withing the subnet if it is off). A bit like:

      ipv6://[64 bit subnet prefix]/[64 bit interface id with U off]#port
      urn:ipv6interface:[64 bit interface id with U on]#port

Just noticed another scary bit, the "Currently" in:

  "Currently, IPv6 continues the IPv4 model in that a subnet prefix is
   associated with one link. Multiple subnet prefixes may be assigned to
   the same link."

But I have been using the same subnet prefix over multiple links in IPv4
and it "works" (magic of /32 routes). :-). I guess it will continue to
"work" in IPv6 (with /128 routes which are needed anyhow for non-subnet
addresses like various levels of "multicast" etc.). :-)

[ ... ]

> So it would seem that 64bit host identifiers are mandated for
> most purposes, but the same RFC also specifies that hosts must
> not make assumptions about the structure of an address. In
> fact that very same section talks about hosts having a
> variable understanding of the structure :

The language here:

 "IPv6 unicast addresses are aggregatable with prefixes of arbitrary
  bit-length, similar to IPv4 addresses under Classless Inter-Domain
  Routing."

to me just means is that one can conceivably *write* them with
arbitrary bit-length prefixes, rather than *use* them for routing.

This seems stronger:

 "Though a very simple router may have no knowledge of the internal
  structure of IPv6 unicast addresses, routers will more generally have
  knowledge of one or more of the hierarchical boundaries for the
  operation of routing protocols.

  The known boundaries will differ from router to router, depending on
  what positions the router holds in the routing hierarchy."

But all it seems to say that a "very simple router" may route on
all 128 bits, and indeed it may, as after all, in the limit,
each full address is a globally unique interface locator, one
can always ignore the subnet structure of IPv6, and one can
always reach it using 128 bit route tables. But this is not the
same as *requiring* routers to always support up to 128 bit
route tables.

The real question is what the longest subnet prefix length that
*must* be recognized by a router, not the one that *can* be
recognized by a router.

> Personally, it strikes me as short sighted to enforce such a
> large subnet size. The answer of course is that it still leaves
> a vast number of possible subnets, bt then I suspect the
> designers of the IPv4 addressing system probably also considered
> the address space to be vast.

Well, nearly 2^64 is pretty huge for subnets, especally as each
subnet can still have 2^63 (or a bit less/more) interfaces.

But the killer RFC on this topic is not the addressing one,
which is about laying minimal ground rules, but more properly
RFC 5375:

 "Using a subnet prefix length other than a /64 will break many features
  of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery
  (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6
  [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with
  Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation
  (SHIM6) [SHIM6], among others.  A number of other features currently
  in development, or being proposed, also rely on /64 subnet prefixes.

  Nevertheless, many IPv6 implementations do not prevent the
  administrator from configuring a subnet prefix length shorter or
  longer than 64 bits.  Using subnet prefixes shorter than /64 would
  rarely be useful; see Appendix B.1 for discussion.

  However, some network administrators have used prefixes longer than
  /64 for links connecting routers, usually just two routers on a
  point-to-point link.  On links where all the addresses are assigned by
  manual configuration, and all nodes on the link are routers (not end
  hosts) that are known by the network, administrators do not need any
  of the IPv6 features that rely on /64 subnet prefixes, this can work.

  Using subnet prefixes longer than /64 is not recommended for general
  use, and using them for links containing end hosts would be an
  especially bad idea, as it is difficult to predict what IPv6 features
  the hosts will use in the future.

  Appendix B.2 describes some practical considerations that need to be
  taken into account when using prefixes longer than /64 in limited
  cases.

  In particular, a number of IPv6 features use interface identifiers
  that have a special form (such as a certain fixed value in some bit
  positions). When using prefixes longer than /64, it is prudent to
  avoid certain subnet prefix values so that nodes who assume that the
  prefix is /64 will not incorrectly identify the addresses in that
  subnet as having a special form.

  Appendix B.2 describes the subnet prefix values that are currently
  believed to be potentially problematic; however, the list is not
  exhaustive and can be expected to grow in the future.

  Using /64 subnets is strongly recommended, also for links connecting
  only routers. A deployment compliant with the current IPv6
  specifications cannot use other prefix lengths.  However, the V6OPS WG
  believes that despite the drawbacks (and a potentially expensive
  network redesign, if IPv6 features relying on /64 subnets are needed
  in the future), some networks administrators will use prefixes longer
  than /64."

 "Based on RFC 3177 [RFC3177], 64 bits is the prescribed subnet prefix
  length to allocate to interfaces and nodes.

  When using a /64 subnet length, the address assignment for these
  addresses can be made either by manual configuration, by a Dynamic
  Host Configuration Protocol [RFC3315], by stateless autoconfiguration
  [RFC4862], or by a combination thereof [RFC3736].

  Note that RFC 3177 strongly prescribes 64-bit subnets for general
  usage, and that stateless autoconfiguration on most link layers
  (including Ethernet) is only defined for 64-bit subnets.  While in
  theory it might be possible that some future autoconfiguration
  mechanisms would allow longer than 64-bit prefix lengths to be used,
  the use of such prefixes is not recommended at this time."

 "EUI-64 'u' and 'g' Bits

  When using subnet prefix lengths other than /64, the interface
  identifier cannot be in Modified EUI-64 format as required by
  [RFC4291]. However, nodes not aware that a prefix length other than
  /64 is used might still think it's an EUI-64; therefore, it's prudent
  to take into account the following points when setting the bits.

  Address space conservation is the main motivation for using a subnet
  prefix length longer than 64 bits; however, this kind of address
  conservation is of little benefit compared with the additional
  considerations one must make when creating and maintaining an IPv6
  addressing plan.

  The address assignment can be made either by manual configuration or
  by a stateful Host Configuration Protocol [RFC3315].

  When assigning a subnet prefix of more then 70 bits, according to RFC
  4291 [RFC4291], 'u' and 'g' bits (the 71st and 72nd bit, respectively)
  need to be taken into consideration and should be set correctly.

  The 71st bit of a IPv6 address is the inverted 'u' (universal/local)
  bit and is used to determine whether the address is universally or
  locally administered.  If 1, the IEEE, through the designation of a
  unique company ID, has administered the address.  If 0, the address is
  locally administered.  The network administrator has overridden the
  manufactured address and specified a different address.

  The 'g' (the individual/group) bit is the 72nd bit and is used to
  determine whether the address is an individual address (unicast) or a
  group address (multicast).  If '0', the address is a unicast address.
  If '1', the address is a multicast address.

  In current IPv6 protocol stacks, the relevance of the 'u' and 'g' bits
  is marginal and typically will not give an error when configured
  wrongly; however, future implementations may turn out differently if
  they process the 'u' and 'g' bits in IEEE-like behavior.

  When using subnet lengths longer then 64 bits, it is important to
  avoid selecting addresses that may have a predefined use and could
  confuse IPv6 protocol stacks.  The alternate usage may not be a simple
  unicast address in all cases.  The following points should be
  considered when selecting a subnet length longer then 64 bits.

  B.2.5.  Anycast Addresses [ ... ]"

Of course, all of the above does not matter if someone knows better...

Also I did a search on some relevant RFC 5375 phrase and got this
summary of the whole debate:

  http://etherealmind.com/allocating-64-wasteful-ipv6-not/

The only conceivable use of prefixes narrower than /64 I can imagine is
for inter-router links, as in some /126 example in this very useful
summary of OSPFv3 etc:

  http://www.cablelabs.com/cablemodem/ipv6/ipv6_routing.pdf

But even those are questionable. Because one can use for inter-router
links local addresses (probably) or just a /64 assigned to multiple
links (in IPv4 too, e.g. a /24 if one has not that many routers).
Unusual, but given the semantics of the case, quite reasonable.

Other interesting bits of RFC 5375:

 "The practically unlimited size of an IPv6 subnet (2^64 bits)
  reduces the requirement to size subnets to device counts for the
  purposes of (IPv4) address conservation."

As someone pointed out before that larger subnets than /64 are
pointeless, not just smaller, so in practice all subnet prefixes should
be /64 and nothing else.

 "The proposed Host-Density (HD) value [RFC3194] for IPv6 is 0.94
  compared to the current value of 0.96 for IPv4.  Note that with
  IPv6, HD is calculated for sites (e.g., on a basis of /56),
  instead of for addresses as with IPv4."

Which implies that IPv6 is really all about allocating and using network
prefixes more than individual addresses (which are extremely cheap).