[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Fred,

I will respond to what you wrote about header lengths and SEAL in a
separate thread.

You wrote:

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

I would have thought that if the proposal was "active", that there
would be an 8 page summary and analysis document for it, and that
the relevant Internet draft be updated within 6 months.

Since scalability is part of what you are trying to achieve (from
the introduction):

  This document proposes an architectural framework for IPv6/IPv4
  coexistence known as: "IPvLX (IP with virtual Link eXtension)"
  with goals of limiting core routing table growth while supporting
  scaling to arbitrarily large numbers of end systems and restoring
  global Internet transparency.  The scheme uses IPv6 for end system
  interface identification and simple network middleboxes to extend
  virtual links (VLs) across one or more IPv4 networks.

I think it would be good to mention scalability in the abstract.


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

How then would your proposal help with the address scaling problem
in the IPv4 routing system?


>> 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.
>
> IMHO, it can be a "both/and" situation as opposed to all
> one way or the other.

I suppose if some set of hosts, such as cellphones each with an IPv4
address or an IPv6 /64, became needed in such numbers that they
couldn't all fit on IPv4, then this would mean a large number of
users would have native IPv6 addresses only.

Then, some subset of other users (implicitly those with IPv4
services only) would have some kind of reason to get IPv6 - for
instance to do more direct communication with those mobile hosts
than would be the case via whatever gateways etc. would be used
otherwise.

Then, I suppose, over time the dual stack dual IPv4/IPv6 connection
model could spread.  All this sounds really messy - everyone being
stuck in IPv4 forever or having part of the user base migrate to
IPv6, but most never wanting to leave IPv4 because it works fine.

Thanks for the link to this overview:

http://download.microsoft.com/download/0/7/c/07ca1a49-050c-4928-a13f-67bf812d3f80/ISATAPOverview.doc

The detailed technical stuff is pointed to from there:

Microsoft Intra-site Automatic Tunnel Addressing Protocol
Deployment Guide

http://www.microsoft.com/downloads/details.aspx?FamilyID=0f3a8868-e337-43d1-b271-b8c8702344cd&displaylang=en

I won't pursue these, because I think that no solution to the IPv4
routing scaling problem will be widely deployed if it relies in some
way on hosts having anything to do with IPv6.

  - 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