[ppml] Effects of explosive routing table growth on ISP behavior

[Thomas Narten]

"Brian Johnson" <bjohnson at drtel.com> writes:

> > If by "require" you mean "enforce", then you're probably right.
> > However, if by "require" you mean "state what should happen" there is
> > precedent: the IPv6 guidelines say you have to announce your
> allocation
> > as a single netblock.
> > 

> Question: Does it say you cannot advertise smaller portions as well as
> the larger block?

The policy text does not. As one of the authors of the original text
(as adopted by APNIC/ARIN/RIPE), there was no intention to disallow
advertising of longer prefixes. Indeed, that is not something that RIR
policy would normally get involved in. The intention was, to be clear,
to ensure that a single aggregate _could_ be advertised, and it would
provide reachability for all the covered addresses. In some sense,
this goes hand-in-hand with the definition of being an ISP. You are
handing  out address space plus providing connectivity for that space.

"Stephen Sprunk" <stephen at sprunk.org> writes:

> Also, I do have some tolerance for deaggregates, as long as the covering 
> aggregate is provided.  How much that tolerance is (i.e. the value of N) 
> will depend on how close my routers are to falling over this week.  In fact, 
> N may even be a function of how many AS hops they are from me: deaggregates 
> from India or somewhere else 5+ hops away don't particularly interest me, 
> but ones from here in the US/Canada may.  In fact, if someone were assigned 
> a /24 here, I might want their /27s; I don't want /24s (or even /14s) from 
> someone further away with a /10 -- as long as that /10 makes it to
> me.

The above is why the aggregate must be advertised. That way, if
deaggregates are also advertised, anyone can freely filter them, with
the result being reduced performance, but not broken connectivity.

It is important that RIR policy preserve aggregation to the maximum
degree possible, so that if/when increasing use of filters kicks in,
global connectivity can be maintained.

Jon Lewis <jlewis at lewis.org> writes:

> [from the v6 ISP template]
> 14. Will you announce only the single, aggregated IPv6 prefix you
>      are allocated by ARIN? Indicate YES or NO.
> ...
> 14. Specify YES or NO. If you receive an allocation from ARIN
>      and you will only announce the least specific, aggregated
>      prefix to your BGP neighbors, indicate YES. If you plan to
>      announce more specifics of your allocation to your BGP
>      neighbors, indicate NO.

IMO, this is an incorrect application of what the policy calls for.

Member Services <info at arin.net> writes:

> Hello Scott-

> As you indicate above, NRPM 6.5.1.1(3) states that an organization "must 
> plan to provide IPv6 connectivity to organizations to which it will 
> assign IPv6 address space, by advertising that connectivity  through its 
> single aggregated address allocation".

> If a requester answers YES to question 14, then this clearly meets the 
> policy.  A NO answer to this question would not be an immediate denial, 
> but instead would lead staff to ask for clarification as to whether the 
> organization intended to announce the single, aggregated prefix at all. 
> The policy doesn't specifically preclude an organization from announcing 
> more specifics of the larger prefix.

> Because this question seems to be somewhat confusing,  ARIN staff will 
> update the template today to clarify this question and the
> instructions.

Thanks! I think this is a good example of where subtle nuances in the
wording can have a much bigger impact than intended.

Glad to see this get clarified.

Thomas