[ppml] Draft ARIN Recomendation on draft-ietf-ipv6-ula-centra l-00.txt, take 2

[Leo Bicknell]

In a message written on Tue, Nov 09, 2004 at 09:24:10AM -0800, Azinger, Marla wrote:
> Leo-  since you have clearly read this proposal in detail.  Can you please
> clarify your interpretations on the following:

I will do my best.

> You wrote:  "The proposal is likely to create confusion in the ARIN region
> about which prefixes can be routed on the Public Internet."
> 
> 1. Can you clarify what specifically could be confusing?

The barrier to a prefix being on the Public Internet is the filtering
practices of ISP's.  When you look at the filtering practices of
ISP's, you see a set of concerns.  For an individual ISP, I believe in
priority order they are:

   1) Is the request technically feesable?  That is, can I do it and
      not break my own network, my other customer's networks, and my
      peers networks.

   2) Is the request economically feesable?  That is, even if I can do
      it, can I do it in a way that will scale.

   3) What does the community think about my practice?

With this proposal (ula, central registration of prefixes), I believe
the answers most people would come up with are:

   1) Yes.  From a technical perspective they are guaranteed to be
      globally unique.  This should never break my own network or 
      anyone elses.  Indeed, this is the very point.  Those who need
      a portion of this address space can use it without conflict,
      and interconnect with each other without conflict.

   2) Probably.  For all of my customers with their own space today I
      carry at least one, if not 5, 10, or even 100 routes in IPv4.
      If I carry 1 IPv6 route, be it from ARIN or from the central
      registry that's probably no more of a burden on my devices or
      staff, and thus no more cost.

   3) Well, some IETF drafts say it's a "bad idea".  My peers, well,
      I'm not sure yet.

It's also interesting to look at a picture:

Customer 4--link 6--ISP1----link 1----ISP2--link 5--Customer 3
                     |                  |
                   link 2            link 3
                     |                  |
                Customer 1--link 4--Customer 2

These prefixes are specifically allowed for link 4, that's their whole
purpose.  I think it's easy to extend that, via VPN services or via
direct announcement to include link's 3 and link 5 (same ISP, they
can do what they want internally) and similarly link 6 and link 2.

So the only link these are rigidly supposed to be filtered on is
link 1.  Confusing?  I think so.  What happens when two ISP's open
up the filter on link 1 to allow cross selling (think cross provider
MPLS VPN's today).  So now, I can use these addresses between Sprint
and UUNet, but not Level 3.  I can use them on my private, talk to
100 other companies network, but not on the public internet.

I think it will be very confusing to many smaller network
administrators.  Today it's easy to cut off any 1918 confusion.
"Everyone gets the same block, if we routed it there would be
a collision, so we can't route it."  This eliminates the possibility
of collision, and thus the strongest argument against routing the
space.

> You Wrote:  "If the prefixes in the proposal become globally routed by major
> Public Internet ISP's it has the potential to impact ARIN's viability."
> 
> 2.  How do you see this will impact ARIN's viability?

This is a chained result.  If you believe the worst case of what I wrote
before, that these prefixes /are/ globally routed on the public internet
then you have an interesting situation.  A party can get IP's from ARIN,
complete with doing justification and paying yearly fees, or it can get
them for free from a web site with no justification.

I suspect almost everyone will go for the free, no paperwork option.  If
that's true, ARIN has no income from IPv6 addresses.  Of course ARIN
wouldn't be allocating any anyway, so perhaps ARIN would simply no
longer be needed (for that function).

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20041109/9bc0f50b/attachment.sig>