[deepspace] Re: Understanding the difference in aggregation between a single and multiple RIR model

[Jen Linkova <[e-mail]>]

On Tue, Sep 1, 2026 at 8:32 AM Tony Li <[e-mail]> wrote:

> >>> 'BYOIP' model explicitly prohibited by the architecture?
> >>
> >>
> >> If we want efficient addressing, it needs to be.
> >
> > I have some reservations about how realistic this goal is.
> > Nobody likes large routing tables. However PI addresses, and more
> > specific routes from Provider-aggregatable blocks existing in the full
> > view for a reason: business cases.
>
>
> Just because you have a business case for something doesn’t mean that the rest of us have to pay for it.
> And that’s exactly what happens right now.  [I object more the more-specifics than I do PI space.]

There is always an option of not accepting more specifics from PAs, right?

> > If Foo would like to use some prefixes not belonging to this colony,
> > and is willing to pay for it, do we think the connectivity provider
> > would refuse that deal because the IETF says they should?
>
>
> Who exactly are they paying?  Today, the rest of the transit community pays and there is zero compensation.  Pure tragedy of the commons.

They are paying their service provider, I guess.

> > Also, there is a technical point I'd like to make. When we are
> > optimizing for one thing, we often sacrifice others.
> > You can optimize your address plan for routing (minimizing # of
> > prefixes in the routing table), but it often impacts security policies
> > (such as inflated ACLs etc).
>
>
> If you are writing ACLs based on source addresses, then I will point out that source addresses are trivially forged.

Within the given network they are not.
Company Foo should have BCP38 policies on their edge, preventing their
sources to come from the outside.
Then they might want to only allow some internal services to be
accessible by espresso machines (2001:db8:cafe::/48) but not their
vacuum cleaning robots (2001:db8:b00::/48).

Anyway, I'm afraid this discussion is going in the wrong direction.
IETF documents have a section for the IANA Considerations.
We do not have RIR or LIR considerations and we can not regulate their policies.
As it's been pointed out already, address policies of RIRs are
developed by the RIR community, not the IETF (we have tried - see
RFC6177 - and some operators ignore us).

We should document that we'd like IANA to allocate a block f00::/X and
allocate N subnets for the predefined set of bodies, with some
expectations of what might be needed in the future.

Everything beyond (IANA <> RIR, RIR <> LIR) should be decided in
another venue(s).

-- 
Cheers, Jen Linkova