[ppml] Practical alternatives to v6 deaggregation for ISP/NSPs

[Stephen Sprunk]

Thus spake "Kevin Day" <kevin at your.org>
> On Mar 12, 2008, at 12:14 AM, Scott Leibrand wrote:
>> You could try announcing your deaggregates (/36 or whatever), in
>> addition to announcing the /32, and *without* no-export set.  This
>> is what I envision we'll do when we deploy IPv6.  Most people I've
>> talked to agree that, as long as you're announcing the /32, that
>> should be allowed, and it's up to everyone to decide whether or not
>> to accept the more-specifics.  If you're paying a transit provider
>> to do so, they should accept them, and should accept the same more-
>> specifics from their peers.  As long as your ISPs (or their transit
>> providers) peer with each other, and accept the more-specifics from
>> each other, you should have full reachability, and you shouldn't
>> have to transport the packets yourself (you're paying your ISPs to
>> do that).
>
> That doesn't work though... Imagine this scenario:
>
> POP A = 2001:1234:1000/36.
> POP B = 2001:1234:2000/36.
>
> POP A <---> Transit 1 <--> Big NSP 1 <---> Big NSP 2 <--> Transit 2
> <---> POP B

AFAIK, if your POPs are completely independent, i.e. you have no backside 
network connecting them, then they're two different networks and you qualify 
for two /32s -- preferably a /31 in case you ever do connect them together.

(I assume reality is a lot more than two sites, though, which makes this a 
very ugly "solution", but I don't see anything better.  Most ARIN policy is 
based around the assumption that each org operates a single network or a 
group of networks with complete internal reachability.)

>> Alternately, you could perhaps give back your /32, and instead get a
>> PI /48 from ARIN (under the end user policy) for each site (or
>> perhaps a contiguous /44 to get you a /48 per site).  I'm not sure
>> if that policy applies in your case, or if that would be a better
>> idea overall in your situation than using a /32, but it seems more
>> reasonable than trying to get additional /32's or "critical
>> infrastructure" blocks.
>>
>
> Well... For one, we need to be able to assign /48's to our customers,
> so I'm not sure an end-user allocation is going to work for us.
> Secondly, I don't believe current policy allows for getting more than
> one /48 without using up the first.

If you need to assign space to customers, you are an LIR and do not qualify 
for end-user PI space.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking