New ARIN ipv6 allocation policies

Brandon Butterworth brandon at rd.bbc.co.uk
Sun Sep 3 17:52:11 CEST 2006


> All of those incentives exist today.  The net effect
> of those incentives is a ~200/month growth in ASNs.

They adapt their swamp to fit the rules. I think it's
better to know where the swamp is as you can avoid
getting wet if you wish

> Regarding lawsuits, a simple, clear policy is the
> single best defense against lawsuits; how could
> anything be simpler than "PI allocations are made at
> /48 boundaries to organizations which already possess
> and qualify for a unique RIR-issued ASN"?

As the compromise is to let them have a swamp the price should be
they can only have one prefix in it, if they fill it they have to
renumber (once they fill registry provided slack) rather than get
another

> I agree that efforts to make the swamp swampier need
> to be resisted, but I don't think the pressure to
> swampify will be all that horrible.

I'd tolerate some local swamp for local enterprises,
it'd probably work out more beneficial than filtering
it all and letting an upstream DFZer look after it

So rather than per registry swamp it'd be nice if they had
one per country or similar boundary. I could then choose which
swamps matter to me, the rest can get by on default. Sub optimal
but we've aggreed sub optimal is OK by having a swamp.

> One thing I notice in that report is the complete
> absence of enterprises - all of the names listed are
> themselves service providers.

I see more garden shed hosters asking than enterprises

> More likely is some of the
> intentional deaggregation (consider the case of AS
> 6197, who advertise twice as many routes as they need,
> and are also near the top of the updaters list)...

If people are allowed to do that they will, in v6 world
it may be sensible not to. Those that would are probably
swamp candidates so they only get to polute swamp or
not swamp, not both. If I know not swamp won't deaggregate
then that's something less to worry about.

brandon



More information about the ipv6-ops mailing list