[ppml] Various IPv6 issues

[mack]

1) I oppose allowing blanket allocations of /48s by an LIR.
A /48 is close to infinite for practical purposes but is not infinite.
I agree with a /56 for 'residential' use and /48 for 'commercial' use.
This is basically the current guideline.  Residential subnets are likely to
be dynamic rather than static for routing aggregation reasons and are unlikely
to need more than 256 subnets.  Four tiers seems sufficient:
/12 RIR
/32 LIR
/48 'commercial site'
/56 'residential site'

2) IPv6 renumbering happens.  We need a policy that says a network
with X nodes is eligible for a /48 and with Y nodes is eligible for a /32.

3) IPv6 NAT is going to happen.  It is going to be one to one rather than
one to many which prevents breaking most protocols.  ULA-C is not dead yet.
Routable ULA-C is no different from PI /48 space.  It just puts all of the
filterable prefixes in one basket.

4) ARIN seems to be allocating on /29 boundaries to allow expansion while maintaining aggregation.
This is a good thing.  Obviously gaps can be filled in later if needed.

5) Geographically dispersed organizations will need more than a single /32 if a /32 is the
smallest announcement and we do not wish to de-aggregate.  Traffic engineering is also
going to require either A) a new routing protocol, B) changes to BGP, C) deaggregation
or D) multiple /32s.

We need some policy with this in mind.

Example with two locations, 2 transit providers and a link:
Transit1 in location A.
Transit2 in location B.
Transport between A and B via Layer 2 connection (billed at 95th).

Advertising the same prefix in both locations means that traffic
from Transit2 will exit only in location B.
But may actually be destined for A.

The obvious solution is to apply for a second /32.

I am not sure how ARIN expects these aspects to be handled.
Guidance here would be useful.

I am not sure how many companies fall in this category but I would venture to say it is a
substantial consideration.

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