Subject: [RRG] Is ISATAP a practical solution?

From: Robin Whittle <[email-masked]>
Date: Thu, 03 Apr 2008 11:21:21 +1100

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 [email-masked] 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 3 Apr 2008 10:22:17 -0700

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:[email-masked]] 
>Sent: Wednesday, April 02, 2008 5:21 PM
>To: [email-masked]
>Cc: Templin, Fred L; Xu Xiaohu
>Subject: Is ISATAP a practical solution? 
>

Nodes that have public IPv4 addresses and with access to
the global Internet would prefer to use 6to4 [RFC3056]
over using ISATAP.

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

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

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

>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

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.

>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
[email-masked]

---

From: Robin Whittle <[email-masked]>
Date: Fri, 04 Apr 2008 11:07:51 +1100

Hi Fred,

Sorry, I got my wires crossed.  In my "Is ISATAP a practical
solution?" I responded to your message:

  RE: [RRG] What does incremental deployment mean
  http://psg.com/lists/rrg/2008/msg01107.html

as if it was a response to my "Taxonomy: 25 questions" message, in
which I mentioned ISATAP.  I only considered it as a solution to the
routing scaling problem because it was mentioned in the RRG wiki. I
misunderstood your message 1107 as meaning you thought I should
consider ISATAP as a solution to the routing scaling problem.

I will respond to your discussion of ISATAP in another message.

  Regards

    - Robin

---

From: Robin Whittle <[email-masked]>
Date: Fri, 04 Apr 2008 12:55:12 +1100

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.

> expected to coexist in the network for the

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.

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

> the global Internet would prefer to use 6to4 [RFC3056]

OK.

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

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

> end systems and routers that understand ISATAP should

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.

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

> and, ideally, the selection would be done w/o explicit

OK. Thanks for this.

> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 4 Apr 2008 09:54:23 -0700

Robin,

See below for some follow-up: 

>Sent: Thursday, April 03, 2008 6:55 PM
>To: [email-masked]
>Cc: Templin, Fred L
>Subject: Re: [RRG] RE: Is ISATAP a practical solution?
>
>Hi Fred,
>

Are you suggesting for me to revise the IPvLX proposal?

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

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

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

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

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

>chewing up bandwidth on cell-phone radio links carrying streams of

Again, header compression has been proposed.

>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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 4 Apr 2008 13:15:28 -0700

Robin, 

Some additional follow-up:

>>I am also keen to avoid anything like a SEAL header, at least

Including the SEAL header on large packets and omitting
it on smalls is certainly an idea to be taken seriously
and not to be dismissed w/o further consideration. However,
reasons we might not want to do that include:

 1) multiple encapsulation formats on the same link; could
    confuse both tunnel endpoints and middleboxes
 2) omission of SEAL header reduces identification to
    only 16 bits; may not be sufficient for duplicate
    packet and/or off-link attack detection

What are your thoughts on this?

BTW, the idea of extending the IPv4 ID to 32 bits in a
manner similar to the way SEAL does it is not new. The
earliest proposal to do this (which I came across after
publishing SEAL) was from Steve Deering on the mtudwg
mailing list in Feb. 1990:

  http://ipvlx.org/mtudwg-log   

but I wouldn't be surprised if there were still
earlier proposals. The primary difference between what
SEAL is doing and what Steve articulated was that Steve
proposed a new IPv4 option, whereas SEAL proposes a new
IPv4 protocol.

Thanks - Fred