Short version: Responding to Tom Vest's concern about how the
constraints on widespread adoption of a scalable
routing solution seem to preclude widespread
adoption of IPv6.
Hi Tom,
Regarding my suggested text:
http://www.ietf.org/mail-archive/web/rrg/current/msg04815.html
you wrote:
> FWIW I like what's here. However, if we subsequently find ourselves in a
> world where IPv6 remains undeployed, and (possession of) IPv4 continues
> to represent a critical bottleneck to nontrivial participation in the
> routing system, then most/all of the maxims below would seem to be
> largely or exclusively relevant to "incumbent" IPv4 holders.
I tried to describe the constraints as I saw them. The pressure to
retain existing applications and stacks is extremely strong - surely
too strong in the foreseeable future to allow widespread voluntary
adoption of a solution which required extensive stack or application
changes.
I didn't refer to the possibility of adopting a completely new kind
of new address space (IPv6 instead of IPv4) and the required new ISP
connectivity to support it, as would be the case if the solution
involved IPv6 or some other alternative to IPv4.
That would be precluded by the points:
2 & 3 - Hosts with the IPv6 address only get multihoming etc. with
communication with other IPv6 hosts. Because the solution
presumably only provides benefits for IPv6 communications,
it fails to meet this constraint that it "fully supports
communications with all hosts - including all hosts in
non-upgraded networks." since, during adoption, most
hosts in non-upgraded networks are IPv4 hosts.
4 & 5 Most end-user networks which want multihoming do not, at
present, have all their hosts and applications fully ready
for IPv6.
However, perhaps something needs to be added to the text to address
your concern about how the scope of text seems to be within the
current IPv4 situation, rather than looking beyond it.
> If I'm not
> off-base in this observation, it would have two troubling implications.
> First, it suggests that this particular vision of incremental
> deployability foregoes, if not excludes, one of the key drivers of
> technology change in other sectors -- i.e., the possibility of early
> adoption led by aspiring new entrants, in this case aspiring routing
> services providers.
I understand you are referring to IPv6 being promoted by existing or
new ISPs who have a vision for IPv6 and promote its adoption.
IPv6 adoption remains glacial:
http://bgp.potaroo.net/v6/v6rpt.html
BGP advertised Autonomous
prefixes Systems
IPv4 219603 25296
IPv6 855 741
I can't imagine the majority of current Internet users adopting it
any time soon.
Perhaps in the future it will be adopted for fixed networks in
countries where IPv4 space is in too-short supply. However, I think
that any such service would need IPv4 connectivity to be useful - so
IPv6 addresses for the hosts is not the whole story - the hosts still
need to tunnel to some IPv4 proxy server or whatever, so they can
function on the IPv4 Internet.
The most likely scenario I can imagine for large-scale adoption of
IPv6 is in mobile networks - 3G cellphone networks and whatever they
develop into. AFAIK, this has not occurred to any substantial degree
yet.
I agree that the constraints as I wrote them seem to preclude
widespread adoption of IPv6, except perhaps in some future mobile
networks where direct connectivity to IPv4 hosts is for some reason
not required. I think the text reflects the reality, however
unfortunate the reality is for the migration to IPv6.
> Second, while the recommendations should, if
> followed, increase the odds of the associated technology being widely
> deployed, it would still leave the fate of the technology in question to
> be determined absolutely by "incumbent" routing system participants.
Since we (the RRG, the IETF etc.) have no coercive powers, I agree
that the fate of a particular network is absolutely determined by
those who are running and using the network.
I see our task as requiring the development of a new form of address
space, with all the supporting protocols and software for routers and
other network elements, which will solve the scaling problem if
widely deployed. Then we need to make that system so attractive that
it will be widely adopted by most end-user networks which want
multihoming etc. - even though they may neither know or care about
the scalability problem, bloated DFZ route numbers etc. We need to
show it works, that people can make money using it and generally
promote it. However, only if it works really well will it be widely
enough adopted to solve the routing scalability problem.
> In
> this specific sense, a future technology that satisfies all of the
> requirements for "incremental deployability" might still end up getting
> effectively "vetoed," in the way that (some say) IPv6 has been vetoed.
I am trying not to ascribe any particular meaning to "incremental
deployability".
I don't agree that IPv6 has been "vetoed". It has been available for
10 years or more an almost no-one really wants it, for the simple
reasons that it doesn't provide connectivity to the great majority of
hosts and that for most people, it provides no benefit over IPv4.
> Before I even attempt to suggest what kind of extensions or
> modifications might serve to remedy this perceived "incumbent bias" I'd
> be very interested in hearing reactions from others...
I think the term "incumbent bias" implies an unreasonable resistance
to change.
I don't think it is unreasonable that the great majority of Internet
users want and need a continuing service which enables them to
communicate with every other Internet host used by other similar people.
The IPv4 Internet is by far the biggest and most significant IT
system which has ever existed. In a free country, there would be no
demand for a service which failed to connect to even 1 or 2% of
hosts. An IPv6-only service fails to connect to nearly 100% of hosts.
This is no fault of IPv6 - its just that no-one has figured out how
to remain IPv4 compatible while upgrading to another network. It
could be done, in principle - but only by radically rewriting all
applications to use a new stack. Even then, it would be a complex
and error-prone business trying to retain functionality running on
one or the other network exclusively, or using them both at the same
time.
Here is a potential addition to the text, but I think this is taking
the scope of the piece beyond the constraints to adoption, and into
some additional goals we might have regarding the long-term
development of the Net:
The above text attempts to summarise the real-world
constraints on a scalable routing solution. It
appears that these constraints create a very high
barrier to migration of significant numbers of
existing end-user networks from IPv4 to an IPv6
service, either with or without retaining their
IPv4 address space.
It follows that even if IPv6 had a scalable routing
solution, that the barriers to mass adoption of it
would remain so high as to preclude a mass migration
from IPv4.
Our goal is to solve the routing scaling problem
in both the IPv4 and IPv6 Internets - and for the
foreseeable future, the problem only manifests in
the IPv4 Internet.
Perhaps an additional goal of a scalable routing
solution would be - by some methods yet to be
determined - to facilitate adoption of an alternative
to IPv4 such as IPv6 which is a more promising
basis for accommodating very large numbers of
individual hosts, many of which are expected to be
mobile devices.
Maybe something like this could be a footnote.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
