So to start off, I'm new to following this list so if these points have
already been beaten into the ground, feel free to tell me to shut up.
So two things I wonder about the preservation of current IP4 space and
delaying IP6 are:
1. Why don't providers use /31 addresses for P2P links? This
works fine per rfc 3021 but nobody seems to believe it or use it. Are
there any major manufacturers out there that do not support it?
2. Longer than /24 prefixes in global BGP table. The most obvious
answer is that some hardware may not handle it... How is that hardware
going to handle an IP6 table then? I have had several occasions where
functionally I needed to advertise for different sites but only needed
20-30 addresses which is a complete waste of a /24. How hard would it
be to start allowing /25s when compared to trying to roll out IP6?
The intention of this isn't to start a "what's good or bad about IP6 and
what still doesn't work" debate.. I'm just generally curious about how
these two seem like easy ways to make more efficient use of what we have
already.
Thomas Magill
Network Engineer
Office: (858) 909-3777
Cell: (858) 869-9685
mailto:tmagill@providecommerce.com
provide-commerce
4840 Eastgate Mall
San Diego, CA 92121
ProFlowers <http://www.proflowers.com/> | redENVELOPE
<http://www.redenvelope.com/> | Cherry Moon Farms
<http://www.cherrymoonfarms.com/> | Shari's Berries
<http://www.berries.com/>
Some vendors inconsistently support these on ethernet-framed interfaces and randomly break their code [again].
The one I am aware of is located on Tasman, and YMMV varies depending on what line of business synced code from whom and when.
Nothing like upgrading a minor patch revision of software and losing your infrastructure link....
- Jared
I posed this to the list in January, and learned that apparently there
are still some vendors whose products choke with presented with a /31.
Search for thread "Using /31 for router links".
~Seth
1. Why don't providers use /31 addresses for P2P links? This
works fine per rfc 3021 but nobody seems to believe it or use it. Are
there any major manufacturers out there that do not support it?
99.999% of my customers are on /32 anyway. I could probably get a handfull of addresses (/25) back by renumbering the backbone links . But this will not save the world and they will most likely be used more rapidly as I can reclaim them.
MarcoH
prefix deaggregatation beyond /24 is probably inevitable but that
doesn't mean you want people to burn routing table slots on your
equipment for /28s. That routing table slot is an externality that
everyone has to pay for. By holding the line to the extent that it is
held, a cap of the growth rate of your dfz fib that is roughly congruent
with rir policy.
handling the v6 table is not currently hard (~2600 prefixes) while long
term the temptation to do TE is roughly that same in v6 as in v4, the
prospect of having a bunch of non-aggregatable direct assignments should
be much lower...
1. Why don't providers use /31 addresses for P2P links? This
works fine per rfc 3021 but nobody seems to believe it or use it. Are
there any major manufacturers out there that do not support it?
Because those who want to hyper-optimize use a /32 loopback address on
each router instead and rely on SNMP instead of Ping to determine
whether an interface is up.
2. Longer than /24 prefixes in global BGP table. The most obvious
answer is that some hardware may not handle it...
That's the most obvious answer?
I think these qualify to be in an IPv6 FAQ if they're not already 
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony@lava.net
I would suggest that the ratio of folks that will multihome under IPv6 versus those that won't will get smaller. I base that on an assumption that NAT (as we know it today) will be less prevalent as IPv6 usage grows.
Folks, I know that IPv4 is down to bread crumbs.
That's why I'm ready for IPv6 and hopefully the rest of you are or will be soon.
However, let's consider how much address space is saved by going from /30 to /31
on every point-to-point link in the internet...
Let's assume that there are ~1 million routers on the internet with an average of 8
point to point interfaces. (I think there are probably more like 1/4 million and the
average is probably more like 2, but, absent real numbers, I'll be uber-conservative).
8 million /30s is 32 million IPs, or, 2 /8s world-wide.
8 million /31s is 16 million IPs, or, 1 /8 world-wide.
We burn roughly 14 /8s per year in new allocations and assignments.
So, assuming:
1. There are actually 8 million point to point links in the internet
2. All of them are currently /30s
3. Absolutely optimum use of addresses for all those links
4. All of them are converted to /31s
(none of these assumptions is likely in fact)
The most we could achieve would be to extend IPv4 freepool lifespan
by roughly 26 days. Given the amount of effort sqeezing useful
addresses out of such a conversion would require, I proffer that
such effort is better spent moving towards IPv6 dual stack on your
networks.
Owen
... and, unstated behind that, is the observation that pretty much any
proposed effort to squeeze more time out of IPv4 will inevitably have
the same answer
- mark
In particular, if your site has 256 PTP links, you can convert from /30s to /
31s, save 128 IPs, but then trying to *actually use them* effectively outside
your AS ends up sounding like this:
"Eat your Brussel sprouts. Don't you know there's kids starving in Africa"
"OK, you can send my sprouts to them..."
The most we could achieve would be to extend IPv4 freepool lifespan
by roughly 26 days. Given the amount of effort sqeezing useful
addresses out of such a conversion would require, I proffer that
such effort is better spent moving towards IPv6 dual stack on your
networks.
A /8 sounded like a decent amount until you put it that way. Nice
empirical data, even though its based completely on assumptions. But if
it is even in the ballpark.. It is pretty obvious it isn't worth the
effort. I just didn't have even have a guess at the number /30s out
there.
I've been on board with rolling out IP6 but the SPs I've talked to are
all '...about to start trying to possibly think about extending a beta
to a small portion of some customers' or something along those lines.
This led me to believe that SPs are way behind on this considering the
expected exhaustion of IP4 space.
Also, and not sure how to phrase this, but is there any
behind-the-scenes push to start moving closed systems that run over the
Internet to IP6 with the goal of freeing up any of the IP4 space for
more public-facing systems and end-users? Is the thought of anyone
giving up IP4 space after they have moved to IP6 just a silly notion? I
could see a future where infrastructure services like voice run on IP6
while common 'web services' stay on IP4.
Once again, sorry if I'm bringing up anything that has been beaten to
death. I just come from the corporate side of this and the SP side is
just a point of interest for me so I like to hear that point of view.
Owen, thanks for this picturesque description. Whoever recommended the
FAQ, add this equation into it.
I *wholeheartedly* agree with Owen's assessment. Even spending time
trying to calculate a rebuttal to his numbers is better spent moving
toward dual-stack 
Nice.
Steve
ps. and I'm just tiny. I just enjoy seeing reports of the big boys
moving forward, and watching my v6 routing table grow...
heh.
Stan, you've got things backwards, no matter which direction you are
looking at things from. I'm thinking that you may have written the
sentence incorrectly.
It's unfortunate, but it is reality.
Have you reviewed your RIR policy lately? v6 will be flying out the
window soon, and your local RIR may be assigning PI space like candy.
Welcome IPv6.
Steve
fwiw, it didn't appear clear to me that my own comments reflected my
feelings that the migration was a good thing
STeve
When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort.
Extrapolations of current IPv4 address space consumption become precisely useless when the existing policy regimes no longer apply.
This is not to say folks shouldn't be aggressively pursuing IPv6 deployment, merely that there is a vast installed base that will continue to require IPv4 addresses even after the RIRs allocate the last block they control.
Regards,
-drc
Only to the extent that the cost of IPv6 migration exceeds the cost
of recovering space.
There's sure to be an upper-bound on the cost of v4 space, limited by the
magnitude of effort required to do whatever you want to do without v4.
- mark
yea, it doesn't seem to follow based on what I'd seen at a large
network provider, more people multihome over time, for reasons related
to business continuity...
(the comments about multihoming and nat just seem sideways, as well)
-chris