[arin-ppml] Advisory Council seeks additional commentary on PP-158

[Owen DeLong]

On Nov 12, 2011, at 1:21 PM, William Herrin wrote:

> On Sat, Nov 12, 2011 at 12:50 PM, Owen DeLong <owen at delong.com> wrote:
>> On Nov 11, 2011, at 9:01 PM, William Herrin wrote:
>>> Are there any parameters for this game in which the registrant
>>> acquires more IP addresses via the 10 distinct blocks? How much more?
>> 
>> In general, the initial assignment will not be where this policy makes a
>> significant difference, but, instead, when the applicant runs out of space
>> in region G while A, B, C, D, E, F, H, I, and J still have space available.
>> 
>> In the non-discrete case, the applicant would be expected to move space
>> from one of the other regions into G to accommodate the need. In the
>> discrete case, the applicant is able to apply for an additional prefix for
>> region G separate from his utilization in the other regions.
> 
> Okay, let me tweak the parameters a little and present a scenario:
> 
> 1. Registrant creates 8 discrete networks each of which just barely
> qualifies for a /24. If ARIN did not treat them as discrete networks,
> they would collectively qualify for a single /21.
> 
> 2. Network A grows quickly while the other 7 stagnate. It now
> qualifies for an additional /23. Had ARIN allocated the /21, the
> registrant would have had sufficient addresses left in the /21 to
> satisfy the demand.
> 
> Is that about the size of it? Or am I underselling the downside risk?
> 

That's one possibility. However, note, if the 8 discrete networks are
discrete (as in can't share a routing policy), then, network A needs
additional space as moving space from one or more of the others
to A is not practical. (The smaller block(s) shifted to A wouldn't make
it into the global routing tables most likely.)

> Also, correct me if I'm wrong but the finding of sufficient addresses
> left in the /21 is actually in error, isn't it? Because of the /24
> backbone boundary, network A would need some pretty wacky routing to
> get that to work, would it not?  But that's *only* true if the network
> is Internet-connected. For a DN connected only to other private
> networks there would be no difference.
> 
If they all share a common routing policy (e.g. advertise the /21 externally
and not necessarily the more specifics), then, no, it's not in error. The
whacky prefixes would be strictly IGP and wouldn't impact any exterior
routing.

Hence the definition of discrete networks hinging (IMHO) on the need (or
lack thereof) for distinct routing policies.

> 
> 
>>> Are there any parameters where more routes must be announced due to 10
>>> distinct blocks? Remember, genuine distinct networks here, the
>>> separation can be needless but there is no overt fraud. What about
>>> parameters which leave no choice but for the single aggregate approach
>>> to introduce more routes?
>> 
>> If the networks have separate routing policies, it will require a minimum of
>> 10 announcements anyway. If they are not discrete from a routing policy
>> perspective, then, one announcement is possible. In the case where the
>> routing policies are distinct, expansion in on network will require additional
>> announcement(s) from that network specifically. In the case where the
>> routing policies are not distinct, the additional space could be aggregated
>> across the networks, at least theoretically.
> 
> To me, that sort of implies that rather than asking ARIN to find a
> compelling need, we should ask ARIN to confirm that the networks are
> in fact discrete in that they do not share a common Internet backbone
> access facility. In effect, the fact that the registrant found it
> needful to physically connect the networks to the Internet with a
> different set of lines *is* the compelling reason.
> 

This really depends on how you define "common internet backbone
access facility".

For example, 8 sites each of which has it's own uplink to an ISP and
no two of which share ISPs, but, which have an internal backbone
meshing the 8 sites such that any site can easily accept more than
its share of global traffic (e.g. they can advertise the /21 due to their
interior backbone capabilities) would not be discrete.

However, one could argue that they "are discrete" in fact because
they don't share a common upstream provider or a common backbone
access facility as you describe it.

> Here's a potential abuse scenario:
> 
> Registrant creates 8 distinct networks, all at the same building or
> campus. Gets addresses from ARIN. Drops 7 of the networks' Internet
> connections and sets up one of the 8 as an administratively distinct
> "ISP" for the other 7.
> 
> How does/should the policy deal with that?
> 


Frankly, this sets off my "extreme corner case" detector, but, I'll play
along...

This particular policy wouldn't deal with it until the applicant came for
more addresses. It would also depend on what is meant by your
term administratively distinct. For example, if it were spun off
into a separate organization or other wise transferred to a different
organization through a section 8 process, then, the remaining 7
would likely still qualify as discrete networks.

In the case where they remain part of the original ORG, the
alleged administrative distinction is not relevant to ARIN and
they would still be a single org. Since they now share a common
routing policy (everything through the one network) as far as the
outside world is concerned, I would say they are no longer
discrete networks in the meaning of the policy.

Whether or not this is the ideal ARIN response is an open question
and I"m frankly not sure I have an opinion. It's such an extreme
corner case that I can only see it coming up one of two ways:

1.	Someone is so determined to game the system that they will
	likely find a way no matter what policy we write. Clearly they
	are at least willing to walk right up to the boundary of fraud
	if not actually step over the boundary as to make the distinction
	largely academic.

or

2.	It really is a very bizarre scenario in that particular network
	in which case it would occur so infrequently as to be irrelevant
	in evaluating policy efficacy.

I would argue that the number of organizations willing to play that
close to the edge of address fraud is actually small enough as to
still render version 1 an irrelevant corner case as well.

Owen