[AusNOG] Should we be a LIR for our customers and get them PI (Was: another ipv6 Q)

[Jeroen Massar]

On 2014-07-03 21:49, Tony wrote:
> Hi,
> 
> I am still confused I think.
> 
> As an SP we currently have a /32 from APNIC that is (I assume) from PA
> space and so it should only ever be announced as a single /32 by us.
> This means that any sub-allocations we might make to our customers are
> not provider independent and so if/when the customer moves on they need
> to return the address space to us and renumber using the address space
> provided to them from their new SP.

Correct.

> Assuming one of our customers (the larger ones that have multiple sites,
> and hundreds of devices) meet the APNIC criteria for their own PI space
> so that they never have to renumber IPv6 space when they change SP,
> there would appear to be two options:
> 
> 1. Customer becomes APNIC member and applies to APNIC directly for PI
> space. Assuming the meet the criteria (and pay up) they will get a /48
> of PI from APNIC - problem solved, costs customer annual APNIC fees.

That is indeed one way.

> 2. We assign the customer some PI space (that is then theirs forever).
> We can't/shouldn't do that out of our existing /32 and so would need to
> apply for some more space from APNIC that is able to be assigned as PI
> to our customers who request.

Fine up to here. You playing LIR means that the cost of the extra prefix
will be less as the base fees are already payed btw.

This whole concept is also why the LIR model exists, as it lowers the
amount of work done by the RIR as the LIR (should) know the procedures.

> Once we have this additional address space
> we would assign it in /48's to our customers who wanted this (assuming
> it was justified). We could either apply for a larger chunk at once to
> divide up for all of our existing and future customers that require it,
> or apply in /48 chunks each time.

Almost correct: You would request a separate PI prefix for each
customer/site.

Hence, there would not be any splitting happening.

> Can we get more space from APNIC for assigning as PI or do we need to
> get our /32 "converted" to be from the appropriate pool ?

Depending on your justification you should be able to get more, see below.

> We haven't
> gone too far yet into actually using our /32 so wouldn't be too much
> grief to do this at  this stage. I do need to know though if this is the
> correct way to go about it. We're also unlikely to use a /32 even if
> we're "giving away" /48's to large customers that then leave us at some
> point in the future. I'm fairly sure there is enough in a /32 to go
> around. Yes, I guess having customers IPv6 networks numbered out on OUR
> non-portable space might help to lock them into us by making it hard to
> change providers, but if this is the only reason they are staying with
> us as customers then we are doing something wrong.

Excellently stated.

The big question simply is: are you in the PA game or not.

If you are in the PA game, eg you are a hosting company, then having a
/32 is quite fine, even if you never even reach more than 400 /48s.
You will just be able to survive with that space for a long long time.
For the routing tables though you are just using 1 routing slot, hence
nobody will complain about it.

For entities that need more than a /32, well, they likely saw that
coming already having thousands or millions of customers and have
requested space for that, eg German and France Telecom with their /19s.

> I could ask APNIC directly, but I also know there are some peoples from
> APNIC that read this list, perhaps they are able to respond about what
> can/can't/should be done for the benefit of all in this scenario ?  Am I
> unique in my questions ? Has this come up before ?

You are not a snowflake, these situations have definitely come up.

The best example is Cloudflare which still thinks they can announce /48
out of their /32 PA. They have been told this, and their connectivity is
still broken and will keep on being broken all around the world with all
kinds of magical issues.

> Perhaps we should be just telling our customers to foot the bill and get
> their own IPv6 PI space and stay out of the middle (and just advertise
> it for them as required).

IMHO the LIR model is better, as it saves a lot of "annoying" paperwork
for the customer. Note that for a LOT of people the RIR paperwork is
just that as it can get complex as a lot of people do not know the rules
(as this thread is evident of ;)

But that is why it is good there are questions, as that way they can be
resolved.

> If this is the case though we still need to
> know this, so we can recommend to customer that this is what they should
> be doing. The only reason we'd look to do it on their behalf (option #2
> above) would be to simplify it for them.

Exactly the role of an LIR.

Note that as an LIR, you do not have to actually play transit for them.
As long as they typically have at least one, and for some RIRs two,
upstreams, they are fine with their request.

> I'm not too concerned about
> cost to the customer, if they can't manage an extra $1200 PA for IP
> address space then they probably aren't big enough to be trying to
> justify PI anyway (although if it's a cost we can help them avoid at no
> expense to us, then why wouldn't we help them).

EXACTLY the point.

Do note that anybody who is going to announce that prefix in a useful
manner also needs to have proper routing equipment to handle a full BGP
feed. The cost of that kind of equipment, the transit payments and the
engineers that do that will add up to a LOT more than $1200 PA :)

> As someone said, in terms of routing table sizes, if a /48 is going to
> be advertised it doesn't matter what space it comes from, it's still
> going to be another /48 in the table.

That is quite correct.

But the idea behind the PA and PI split is that it is and will remain
possible to filter on prefix lengths and that we do not get into the
huge swamp of uselessly de-aggregated prefixes that IPv4 has.

See:
http://www.cidr-report.org/as2.0/#Gains

NetsNow:  508066
NetsAggr: 284324
NetsGain: 223742
Gain:      44.0%

YES. 44% of the routes in IPv4 CAN be aggregated and thus should not
have to be there!

Take a small guess what happens when folks de-aggregate a /32 into
/48.... yep, we'll reach such a situation VERY quickly.

Greets,
 Jeroen