Subject: RE: IPv6: Past mistakes repeated?

From: Ian King <[email-masked]>
Date: Mon, 24 Apr 2000 09:11:23 -0700

"Near-perfect example"?  I beg to differ.  I used to work for a Local
Exchange Carrier.  

The telephone number situation in the United States has been one of
continual crisis for years, because of rapid growth in use (in part because
of Internet access!).  The area served by a given "area code" would be split
into smaller areas with multiple area codes; these days, those areas aren't
necessarily even contiguous.  Moving from seven-digit to (effectively)
ten-digit numbers was difficult, if not impossible, for some older
equipment; sometimes a kludge could be developed to allow the old equipment
to be used for a few more months or years, but often as not new equipment
was required, at considerable cost.  It was difficult for end users, too: in
addition to the confusion everyone suffered during the transition (I still
get scads of wrong numbers on my cellphone, because people forget the area
code is needed), businesses had to spend great sums of money to revise their
public appearance (advertising, letterhead, etc.).  

And, often as not, we'd do it all over again a few months later.  

My point is that ANY numbering scheme is difficult to change, once it's in
place.  Someone else on this thread made a good point, however, that the
administration of that scheme can make worlds of difference - this person's
point was about "giveaway" assignment of large portions of the address
space, "because there's so much" -- hm, sounds like the exhaustion of
Earth's natural resources, too.  :-)  I'd suggest that address assignment
policy should keep process lightweight, so that it is realistic for
businesses to regularly ask for assignments in more granular chunks; rather
than grabbing a class A-size space "just in case", big users would be
willing to request another 256 when the new branch office opens, then
another 64 for the summer interns... and so individuals can easily get
multiple addresses through an ISP.  

In fact, it should be as easy as getting a telephone number.  -- Ian 

> -----Original Message-----
> From: Anthony Atkielski [mailto:[email-masked]]
> Sent: Monday, April 24, 2000 3:05 AM
> To: [email-masked]
> Subject: IPv6: Past mistakes repeated?
> 
> 
[snip]
> The only real solution to this is an open-ended addressing 
> scheme--one to which digits can be added as required.  And it just so
> happens that a near-perfect example of such a scheme is right 
> in front of us all, in the form of the telephone system.  Telephone
> numbers have never had a fixed number of digits.  The number 
> has always been variable, and has simply expanded as needs 
> have changed
> and increased.  At one time, a four-digit number was enough 
> to reach anyone.  Then seven-digit numbers became necessary.  Then an
> area code became necessary.  And finally, a country code 
> became necessary.  Perhaps a planet code will be necessary at 
> some point in
> the future.  But the key feature of the telephone system is 
> that nobody ever decided upon a fixed number of digits in the 
> beginning,
> and so there is no insurmountable obstacle to adding digits 
> forever, if necessary.  Imagine what things would be like if 
> someone had
> decided in 1900 that seven digits would be enough for the 
> whole world, and then equipment around the world were designed only to
> handle seven digits, with no room for expansion.  What would 
> happen when it came time to install the 10,000,000th 
> telephone, or when
> careless allocation exhausted the seven-digit space?
> 
[snip]

---

From: Daniel Senie <[email-masked]>
Date: Mon, 24 Apr 2000 12:48:27 -0400

> And, often as not, we'd do it all over again a few months later.

We've now got number portability. I've got a choice of local exchange
carriers. I can get service from Bell Atlantic or from MediaOne. I can
keep the same phone number when I move from one to the other.

