[ppml] alternative to 2005-1
At 12:54 PM 2/9/2006, Daniel Golding wrote:
>On 2/9/06 12:45 PM, "Thomas Narten" <narten at us.ibm.com> wrote:
> >>> Also, why do you specify /19 for #5 under 22.214.171.124? Shouldn't
> someone with
> >>> a IPv4 PI /22 be able to get an IPv6 /48?
> >> It is just a line in the sand.
> >> I personally believe that a /22 is too small, however there are
> >> those who will think that an org with a /22 should be able to obtain
> >> a IPv6 PI address space.
> > Note: a /22 is only 2^10 addresses, or 1024. That's a pretty darn small
> > site, if you ask me.
> > A /19 is somewhat better, namely, 8192.
> > Still, I fear there are 10s to 100s of thousands of organizations in
> > this size. Remember, each entity with a PI assignment translates into
> > a routing slot in the DFZ.
> > Heck, even if we set a threshold of /16, we'd be saying "anyone who
> > can justify a class B assignment". I suspect that the number of end
> > sites meeting that criteria is pretty large.
> > I'd feel a lot more comfortable picking a threshold if I had a rough
> > idea of how many entities we're talking about who would qualify. Given
> > the above, even /19 sounds too low.
> > In the absense of data, I'd say be _very _ conservative, e.g., start
> > with a /16 (or higher).
>Again, we are headed down a road that we have been on before. The last
>2005-1 was defeated because of this point - the bar was set too high. I can
>understand those who wish for no end-site multihoming. I can understand
>those who wish for end-site multihoming similar to IPv4. However, I can't
>understand going in circles, which is exactly what we are doing.
This is deadlock again.
Martin Hannigan (c) 617-388-2663
Renesys Corporation (w) 617-395-8574
Member of Technical Staff Network Operations
hannigan at renesys.com