[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] RE: Is ISATAP a practical solution?
Robin,
See below for some follow-up:
>-----Original Message-----
>From: Robin Whittle [mailto:rw@firstpr.com.au]
>Sent: Thursday, April 03, 2008 6:55 PM
>To: rrg@psg.com
>Cc: Templin, Fred L
>Subject: Re: [RRG] RE: Is ISATAP a practical solution?
>
>Hi Fred,
>
>Thanks for your reply. I apologise for taking one message, on
>incremental deployability and responding to it as if it was part of
>another discussion about routing scalability.
>
>I thought ISATAP was intended as a mechanism of dealing with the
>routing scaling problem, because it is mentioned in the RRG wiki:
>
>http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
>
>but I now realise it is mentioned there because it has something to
>do with IPvLX:
>
> http://tools.ietf.org/html/draft-templin-ipvlx-08
>
>Yet this ID hasn't been revised since May last year, its abstract
>doesn't mention the routing scaling problem, and I don't recall it
>being discussed on the RRG or RAM list.
Are you suggesting for me to revise the IPvLX proposal?
>So do IPvLX and ISATAP really belong on the RRG wiki, under the
>heading "Active proposals"?
I think so; they have been around a lot longer than any
of the proposals on your short-list (although admittedly
not as long as some of the foundational earlier proposals).
>Sorry if my previous message was overly long. I was trying to
>explain my criteria to encourage further discussion.
>
>You wrote:
>
>> 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.
>
>The reason I mentioned ISATAP in my "Taxonomy: 25 questions" message
>was that it is mentioned on the RRG wiki page. The first two
>questions were intended to weed out anything which wasn't a
>potentially practical proposal (according to my criteria) for
>solving the routing scaling problem.
>
>
>> It seems you take a somewhat dim view of the potential
>> role for IPv6 in general in terms of addressing the
>> routing scaling issue.
>
>I have a dimmer view of IPv6 than many IETF folks. I think 64 bit
>addresses would have been better. With 128, there are 32 bytes of
>address in every packet - which seems like overkill when there are
>millions of people sending two-way streams of 50 VoIP packets a
>second with only 20 bytes of payload. However there are creative
>uses of the extra bits, such as Six/One.
I think there are those who place faith in header compression
as a mitigation for the sort of situations you are describing.
>This address burden gets worse with any map-encap tunneling header,
>so I am keen to keep Ivip encapsulation as minimal as possible:
>IP-in-IP. LISP involves a LISP header and therefore a UDP header as
>well. I am also keen to avoid anything like a SEAL header, at least
>on the shorter packets in any map-encap tunnel.
Well, when you are doing encaps you are already committed
to inflating the size of packets. The SEAL encapsulation
does not add a lot beyond the base encapsulation, and there
is value in the bits added (IMHO).
>Since the five map-encap schemes could work with IPv6, if we could
>somehow get everyone off IPv4 and onto IPv6, then it would be
>possible to solve both routing scalability and the address shortage
>problem. The trouble is, no-one knows how to make a new addressing
>system which people could painlessly change over to while not
>needing an IPv4 address, but still be able to communicate with any
>IPv4 host.
>
>
>> 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.
>
>I understand and agree with the long-term argument: the extremely
>desirable goal of NAT-free any-to-any communication without being
>cramped for address space. However I am not sure if this is a "no
>other choice" goal.
>
>Now, and for the foreseeable future, there is no direct reason why
>ordinary net users would want IPv6. Until virtually everyone has
>IPv6, it is impossible to imagine why ordinary users would want to
>relinquish their IPv4 addresses.
IMHO, I don't envision the situation in which users would
relinquish their existing IPv4 addresses, i.e., even if
they move to IPv6.
>Maybe humanity will be stuck inhabiting IPv4 more and more
>efficiently forever. Something like Positano, Italy:
>
>http://glamgal.typepad.com/.shared/image.html?/photos/uncategor
>ized/dsc00216.jpg
>
>with each end-user network making the most of its little public
>patch of one or a few IP addresses, all crowded together.
>
>That is ugly compared to us moving to a more expansive addressing
>scheme - and IPv6 is the only one on offer.
>
>I suspect that if NATs and their traversal become more standardised
>that the "IPv4 forever" wouldn't be so disastrous and that "no other
>choice but IPv6" would prove to be wrong.
IMHO, it can be a "both/and" situation as opposed to all
one way or the other.
>The one thing I could imagine making IPv4 completely unworkable
>would be every cellphone on the planet having its own mobile public
>IP address, which I think could be done with the map-encap approach
>to mobility. Since there are 3.3 billion such devices now, IPv4
>could never do that. But then think of those bloated IPv6 addresses
>chewing up bandwidth on cell-phone radio links carrying streams of
>VoIP packets.
Again, header compression has been proposed.
>>>>> 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.
>
>OK.
>
>
>>> 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.
>
>OK, but my impression is that there would be some flakiness from the
>point of view of the ordinary user.
>
>
>>> 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.
>
>OK. My expectation that ISATAP should considered as a way of
>helping with routing scaling was mine alone - not what you wrote.
>
>
>>> 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".
>
>I was hoping for a more detailed description, but since ISATAP isn't
>a contender for solving the routing scaling problem, this list is
>not the appropriate place to go into such detail.
There's not really much more to it than what I have
already said, but here is an overview that should help:
http://download.microsoft.com/download/0/7/c/07ca1a49-050c-4928-a13f-67b
f812d3f80/ISATAPOverview.doc
Thanks - Fred
fred.l.templin@boeing.com
>Googling "ISATAP" deployment turns up a number of pages. However,
>with "ISATAP" only returning 49k pages, I guess it is not very
>widely used. "6to4" turns up 131k.
>
>>> 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.
>
>Without knowing how ISATAP worked, I was wondering whether as a
>transition mechanism it involved arrangements which were sub-optimal
>compared to whatever is the best way of doing native IPv6 connectivity.
>
>
>>> 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.
>
>OK. Thanks for this.
>
>
>>> 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.
>
>OK - I think this comes down to whether the end-user really has a
>direct need for IPv6 connectivity. At present, and for the
>foreseeable future, most end-users don't.
>
> - Robin
>
>
--
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