[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] RE: Is ISATAP a practical solution?
Robin,
It interests me to see that you would invest an
extensive analysis in ISATAP, which you previously
categorized as a transition mechanism. Perhaps a
better term (which has been used by others) is a
"coexistence" mechanism, where IPv6 and IPv4 are
expected to coexist in the network for the
forseeable future.
It seems you take a somewhat dim view of the potential
role for IPv6 in general in terms of addressing the
routing scaling issue. Based on who you ask, though,
I think you would find that there are those in the
IETF that feel that we have no other choice but to
ensure a successful deployment of IPv6 and to ensure
that routing scaling is not adversely impacted in the
process. Maybe you don't subscribe to that philosophy,
but IMHO the debate would need to be taken to a higher
level than what we are engaged in here - my $.02.
I will try to address the technical aspects of your
questions below:
>-----Original Message-----
>From: Robin Whittle [mailto:rw@firstpr.com.au]
>Sent: Wednesday, April 02, 2008 5:21 PM
>To: rrg@psg.com
>Cc: Templin, Fred L; Xu Xiaohu
>Subject: 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?
Nodes that have public IPv4 addresses and with access to
the global Internet would prefer to use 6to4 [RFC3056]
over using ISATAP.
>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.
Again, to my understanding, there are address selection
rules and APIs used for this purpose.
>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?
ISATAP supports communicating endpoints that use IPv6
w/o disrupting any pre-existing IPv4 infrastructure nor
interfering with future IPv4 deployment. We haven't
talked yet about the role of IPv4 NATs, but IMHO we can
simply acknowledge that NATs exist and leave it at that.
>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?
All that is needed to enable ISATAP is to turn it on
through relatively simple administrative actions. Then,
end systems and routers that understand ISATAP should
"just work".
>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?
I don't see how, i.e., I don't see any undesireable
interactions with 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?
There probably should be a pecking-order of sorts, e.g.,
1) use native IPv6 if available, else:
2) use 6to4 if available, else:
3) use ISATAP if available, else:
4) use TEREDO if avaialble
and, ideally, the selection would be done w/o explicit
end-user involvement.
>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.
As I said above, IMHO the IPv6 debate needs to be taken
to a higher level and is not specific to just ISATAP.
Fred
fred.l.templin@boeing.com
>
> - 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