[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