AddOn --- Re: [address-policy-wg] Re: Re: a consensus, about what?

Marcus Gerdon wrote:
> A thought just crossed my mind:
> 
> those of you striving to deny slots in the routing tables to non-LIRs, what
> do you think about splitting a PA and announcing parts out of different
> AS'es ? This isn't really a de-aggregate, serves the 'address conservation'
> constraint but is utilizing routing table space. Wasn't the 'sub-allocation'
> type intended for this and must have had some consensus to become
> implemented ?

See my message about "De-aggregation of assigned IPv6 prefixes?" and
Gert's response on it.

ISP's are already doing this in IPv6. The only thing to 'stop' it is to
have "most" ISP's filter those announcements. But even if you filter
then the prefix is still reachable through the aggregate, thus
connectivity isn't lost.

> Maybe there should be added a PA allocation rule that each PA has to be
> announced only out of one AS.

This rule can be configured on your the router(s) in your network.
It's called filters and that is up to you to configure or not.

> No ? We can't do this ? Why not ? Be splitting PA's this way the LIR create
> a address space type that can be moved along very similar to PI, just
> without being handed out directly to the customer.

Cool huh :)

> Would be an idea:
> I split one of our PA into /24's and lend them to enterprise customers free
> for announcement via their favourite ISP charging a yearly fee (obvisously
> the fee only for administering the RIPE data, as charging for addresses
> isn't allowed.).

You have a mostly valid business case here (IANAManager/Banker :)

Instead of an end-site going to the RIRs for IP space, let them come to
you, you being LIR. You as a LIR give them a /48 (or more) and say they
can use their own ASN to announce it to their peers and transits. As
long as those parties accept it they are fine. This also means you will
have a plan for 200 potential customers :) The first side-effect is that
your customers are (partially) dependent of you, you as LIR disappears,
then they don't have squat. Then again if RIPE disappears, what then? :)
Also they depend on you to carry the PA of their prefix in case their PI
breaks, but they can see that as 'extra service. When their /48 gets
filtered with normal PI they would not have anything at all, now their
packets can still be delivered. Note also that there is no need for
requirement that you as a LIR actually carry packets for them as long as
their route is available. Good thing: LIR costs/members = low costs :)

WARNING: Also note that there are a number of places where there is
quite some strict filtering happening. This might result that your small
/48 gets filtered out by fast/good "transits", but accepted by slow/bad
"transits", thus causing you to be pretty unreachable over those ASN's.
This has already been seen a couple of times in IPv6 routing tables!

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/address-policy-wg/attachments/20051207/1027b0ee/attachment.sig>