From the reports I read, this was implemented by mapping phone numbers
to some other tag (which the user doesn't see) which is used to get the
calls to the proper carrier and ultimately to the proper user.

Sounds a whole lot like using DNS to map names to IP addresses. Of
course we expose users to IP addresses WAY too often, and overuse them
in applications as well, for this analogy to be really workable for the
Internet.

Users shouldn't care or know about the network's internal addressing.
Some of the application issues with NATs spring directly from this issue
(e.g. user of X-terminal setting display based on IP address instead of
DNS name).

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: John Stracke <[email-masked]>
Date: Mon, 24 Apr 2000 13:21:34 -0400

Ian King wrote:

> I'd suggest that address assignment
> willing to request another 256 when the new branch office opens

Wasn't one of the design goals of IPv6 to make renumbering easier, so that
people could move from small assignments to large ones?

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |The cheapest, fastest, most reliable components|
[email-masked]|of a computer system are those that aren't     |
|                |there.--Gordon Bell                            |
\================================================================/

---

From: Richard Shockey <[email-masked]>
Date: Mon, 24 Apr 2000 12:39:09 -0500

>keep the same phone number when I move from one to the other.

FYI And by 2002 you will be able to port your number from your land line 
phone service to your cell phone as well...that is  called "service 
portability".

>calls to the proper carrier and ultimately to the proper user.

Yep ...essentially phone numbers are nothing more than names to the IN.

FYI  there is a ID on how the Number Portability system works and there 
have been recent FCC rulings on Number Conservation and Pooling which 
direct teleco's not to hoard phone numbers or else they will be taken away.

It is a system that has worked remarkably well and is rapidly being adopted 
my many other countries as well.

>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-foster-e164-gstn-np-00.txt

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Apr 2000 15:43:04 -0400

> (e.g. user of X-terminal setting display based on IP address instead of

it's not the same issue.  the point of using IP addresses in DISPLAY 
variables is not to make them visible to the user - it's because 
using the IP address is (in a non-NATted network) far more reliable 
than depending on the DNS lookup to work.  the fact that doing this
makes the address more visible to the user is just a side effect;
most users don't care diddly about it one way or the other as long
as it works.

Keith

---

From: "Anthony Atkielski" <[email-masked]>
Date: Mon, 24 Apr 2000 22:30:19 +0200

> The telephone number situation in the United States
> has been one of continual crisis for years, because
> of rapid growth in use (in part because of Internet
> access!).  The area served by a given "area code" would
> be split into smaller areas with multiple area codes;
> these days, those areas aren't necessarily even contiguous.

That is mostly because the telco(s) tried to impose a fixed address length
on a scheme that really should have remained variable.  Telephone numbers
overseas are truly variable.  When you dial 011+3, the remaining digits can
be anywhere from one to a thousand.  The local end just stores them all
until you say you are done (by pausing or hitting the # key), and then it
routes it as far as it can, and passes the rest onto some other node.

> I'd suggest that address assignment policy should
> keep process lightweight, so that it is realistic for
> businesses to regularly ask for assignments in more
> granular chunks ...

But if you use a truly variable scheme, you don't have to assign anything at
all.

Say Company X wants some addresses, and it is in an area where all addresses
start with 9482.  You just add some digits, tell them what they are, and
they can add as many addresses as they want behind those digits.  All you
have to care about is that 94825xxxxx gets routed to Company X.  The rest of
the address allocation is their business.  They might have just two digits
on the end, or they might have forty.

With fixed-length addresses, you're in trouble as soon as you make an
assignment.  You might assign 94820000 through 94829999 to Company X.  The
problem is that, if Company X needs only 200 addresses, you've wasted 9800
addresses, and you can't give them to anyone else.  Conversely, if Company X
ever needs more than 10000 addresses, you have to completely reallocate
everything, or fragment their address range.  Either way, you lose.

> ... big users would be willing to request another 256
> when the new branch office opens, then another 64 for
> the summer interns...

All well and good, except that it fragments the address space, making it
impossible to route on just a portion of the address--you have to start
looking at the entire address, all the time.

  -- Anthony

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 24 Apr 2000 23:09:11 +0100 (BST)

> has been one of continual crisis for years

funny, I've always had the impression that the '555' area code was
infinite.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 25 Apr 2000 10:57:30 -0400

John Stracke <[email-masked]> writes:

> Wasn't one of the design goals of IPv6 to make renumbering easier,
> so that people could move from small assignments to large ones?

Yes.  IPv6's primary tool in this regard is that it supports multiple
addresses simultaneously. To renumber, you add a new address to each
of your devices (corresponding to the addresses appropriate for the
new ISP) and start using it. For a transition period, both addresses
work equally well. When everything is switched over to the new
address, you simply stop using the old address. There are mechanisms
in IPv6 that make this approach straightforward (i.e., specifying when
to start using the new addresses, how long to overlap using both the
old and new ones, and when to finally retire the old addresses). No
flag day, no need to even reboot machines.

Thomas

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2000 09:56:13 -0700

> in applications as well, for this analogy to be really workable for the

It might also sound like another level of indirection would be useful.

DNS -> IP is sometimes difficult to manage because both can change. It
would be useful to have an ID that had nothing to do with either,
allowing renumbering and renaming without losing that pointer.

E.g. DNS <-> ID <-> IP

Joe

---

From: Paul Francis <[email-masked]>
Date: Tue, 25 Apr 2000 13:53:40 -0700 (PDT)

>  ..... snip snip .....

I have a hard time believing that your average IP net manager
wouldn't prefer to run an IPv6-IPv6 NAT box (lets call this
NATv6) at her ISP boundary rather than do site-wide renumbering.
My reasoning goes as follows:

First, while I am willing to grant you the term "straightforward"
to describe site-wide renumbering (it is, for instance, easier
than running a dynamic routing protocol), I would not grant the
term "trivial", and I would say there is some risk and effort
(to minimize the risk) involved. 

For instance, draft-ietf-ipnlwg-router-renum-10.txt says:
"Because of the power of the Router Renumbering mechanism, each RR
message includes a sequence number to guard against replays, and is
required to be authenticated and integrity-checked." Sounds risky
to me.

To minimize the risk, the IP net manager would go through siginifant
effort, first thoroughly testing everything to see that it works as
it is supposed to, then planning the renumbering, then doing the first
phase (adding the new prefix to routers before updating any hosts),
then doing a lot of testing of that, then bit by bit updating hosts,
testing each time, then somehow making sure that every host (or at
least every important host) has been properly updated and the new prefix
is fully in use, and then finally removing the old prefix (and you can
bet her heart will skip a beat when the window reading "Are you sure
you want to delete this prefix" comes up.

This is all doable, but isn't something a net manager is going to
take on lightly.

Now consider the NATv6 alternative.  The average net admin is already
comfortable with NAT at the ISP boundary (hell, some even like it).
She will already be running NAT, if for no other reason than to deal
with IPv4-IPv6 transition.  NATv6 is much less onerous than NATv4,
because the address mapping is one to one (and in fact is probably
a simple prefix rewriting, not a large table lookup), not many to
one like with IPv4.  What's more, NATv6 will give you some rudimentary
form of multihoming (can advertise different prefixes at different
ISPs)!

It seems to me that the decision to just use NATv6 rather than
do a site-wide runumber will be a very easy decision to make.

PF

---

From: Steve Deering <[email-masked]>
Date: Tue, 25 Apr 2000 16:21:50 -0700

>do a site-wide runumber will be a very easy decision to make.

If that were the only issue, sure.  But there are tradeoffs: is the ease
of renumbering (which should be a relatively rare event) offered by a NAT
box worth all the ongoing costs incurred in using NAT in the first place
(more complicated, fragile network, more difficult problem diagnosis,
degraded performance, weakened security, opportunity costs of not being
able to run certain kinds of applications, and so on)?

Steve

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Apr 2000 23:29:13 -0400

> NATv6) at her ISP boundary rather than do site-wide renumbering.

some of the applications that will motivate the deployment of
IPv6 will be those that do not work with NAT.  (if they do work
with NAT, it's probably easier to just use IPv4.)

so it's quite likely that whereas imposing a NAT box on IPv4 users
wouldn't break many apps using IPv4, imposing a NAT box on IPv6 users
will break many of the apps using IPv6.

also, people using NATs are starting to become aware of the problems
that they cause - particularly those trying to build VPNs between
multiple NATted networks.  so by the time there's enough v6 
deployment for people to have to renumber, enough people will have 
been burned by NATs that won't want to repeat that experience.

Keith

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Apr 2000 09:11:46 -0400

> do a site-wide runumber will be a very easy decision to make.

Actually, if your assumption is that NATv6 is better than IPv6 with
renumbering, then IPv4 and NATv4 was good enough to start with and
there was need to move to IPv6 in the first place. However, many
people fear that NATs just won't cut it as a long-term solution, with
a number of different reasons why this is so (impact on security and
applications, operational and administrative costs, etc.). But if
NATv4 doesn't cut it, I don't see how NATv6 between IPv6 sites cuts it
either.

Thomas

---

From: Paul Francis <[email-masked]>
Date: Wed, 26 Apr 2000 11:12:50 -0700 (PDT)

>  renumbering, then IPv4 and NATv4 was good enough to start with and

I'm not prepared to say that NATv6 is better than IPv6+renumber,
simply because what is better depends on what is important to
the user.  By some general architectural criteria IPv6+reunumber
is better, but I guess if pushed I would have to say that, for
a net manager with a limited budget, for whom internal connectivity
is far far more important than external connectivity, and with
some tricky mix of hosts and routers for instance, yes NATv6 is
"better".

I can easily imagine being a consultant and recommending to a
certain class of customers in certain situations that they use
NATv6.  (Boy I may regret this sentence...its going to be used
against me someday...  :-(

>  NATv4 doesn't cut it, I don't see how NATv6 between IPv6 sites cuts it

NATv4 doesn't cut it, but net managers use it anyway.  NATv6 won't
cut it, but net managers may very well use it anyway.

I may be wrong...the motivations for using NATv6 will be weaker
than the motivations for using NATv4.  But at the same time, the
problems with using NATv6 will be less than the problems with
using NATv4.

On the motivation side, NATv6 won't have the lack-of-addresses
problem.  While this is the major motivation for NATv4, I don't
think it is the only motivation.  On the problems side, NATv6
won't have the problems of port mapping or of having to dynamically
map lots of internal addresses into a small number of external
addresses.

I guess my assertion, to the extent that I'm making one at all,
is that one should take into account these least paths of
resistance when designing new protocols.  This may mean not
designing the protocol you'd otherwise like to design if
practically speaking nobody is going to use it.  Unfortunately
I'm not able to translate this vague assertion into any
concrete suggestion for IPv6 per se...

PF