[ppml] PPML Digest, Vol 28, Issue 51

[mack]

This is not workable for a number of reasons.
1) It is in direct conflict with current RFCs.
2) It is in direct conflict with current auto-configuration implementations.
3) It breaks under at least one major vendors implementation of IPv6 when certain functionality is used.

Quote from vendor documentation:
If the compress mode is on, the IPv6 address is compressed similarly to the EUI-64 compression method (removal of bits [39:24]) to allow for the Layer 4 port information to be used as part of the key used to look up the QoS TCAM, but Layer 3 information is lost.

In practice the loss of data in these bits is inconsequential as they are a specific value (0xFFFE) or manually configured.  Manual configuration can set these to a known constant. I personally use (0x0000 or 0xFFFE).

Any change that significantly breaks current hardware under a common configuration is a very bad idea.

--
LR Mack McBride
Network Administrator
Alpha Red, Inc.

> -----Original Message-----
> Message: 1
> Date: Thu, 18 Oct 2007 19:17:39 -0400 (EDT)
> From: briand at ca.afilias.info
> Subject: [ppml] IPv6 assignment - proposal for change to nrpm
> To: "ARIN PPML" <ppml at arin.net>
> Message-ID:
>         <50228.192.35.166.161.1192749459.squirrel at look.libertyrms.com>
> Content-Type: text/plain;charset=iso-8859-1
>
> I propose changes to the current text of 6.5.4.1:
>
> Currently, it reads:
>
> 6.5.4.1. Assignment address space size
>
> End-users are assigned an end site assignment from their LIR or ISP.
> The
> exact size of the assignment is a local decision for the LIR or ISP to
> make, using a minimum value of a /64 (when only one subnet is
> anticipated
> for the end site) up to the normal maximum of /48, except in cases of
> extra large end sites where a larger assignment can be justified.
>
> The following guidelines may be useful (but they are only guidelines):
>
>     * /64 when it is known that one and only one subnet is needed
>     * /56 for small sites, those expected to need only a few subnets
> over
> the next 5 years.
>     * /48 for larger sites
>
> For end sites to whom reverse DNS will be delegated, the LIR/ISP should
> consider making an assignment on a nibble (4-bit) boundary to simplify
> reverse lookup delegation.
> [...]
>
> -----
>
> I propose the following as a replacement for the text:
>
> 6.5.4.1. Assignment address space size
>
> End-users are assigned an end site assignment from their LIR or ISP.
> The
> exact size of the assignment is a local decision for the LIR or ISP to
> make, using a minimum value of a /120 (when only one subnet is
> anticipated
> for the end site) up to the normal maximum of /48, except in cases of
> extra large end sites where a larger assignment can be justified.
>
> The following guidelines may be useful (but they are only guidelines):
>
>     * /120 for a very small customer with one subnet, using static
> assignments or DHCPv6
>     * /116 for a small customer with a few subnets, using static
> assignments or DHCPv6
>     * /112 for a medium size customer with a significant total number
> of
> hosts and/or subnets, using static assignments and/or DHCPv6
>     * /96 for large customers
>     * /80 for very large customers, or for customers using a proposed
> modified version of V6-autoconf
>     * /64 when it is known that one and only one subnet is needed, for
> a
> customer that absolutely requires either traditional IPv6
> autoconfiguration, or IPv6 host Interface Identifier cryptographic
> generation
>     * /60 for sites where a mix of IPv6-autoconfiguration and other
> address assignment techiques are required
>     * /56 for very large sites
>     * /52 for very, very large sites
>     * /48 for extremely large sites
>
> For end sites to whom reverse DNS will be delegated, the LIR/ISP should
> consider making an assignment on a nibble (4-bit) boundary to simplify
> reverse lookup delegation.
>
> -----
> The timeframe for the proposed change: immediate.
>
> The intent is to provide more current guidance, to both ARIN members,
> and to ARIN staff, based on available IPv6 technology, and for the
> encouragement of efficient assignment of IPv6 address space.
>
> Brian Dickson
> Afilias