[arin-ppml] Q1 - ARIN address transfer policy: why the triggerdate?

michael.dillon at bt.com michael.dillon at bt.com
Mon Jun 23 10:42:27 EDT 2008

> that analogy fails since the first companies who go ipv6-only 
> will all die of starvation since "the internet" from their 
> customers' point of view will be mostly empty. 

Nobody will ever go IPv6-only for at least 10 years, and even then
those will be boutique network operators who provide some special
service rather than general Internet access or IP-VPNs.

In the time frame where IPv4 addresses will run out, we are only
talking about companies who deploy IPv6 services in addition to
their existing services. Even then, this may be an IPv6-VPN service
that does not require Internet access at all, but it still will ease
the pressure on IPv4 address consumption. And then there is NAT-PT and

> the first 
> companies to go dual-stack are doing OK, we're getting some 
> small first-mover advantage by generating skills and tools, 
> but there is no first-mover revenue advantage in dual-stack.  

This also does not protect you from IPv4 exhaustion since dual
stack implies that you give everything both IPv4 and IPv6 addresses.

> the rational individual choice for most companies has been 
> some mixture of (wait-and-see and/or hoard). 

I disagree that this is the rational choice. My view is that this
is the fool's choice. The rational move is to fully deploy IPv6
in a lab environment, roll all the support software changes required
ongoing software upgrade projects, and then move this into a small-scale
production environment with "friendly" customers, perhaps from the
government/DOD sphere. In fact, the governments (Federal, State and
should be lobbied to spread their IPv6 POs around the networking
not just give all the IPv6 business to one or two favored suppliers.

The point is that the rational choice is to spend a small amount to get
ready, and steer yourself into a position where you can at least join
the race when the starting pistol is fired. You don't have to be an
athlete to win such a race, you just have to be able to run faster than
of the competition. No doubt people will run into scaling issues, but if
have people experienced with running IPv6 in a test lab environment, you
a chance of solving the scaling issues.

> 	$ dig +short bt.com in mx
> 	10 smtp62.intersmtp.com.
> 	$ dig +short smtp62.intersmtp.com. in aaaa

You DNS gurus do love to post the output of "dig" but
this is meaningless to me. I think it might be saying that we
outsource our corporate email service but I'm not sure. In any
case it says nothing about what we are doing with IPv6. Also,
we have a global MPLS network on which we sell VPNs, and do some
variuous pseudo-wire stuff. It's pretty easy for companies with
such a network, and there are many of them, to do IPv6 VPNs for
customers who don't expect Internet access to the VPN. MPLS is 
basically an automated tunnel overlay system, so the pure-IP 
equivalent of this is the operator who builds an IPv6 overlay
network with GRE tunnels. I think that this is the better way
to ease into IPv6, and then add the Internet access gateways 
later on.

> the rational choice for many is: waiting until there are 
> other ipv6 endpoints to connect to before adopting 
> dual-stack.  this isn't psychology, but rather "just 
> business" as randy bush sometimes says.

Sounds like magnetic monopoles to me. Why not find an organization
with several endpoints in different locations and connect them all
up? In any case, companies with blinders on will suffer, one way or

> isc.org's network has been dual-stack for years.  what's 
> bt.com's plan?

BT's plan is as complex as the dozen or so IP networks that we operate.
A lot of network operators are in the same boat, still running 3 or 5 or

10 IP networks that result from various M&A activity and/or attempts to
integrate some networks into a merged network. Fact is that there are
customers on these networks so we like to go slow and make sure the
keeps running. That is why you hear so little about IPv6 from the bigger
networks, because they are easing into it in a way that does not disrupt
any existing customers.

--Michael Dillon

More information about the ARIN-PPML mailing list