PI vs. PA, the Sequel (was [ppml] 2005-1:Business Need for PI Assignments)
david.conrad at nominum.com
Fri Apr 29 18:56:39 EDT 2005
I am speaking only for myself. I most assuredly not representing
Nominum or anyone else. Use at your own risk. Void where prohibited.
Use protective eye wear. Do not eat. May cause cancer in rats. Do
not use near open flame. I didn't do it!
On Apr 27, 2005, at 2:43 PM, Tony Hain wrote:
>> More than a few times the IETF has come out with something saying
>> "it will never work if you don't do it this way". The operators
>> then point to it up and running on the live network, shrug, and the
>> IETF runs back to figure out why the operators don't believe them.
> The major problem is that the current crop of operators generally
> they have all operational knowledge and that if 'we only keep doing it
> way we already know' thing will work fine.
I suspect this sort of dialog isn't particularly productive.
> Yes, but the IETF was looking at the operators that were insisting on
> per customer and noting that this would lead to another NAT disaster.
Ignoring value judgments on tools, the fact that IPv6 uses the same
routing technology as IPv4 means, at least to me, that the address
allocation models should be similar. As we (Internet users in general)
have learned, sometimes painfully, that having fixed values can bite
you in the butt, it seems prudent to pro-actively apply some amount of
bug repellant. All we are arguing about is how much.
> That is just wrong. The existing system was developed to the
> requirements of
> the providers
In as much as the providers were interested in keeping their routers
from falling over, I guess you could say this. However, non-providers
were intimately involved in many of the discussions that resulted in
RFC 2050 so characterizing the existing system as you have is
incorrect. An attempt was made to document existing allocation
practice to take into account the requirements of both end users and
providers. The fact that IPv4 allocation policy can be viewed as
skewed toward providers is likely due to the fact that emphasis was
placed on not overloading the routing system as that was seen as in the
best interests of the most entities.
> and through RIR allocation policies continues to be driven by
> the providers.
Just to be clear, RIR policies are defined via a documented (and
followed) open policy process. Anyone, provider or not, can submit
policy proposals and be involved in discussions to drive a particular
policy or derail it as your conscience and/or technical understanding
> The IETF said there is no technical justification for longer
> than a /48,
And 640K will always be enough. As will 32 bits. I have a bit of
difficulty with assertions such as these as history is littered with
cases where the presumed near-limitless turned out to be quite
limiting. 48 is, as far as I know, an arbitrary number with a few
pleasing binary properties. Why not 50? Why not 46? Why not 32? It
has even more pleasing binary properties. The point is, the fact that
the number is arbitrary and has changed over time does not give me warm
fuzzies that it is the One True Limit on how long a prefix needs to be.
> and that the issue about switching providers is something that
> is important yet the ISPs consider that less desirable because they
> provider locking.
I'm not sure I follow how allocating longer prefixes would enable
provider locking if everyone is following the same allocation policy.
Lock-in and lock-in avoidance techniques such as NAT occur because
people have to renumber if they change providers.
> The point is we
> don't know what might be possible because everything to date has had a
> limited number of bits to work with for identifying hosts on a segment.
IPv6 still provides a limited number of bits. Many more, but still a
limited number. I agree that we don't know what might be possible,
however I believe one of the arguments is that because we don't know,
we should be somewhat conservative in allocations. Particularly given
IPv6 is using the same routing technology as has resulted in unpleasant
surprises regarding scalability.
> The last IPv4 address will never be issued because either nobody will
> or nobody will be able to afford it.
As an aside, while I agree that the last IPv4 address won't be
allocated, I suspect that will be because a market will establish
itself for IPv4 addresses and people with vast tracts of address space
will find that maybe NAT isn't so bad after all, particularly when they
can sell the addresses they aren't using.
> Given that we are arguing about the
> lifetime of 1/8th of IPv6 being 50 or 100 years,
Err, no. The estimates Geoff came up with were for all 48 bits. When
we said a /1 to a /4, we were talking about one half to one sixteenth
of all the address space, not just the 1/8th in use now.
> Political edicts mean traditional IP topologies are irrelevant.
Very true. I personally do not think the alternative topologies
preferred by the PTT/ITU community are desirable. Obviously others
> This is not an IETF driven thing.
Not driven perhaps, but the IETF has made the highway. In IPv4
aggregation is the one way we know how to scale networked systems.
Provider-based aggregation is the approach that has evolved to be
economically viable. Since the IETF chose a protocol that was a
simplification and minor (well, except for bits) extension of IPv4, in
particularly continuing to use the existing routing technologies
without specifying the promised renumbering technology to remove the
most significant downsides, it can be argued that the IETF has set the
stage for political edicts.
> Governments have the ability to change the economics if they choose
> to. So
> far the Internet has been left to run free reign, but the economic
> powers in
> the traditional telecom world are putting pressure on their
> governments to
> fix that problem.
I agree. I also believe one sure way to get governments involved is to
create an environment where there is a perceived risk that a country
won't be able to get the IPv6 addresses they need. Another is to give
the impression of egregiously mismanaging a critical resource. I
suspect if you asked someone on the street if they thought reducing
340282366920938463463374607431768211456 possible items to
281474976710656 items was egregious mismanagement, they'd probably
> The IETF is not trying to solve the problem, the RIR's are. The
> proposal at
> the recent ARIN meeting was to use possession of an AS number as the
> technical metric for a routing slot. Unfortunately that metric only
> that you have connections to more than one provider. There is a vast
> difference between number of connections and need for a routing slot.
I believe the intent of AS based proposals is that generally, an AS
signifies (or is supposed to signify) a network topologically
significant set of prefixes as opposed to leaf nodes. As I'm sure you
know, topologically significant sets of networks can have different
routing policies than their parents/peers so they require a routing
slot to be used optimally. On the other hand, a leaf node must have
the same (or a subset of the) routing policy as their parent, thus
their routing announcement can be subsumed by their parent. As such,
using an AS as an indicator of the need for a provider independent
prefix would seem to make sense.
You can argue that everyone needs a provider independent prefix, but if
you do, it would probably be helpful to describe in technical detail
how the routing system with such an allocation policy can be made to
scale. Since we know the current approach works and given the
importance of keeping the system working, I believe the burden is on
those who would propose to change the system to demonstrate
convincingly that the new system would work.
In any event, I suspect it would be appreciated by most if we could
ratchet down the assumption of evil intent or stupidity on the part of
one ambiguous group or another.
More information about the ARIN-PPML