[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Is ISATAP a practical solution?
Short version: From what little I know about ISATAP, it is not
a practical solution to routing scalability or
IPv4 address depletion.
I explain why I think this and suggest criteria
which ISATAP or any other proposal would have to
satisfy in order for me to consider it practical.
Hi Fred,
In my 25 question taxonomy:
http://psg.com/lists/rrg/2008/msg01091.html
ISATAP didn't survive the first question, because I understand it
involves host changes (for any host which is currently IPv4 only, in
terms of OS and/or applications, which many or most are) to adopt
some kind of IPv6 connectivity.
In the "What does incremental deployment mean" thread, you, Xiaohu
and I wrote about ISATAP:
http://psg.com/lists/rrg/2008/msg01084.html XX
http://psg.com/lists/rrg/2008/msg01086.html FT
http://psg.com/lists/rrg/2008/msg01088.html RW
http://psg.com/lists/rrg/2008/msg01089.html FT
http://psg.com/lists/rrg/2008/msg01090.html RW
http://psg.com/lists/rrg/2008/msg01107.html FT
and I understand you are arguing that ISATAP has some role to play
in solving the routing scalability problem.
I have only a partial understanding of ISATAP, so I may be wrong,
but my impression is that it doesn't meet the criteria of
deployability I described in (10) here:
Re: [RRG] What does incremental deployment mean - 2 questions
2008-03-22 http://psg.com/lists/rrg/2008/msg00957.html
where one of the goals of deploying ISATAP is for it to provide
substantial resolution of the routing scaling problem and/or the
IPv4 address depletion problem. A short version of (10) is that the
new be approach provide such overall benefits to most end-user
networks from the start (with a very low active adoption rate of
both IPv6 and ISATAP) that the scheme would in fact be widely
adopted without external inducements.
Perhaps this "substantial resolution" is just weaning people off
their need for IPv4 addresses fast enough for IPv6 to be widely
adopted, and for some map-encap scheme to solve the routing scaling
problem for IPv6.
My starting assumptions are that virtually everyone with an IPv4
host needs to be able to use them as clients to establish
communications to all existing and future IPv4 servers, and to be
used for all existing purposes, including VoIP etc. P2P applications
or whatever in which some server coordinates "client" hosts to
directly communicate (where possible due to NAT etc.) My other
assumption is that a significant proportion of these hosts are IPv4
servers and need to retain this functionality, on fixed, public, IP
addresses.
Without maintaining all this in some easily manageable way, there is
no way any one host, or any network of such hosts, would gain any
short to medium term overall benefit from adopting any scheme which
was intended to help with routing scalability or IPv4 address depletion.
You wrote:
>> Hi Fred,
>>
>> Thanks - I should have remembered this:
>>
>>> ISATAP allows dual-stack nodes to discover routers that
>>> can reach destinations on the global IPv6 Internet.
>>>
>>> ISATAP is already widely implemented and deployed; in
>>> many deployments it is even turned on by default.
>>
>> but it doesn't alter my understanding that it is not a solution to
>> the IPv4 routing scaling problem, because the only way it helps is
>> with hosts which are dual-stack and with applications which in fact
>> communicate via IPv6.
>
> The "domain of applicability" does not explicitly say
> this, but dual-stack routers (or "hosts" that forward
> packets on behalf of other nodes) are also within the
> realm of application. That means that you can stack up
> an arbitrarily large IPv6 network behind an ISATAP "host".
I don't understand ISATAP or the above enough to comment further.
>> Also, ISATAP is a transition mechanism, requiring an IPv4 address.
>
> A private IPv4 address; yes. There are lots of those
> available within end sites without impacting routing
> scaling within the core.
OK - so all hosts with a public address in an ISATAP upgraded
network would need to be reconfigured in some way to have an
additional non-public IPv4 address?
I think any proposal which involves such host upgrades fails to meet
my criteria, because even if we ignore the cost, risk etc. of the
upgrade (including a configuration change) only a subset of hosts
can be upgraded in this way. Hosts include various hardware devices
such as printers, not just PCs and big routers etc. This includes
weird old servers which need to be kept working. (I am still
running Red Hat 7.2 - because it will take me about four days to
configure all the things I want for a new OS, including patches to
the Courier Maildrop mailsort program to deliver mailing list
messages to the IMAP Inbox already tagged for deletion, so I can
read all new list messages in my Inbox, but can get rid of them with
Expunge. Each list's messages are sorted into their own mailbox as
well.)
>> So its only contribution to the IPv4 routing and addressing problem
>> would be to facilitate wide enough adoption of IPv6 that significant
>> numbers of end-users would be happy to have IPv6-only addresses,
>> with no IPv4 direct connectivity.
>
> No; not IPv6-only. Use address selection rules to
> determine the appropriate address for use under the
> appropriate circumstances. Sometimes that means IPv6
> and other times that means IPv4.
I have never tried running IPv6, but I imagine that not all
applications will make the right decision (however defined) about
choosing between IPv4 or IPv6 addresses - and of many or most can't
use IPv6 at all. If the upgrade to ISATAP or whatever causes flaky
behavior or confusion for users, it is a non-starter.
Since my criteria (10) and above involve end-users having continued,
full communication with the rest of the world's IPv4 hosts,
including with some of their hosts operating with their existing
stable public IPv4 addresses because they are servers, I don't see
how ISATAP could achieve this and help with one or the other of the
problems: routing scaling or IPv4 address depletion.
Perhaps you could explain by way of an example how ISATAP would help?
Suppose there is a company with 1000 staff, 1000 desktop PCs of
various flavours - Windoze, Mac, GNU/Linux etc. There are also a
bunch of servers of similar flavours, some on private addresses and
others on public addresses in the PA or PI space the company
currently uses. Some of these servers and routers are publicly
addressable, for the public and for employees doing email, VPN etc.
when in other locations. Some of these desktop machines, printers,
routers, servers etc. can handle IPv6 and others can't. Some can be
reconfigured and some can't.
The company must keep all this going. Whatever effort it makes to
deploy ISATAP (or any other scheme) needs to be paid for immediately
or within months by benefits such as:
1 - A cheaper, more flexible approach to multihoming,
portability, TE etc. than the current PI approach, or
than be converting from current PA space to new
PI space using conventional BGP management.
2 - Whatever benefits the company might gain from having
some or all of its machines able to use IPv6. (This
is no benefit at all at present for most users, since
any host worth connecting to will make itself available
on IPv4, not just on IPv6.)
3 - Some other benefits?
The fact that adoption helps with the routing scalability or IPv4
address depletion problem now or in the future is not a benefit to
the company.
What exactly would the company need to do to adopt ISATAP?
What changes to routers and hosts would this involve?
What new boxes or new address assignments would be needed?
How scalable is ISATAP's provision of IPv6 connectivity? For
instance, if 10% or 70% of end-user networks adopted ISATAP, would
this tangle up the IPv6 routing system? If so, what steps would
end-users need to take to get a different kind of IPv6 connection,
perhaps with different addresses, which would not make a mess of the
IPv6 routing system?
What benefits for the company result in the next 6 months?
Although I know little about ISATAP, I think I know enough to say
that it doesn't meet my criteria.
Perhaps you can show me the way through the problems I foresee, or
suggest some other criteria which ISATAP satisfies, and still
provides reasonably immediate benefits to early adoptors - whilst
making some kind of contribution to solving the routing scaling and
IPv4 address depletion problems.
- Robin http://www.firstpr.com.au/ip/ivip/
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg