Re: [RRG] RE: Is ISATAP a practical solution?

[Robin Whittle <rw@firstpr.com.au>]

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.

So do IPvLX and ISATAP really belong on the RRG wiki, under the
heading "Active 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.

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.

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.

Maybe humanity will be stuck inhabiting IPv4 more and more
efficiently forever.  Something like Positano, Italy:

http://glamgal.typepad.com/.shared/image.html?/photos/uncategorized/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.

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.


>>>> 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.

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