PI vs. PA, the Sequel (was [ppml] 2005-1:Business Need for PI Assignments)

[David Conrad]

Tony,

<Disclaimers>
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!
</Disclaimers>

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 
> believes
> they have all operational knowledge and that if 'we only keep doing it 
> the
> 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 
> /128's
> 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 
dictates.

> 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 
> like
> 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 
> care,
> 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 
differ.

> 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 
agree.

> 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 
> requires
> 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.

Rgds,
-drc