[ppml] Suggestion for ARIN to deligate smaller IP blocks

[John Santos]

On Fri, 8 Jun 2007 Paul_Vixie at isc.org wrote:

> > > > The magic words, "private network", appeared in the next paragraph
> > > > you snipped, don't remember if I made it clear I was talking about
> > > > private internets, not intranets.
> > > 
> > > what's a "private" internet?
> > 
> > I mean an internet (a network of networks) between different
> > organizations, but not (directly) accessible to the Internet.
> 
> that's far from definitive.  first off, by "the Internet" you seem to mean
> what some people call the default free zone (DFZ) but you might be using
> breidbart's definition, which i've quoted a time or two here recently but
> here it is again:
> 
> 	>> But what *IS* the internet?
> 	> It's the largest equivalence class in the reflexive transitive
> 	> symmetric closure of the relationship "can be reached by an IP
> 	> packet from".		--Seth Breidbart
> 

Actually, that was what I was trying to summarize in smaller words,
but which definition gets used is unimportant.

> second and more importantly, if i'm a member of more than one of these
> "private internets," say one between "different organzations" A,B,C,D and
> one between "different organizations" D,E,F,G where i am "D", what am i?

Then you're like me :-)  I'm not sure what that makes you, but whatever
it is, I'm sure you would like to have a set of IP addresses don't don't
collide with any of A, B, C, E, F or G.

> 
> third and finally, if the rest of the world nukes itself in spam and ddos
> and "different organizations" A,B,C,D,E,F,G decide to form their own
> "the internet", or are the last networks standing after the spamocaust
> such that we qualify under breidbart's definition, then what am i?
> 
> > Much has been made of the definition of "the Internet" as the largest
> > set of host defined by the relation "reachable by each other" (as I
> > understand  it) in some recent posts.  There are many other internets,
> > networks encompassing cooperating entities, which contain hosts that
> > are not reachable from the Internet at large but are reachable by each
> > other, and which have some hosts that are part of "the Internet."
> 
> i agree that any network of networks is "an internet".  it remains to be
> seen whether your use of the term "the internet" reaches the same concept
> in my head as it does in yours.  word definitions may not matter if we
> simply avoid disputes and ambiguity.
> 
> a network is "private" if it's not connected to most other networks, but
> clearly it could still be connected to some other networks and still be
> "private".  while the U in ULA ("unique") is clearly beneficial since a
> network might be less private at some parts of its life cycle than at
> others, and collisions are painful, the L in ULA ("local") is unclearly
> unbeneficial since during the times in its life cycle when a network is
> less private, it might be painful to have someone refuse a third party
> route on the basis of its policywise L-ness.
> 
> > They need non-colliding addresses.
> 
> all RIR allocations (PI or PA) are non-colliding ("unique"), so this part
> is already handled.
> 

Yes, but if my network is too small to qualify for a PI or PA under current
policy???

> > RFC1918 might work fine, if a single person or group were managing address
> > assignments (and the private internet were small enough), but I'm talking
> > about intERnets, not intRAnets, that is, these networks belong to and are
> > managed by different people, groups, companies, or organizations, so RFC1918
> > addresses are very likely to collide.
> 
> i'm not proposing that you use RFC1918 or IPV6 "site local" for this kind
> of network.
> 
> > Assigning unique addresses to all the involved organizations would prevent
> > the collisions.
> 
> agreed.  for example, PI or PA.
> 
> > I realize that given the pending crunch in ipv4 addresses, it may not be
> > possible/practical to assign even /24's to all organizations who might need
> > them, but there is *no excuse* for not allowing for this in ipv6.
> 
> also agreed.
> 
> > Whether it is ULA-C or PI is immaterial.
> 
> here, i disagree.  ULA would be a waste of address space, and administrative
> effort.  there's more space available for PA and PI than will ever fit in the
> DFZ.  your argument supports a policy for smaller-size PI allocations which
> may be cheaper and may be easier to qualify for and may be allocated out of
> a well known /10 to make them safe from static TE-resistant route filters,
> but no argument i've seen here supports a policy for "unique local addresses".

Well, I agree with that, but that wasn't my point.  My point was I need
(in the sense of "would really really really like to have") unique addresses,
and whether they are ULA-C or PI or whatever doesn't matter to *me*.  If
one of these solutions is better than the others from someone else's 
standpoint, then that's fine with me, as long as I get my unique addresses.



Here is my wish-list of what I want/need out of an address policy
for ipv6:

1) Globally unique addresses
2) Relatively small number of them
   (for ipv4, a /24 is plenty.  I don't know for ipv6; I haven't messed
   around with it yet, one of the obstacles is knowing what addresses to
   use. :-)
3) Relatively cheap
4) Permanent
5) Low-maintenance
   (I would be making few if any changes, seldom if ever requesting
   more space, etc., so registry overhead should be very low.)
6) Global routing is not needed.
   (I would be using these addresses locally or over private networks
   where the manual one-time effort of setting up routes, firewall
   filters, etc. would be fine.)

I think lots (how many is "lots", I have no idea, but there have been
others posting here who seem to be in the same situation) of other
people/organizations are in the same situation.  And lots more would
differ only on point 6, i.e. other people would like or require global
routing.  Indeed it would be nice to have but for me isn't essential.
Maybe someday, someone will solve the routing table scaling problem,
and it will become a non-issue.

The way I see it, ULA-C has been proposed as a solution to most of
these items.  To summarize the arguments for and against it,

F1) It would be cheaper/easier to administer than PI.
(Some dispute this, saying it would be just as much work for ARIN.)

F2) It would be easy to filter at the edge routers, since it would
all be in a single address block.  (But you would have to be able
to turn this off if you wanted to use said router within a ULA-C
network instead of at the edge of one.)

F3) It could be distributed in smaller chunks than PI.  (But PI
could also be distributed in smaller chunks, too.  This is just a
matter of Policy.  But then backbone people don't want to route the
smaller chunks since too many of them would swamp their routers' 
routing tables, but then again, there is no intention of globally
routing ULA-C packets, so the addresses shouldn't end up in the
routing tables in the first place.)

The arguments against seem to be:

A1) It doesn't do anything PI doesn't already do.
   (See arguments for...)

A2) Someday you might want to route the ULA-C addresses, so you'll
   either have to renumber to PI or convince the world to disable
   the ULA-C filters mentioned in argument F2.  Might just as well
   start with PI and avoid all this.

Did I miss anything?

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539