Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: Sean Doran <[email-masked]>
Date: Mon, 24 Apr 2000 16:32:38 +0200 (CEST)

[Keith Moore on a "KMart box"]
| take it home, plug it in to your phone line or whatever, and get
| instant internet for all of the computers in your home.  
| (almost just like NATs today except that you get static IP addresses).

No, not "or whatever" but "AND whatever".

Otherwise this is a nice but insufficient device, 
since there is an implicit presupposition that only
 one provider will be used by any given owner/lessor 
of this K-Mart box.

If one makes a broad policy decision that it should be possible
and simple for all very small users to be serviced simultaneously
by multiple providers, then you must be very careful about the
static IP address constraint.

Personally, I think _at least_ individual households should be
multihomed -- adjust your K-Mart box so that it can support multiple
interfaces.  Perhaps you might end up with a plug for your DSL or
POTS connection, a plug for your cable connection, and a plug for
your wireless or electricity-grid connection.

Traditional multihoming has some significant features:
	-- all the hosts in the multihomed entity have a fixed
	   set of addresses relative to one another
	   (i.e., hosts don't care about the "remote" topology)
	-- traffic is balanced in both directions in some fashion 
           across the set of multiple providers' connections
	-- if there is a partition in the network which
	   breaks connectivity through one provider, the
	   connectivity will automatically back-up through
	   the remaining provider(s) who are unaffected
	   by the partition

Unfortunately, IPv6's current addressing architecture makes it very
difficult to do this sort of traditional multihoming if one is not
a TLA.  This is a significant step backward from the current IPv4
situation, where one can persuade various operators to accept
more-specific prefixes (coloured with appropriate community
attributes) in order to optimize return traffic from particular
parts of the Internet.

Therefore, in order to support IPv6 house-network multihoming, so
as to preserve at least these three features of traditional
multihoming, either the current IPv6 addressing architecture's
restrictions on who can be a TLA must be abandoned (so each house
becomes a TLA), or NATs must be used to rewrite house-network
addresses into various PA address ranges supplied by the multiple
providers.

If it is reasonable to want to support multihoming individual
SMEs, households, or even "smd"s, IPv6's overall addressing and
routing architecture seems much ill-suited to the task WITHOUT
the presence of NAT.   

IPv6's larger address space is merely a necessary piece of an 
Internet which will not run out of numbers.   

NATs and NAT-like translators appear to be more and more a
fundamental tool in the IPv6 arsenal, and it unfortunate that
people position IPv6 as an alternative to NAT.

	Sean.

---

From: Steve Deering <[email-masked]>
Date: Mon, 24 Apr 2000 09:42:06 -0700

>attributes) in order to optimize return traffic from particular

Sean,

That is widely claimed but incorrect.  Nothing in the IPv6 addressing
architecture prevents a user from negotiating with multiple operators
to accept any prefix assigned to that user.  IPv6 retains the same
capability as IPv4 in that respect.

>becomes a TLA),...

The consequences of those restrictions are not what you imagined, but
even so, making each house a TLA does not strike me as a scalable
multihoming solution for very large numbers of houses, given the current
state of the routing art.

>...or NATs must be used to rewrite house-network addresses into various
>PA address ranges supplied by the multiple providers.

That's not the only possible alternative, and it is an alternative that
creates a bunch of other unsolved problems (see earlier messages in this
thread).

>Internet which will not run out of numbers.  

Wow, we actually agree on something!  (Though I could quibble over the
"merely".)

Steve

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Apr 2000 13:40:48 -0400

> one provider will be used by any given owner/lessor 

sorry if I oversimplified things.  it's clear to me that you have
to allow for user selection of providers, but I was trying to 
make a simple illustration of how this might work, not write 
the requirements document.
 
> static IP address constraint.

I'm all for user selection of providers, but 'serviced simultaneously
by multiple providers' seems like a stretch.  as I'm sure you are aware,
traditional multihoming has scaling implications for the routing 
infrastructure - it's far from clear that it's feasible for every
household to be traditionally multihomed.

my view is that folks who want traditional multihoming 
(i.e. they who want their own entries in core routers' tables)
will sooner or later have to pay major ISPs for those entries.  
I have heard that you can pay individual ISPs for this now.  
so maybe what we need is a clearinghouse organization or two 
that provides one-stop shopping - take your money and ensure
that your routing table entry is maintained in each of several
major ISPs routers.  once we have that kind of cost recovery model,
folks who really need traditional multihoming (and can afford it)
will be able to get it - it won't matter how big your subnet mask is.

> 	   the remaining provider(s) who are unaffected

traditional multihoming is very useful under the right circumstances,
though you need a lot more than just multiple connections advertised
to the net to make it work well.

> attributes) in order to optimize return traffic from particular

I agree that traditional multihoming should not be limited to TLA-sized
portions of the net, and I expect that in practice, even in IPv6, 
it will not be so limited.  having fixed partition sizes in IP addresses
is a bad idea - we learned that long ago with fixed class sizes. And
IPv6-style multihoming through DNS has some fairly significant limitations - 
not that it's not useful for some cases, but for many applications it's 
not going to substitute for traditional multihoming.  

> addresses into various PA address ranges supplied by the multiple

it's not at all clear to me why households need traditional multihoming,
nor how to make it feasible for households to have it.  so I would regard
this as overdesign of the home 'internet interface box'

and given the degree of harm that NATs have done to IPv4, I hope they
never rear their ugly heads in IPv6.

> routing architecture seems much ill-suited to the task WITHOUT

what's the point of traditional multihoming anyway if you have to
have NATs?  you might as well do IPv6-style multihoming - assign a 
separate address prefix to every incoming connection and let the
hosts sort it out.  you don't need NATs to do this.

> people position IPv6 as an alternative to NAT.

NATs can be a transition tool for connecting between IPv4 and IPv6, 
but NATs should never get in the way of a native IPv6 connection.

Keith

---

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

> this as overdesign of the home 'internet interface box'

Now that I've got a decent DSL provider, I've found that the least reliable
component of my Net access is the power line: my DSL just works, but the power
company has been flaking out 2-3 times a week for the past month or so.  (I
have my computers on UPSes, but your average K-Mart Box user wouldn't.)
Multihoming wouldn't solve that.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Using strong crypto on the Internet is like    |
[email-masked]|using an armored car to transport money from   |
|                |someone living in a tent to someone living in a|
|                |cardboard box.                                 |
\================================================================/

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 24 Apr 2000 16:31:11 -0400

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

   > this as overdesign of the home 'internet interface box'

   Now that I've got a decent DSL provider, I've found that the least
   reliable component of my Net access is the power line: my DSL just
   works, but the power company has been flaking out 2-3 times a week
   for the past month or so.  (I have my computers on UPSes, but your
   average K-Mart Box user wouldn't.)  Multihoming wouldn't solve that.

It depends on your ISP.  In the worst case some consumer grade DSL lines
are pretty bad --- 2-3 hour outages in the middle of the day (after all
no one uses the Internet during the day --- they're at work! :-),
sometimes every 3-4 days.  (I don't use this provider any more; clearly
they're using all of their money to take out full-page and half-page ads
in the Boston Globe's, and they're not spending it on upgrading their
network operations.  :-)

To make matters worse, there's a huge price differential between
"consumer grade" ISP's and "business grade" ISP's.  This kind of
situation is just ripe for arbitradge.  :-)

I can imagine some poor (but demanding) network geeks deciding that
they'll solve this problem by purchasing multiple cheap consumer grade
ISP's (say a cable modem and a ADSL line), and then set up tunnels to
some place where they can get address space.  If you can assume that
only one of your consomer grade pipes will crap out at a time, they can
switch the tunnel endpoint to the other grade of service, and keep
working with the same IP addresses, even though one of their lines has
stopped working.  (This is also useful because the cheap consumer grade
ISP's generally won't give you a large address block, even without the
dual redundancy --- and two cheap consumer grade network services is
probably far cheaper than a single business grade ISP monthly fee.)

Right now, getting address space via tunnelling usually requires knowing
someone with connections at some institution with a fast connection to
the internet and a large amount of available address space.  But I
suspect there may be a huge business opportunity here, especially if the
the some price differential between various grades of service continues.

						- Ted

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 25 Apr 2000 07:32:33 +0859 ()

Sean;

> No, not "or whatever" but "AND whatever".

Do you mean "plug THEM in to your phone line and whatever"?

> Otherwise this is a nice but insufficient device, 

Otherwise the device is unnecessarily complex (which means it is
more expensive and less reliable) and, worse, is the single point
of failure.

							Masataka Ohta

---

From: Andrew Partan <[email-masked]>
Date: Mon, 24 Apr 2000 20:27:13 -0400

> addresses into various PA address ranges supplied by the multiple

Or seperate the end system identifer from the routing goop.  This
solves lots of problems (while introducing others).
	[email-masked] (Andrew Partan)

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 24 Apr 2000 20:38:28 -0400

>solves lots of problems (while introducing others).

Deja Vu.

- paul

---

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

> solves lots of problems (while introducing others).

even if you do this the end system identifier needs to be globally
scoped, and you need to be able to use the end system identifier 
from anywhere in the net, as a means to reach that end system.  

otherwise you're in about the same shape as with a NATted network.

Keith

---

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

Sean Doran <[email-masked]> writes:

> a TLA.

This is not true. IPv6's TLA scheme has as its primary goal placing an
upper bound on the number of routing prefixes that are needed in the
core. I.e., a backbone provider is only required to maintain routes
for each individual TLA in order to have reachability to ALL
destinations. Contrast that with today's IPv4 where the number of
prefixes that need to be maintained in the DFZ in order to have global
reachability is more-or-less unbounded, so some prefixes are not
reachable from everywhere.

That doesn't mean that all or even any of these routes will be
optimal. An individual provider, may, maintain longer prefixes for
selected destinations in order to provide better contectivity, say, to
those willing to pay. Thus, traditional multihoming is still quite
possible, assuming the various ISPs that need to handle the routes
agree to do so. But the goal is to make such routes exceptions that
are value-add rather than are a fundamental requirement in order to
insure global reachability for all.

Thomas

---

From: Bill Manning <[email-masked]>
Date: Tue, 25 Apr 2000 08:48:47 -0700 (PDT)

% 
% Sean Doran <[email-masked]> writes:
% 
% > Unfortunately, IPv6's current addressing architecture makes it very
% > difficult to do this sort of traditional multihoming if one is not
% > a TLA.
% 
% This is not true. IPv6's TLA scheme has as its primary goal placing an
% upper bound on the number of routing prefixes that are needed in the
% core. I.e., a backbone provider is only required to maintain routes
% for each individual TLA in order to have reachability to ALL
% destinations. Contrast that with today's IPv4 where the number of
% prefixes that need to be maintained in the DFZ in order to have global
% reachability is more-or-less unbounded, so some prefixes are not
% reachable from everywhere.
% 
% Thomas

and this is different from only carrying the 253 usable /8 prefixes in
IPv4 how? 

--bill

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 25 Apr 2000 09:19:16 -0700

Thomas,

> core.
...
> Contrast that with today's IPv4 where the number of

As you know, this is not IPv6 magic.  The underlying routing technology
between v4 and v6, namely CIDR, is identical.  The only difference is that _by
convention_, the number of routing prefixes in v6 is limited.  If we were to
create an IPv4 Internet' without the historical baggage of the existing IPv4
Internet, the same conventions could be applied.

> Thus, traditional multihoming is still quite
> agree to do so. 

I find it a bit strange that people seem to think the logic / incentives /
disincentives that drive multihoming in the v4 Internet will not apply in the
v6 Internet.

Rgds,
-drc

---

From: Steve Deering <[email-masked]>
Date: Tue, 25 Apr 2000 09:37:24 -0700

>and this is different from only carrying the 253 usable /8 prefixes in

The set of customers who have addresses under a given IPv4 /8 prefix greater
than 127 do not all aggregate into a single topological subregion (e.g., a
single ISP), and therefore more granular routes must be widely disseminated
to make those customers reachable.  That's the difference.

Steve

---

From: Bill Manning <[email-masked]>
Date: Tue, 25 Apr 2000 10:22:42 -0700 (PDT)

% 
% At 8:48 AM -0700 4/25/00, Bill Manning wrote:
% >and this is different from only carrying the 253 usable /8 prefixes in
% >IPv4 how? 
% 
% The set of customers who have addresses under a given IPv4 /8 prefix greater
% than 127 do not all aggregate into a single topological subregion (e.g., a
% single ISP), and therefore more granular routes must be widely disseminated
% to make those customers reachable.  That's the difference.
% 
% Steve

Given the nature of trans-oceanic b/w vs. local b/w arguments I've heard
over the years, I'd say that these delegations are esentially constrained
to topological subregions and that for the most part, having the largest
incumbent ISPs in each region announce the respective /8 would roughly 
meet the IPv6, heirarchical aggregation argument.

133.0.0.0/8 - Japan
193/8           RIPE NCC - Europe                       May 93
194/8           RIPE NCC - Europe                       May 93
195/8           RIPE NCC - Europe                       May 93
199/8           ARIN - North America                    May 93
200/8           ARIN - Central and South America        May 93
201/8           Reserved - Central and South America    May 93
202/8           APNIC - Pacific Rim                     May 93
203/8           APNIC - Pacific Rim                     May 93
204/8           ARIN - North America                    Mar 94
205/8           ARIN - North America                    Mar 94
206/8           ARIN - North America                    Apr 95
207/8           ARIN - North America                    Nov 95
208/8           ARIN - North America                    Apr 96
209/8           ARIN - North America                    Jun 96
210/8           APNIC - Pacific Rim                     Jun 96
211/8           APNIC - Pacific Rim                     Jun 96
212/8           RIPE NCC - Europe                       Oct 97
213/8           RIPE NCC - Europe                       Mar 99
214/8           US-DOD                                  Mar 98
215/8           US-DOD                                  Mar 98
216/8           ARIN - North America                    Apr 98

-- 
--bill

---

From: Steve Deering <[email-masked]>
Date: Tue, 25 Apr 2000 10:58:59 -0700

>meet the IPv6, heirarchical aggregation argument.

A few counter-points:

	- As you know, I am a fan of geographic addressing (to provide a
	  real, scalable, user-friendly  solution to most of the multihoming
	  and renumbering problems), but as you also know, proposals to do
	  any sort of geographic routing have usually been met with
	  hostility and derision from the ISP community and others, because
	  of the topological constraints and interchange requirements it
	  would impose on the ISPs.  I welcome you to try, but don't get
	  your hopes up.

	- Are there not a large number of Class B addresses (and Class C
	  addresses, but maybe those have all been filtered out by now)
	  that were assigned before the registries were established, and
	  thus not aggregatable under the registry allocation prefixes?

	- Why are we talking about this?  Yes, you could adopt the same
	  or a similar address allocation/aggregation policy in IPv4 as
	  has been specified for IPv6, if you were starting all over again
	  with IPv4.  But so what?

Steve

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 25 Apr 2000 11:00:51 -0700

> to make those customers reachable.  That's the difference.

No.  This is a historical feature that IPv6 alleviates by being able to start
over with a clean slate.  You could (at least theoretically) emulate this in
v4.

The difference is that v6 gives you the option of significantly more TLAs than
v4 can ever have.  Of course, this isn't really a feature.

Rgds,
-drc

---

From: Bill Manning <[email-masked]>
Date: Tue, 25 Apr 2000 11:16:56 -0700 (PDT)

% 
% At 10:22 AM -0700 4/25/00, Bill Manning wrote:
% >Given the nature of trans-oceanic b/w vs. local b/w arguments I've heard
% >over the years, I'd say that these delegations are esentially constrained
% >to topological subregions and that for the most part, having the largest
% >incumbent ISPs in each region announce the respective /8 would roughly 
% >meet the IPv6, heirarchical aggregation argument.
% 
% A few counter-points:
% 
% 	- As you know, I am a fan of geographic addressing (to provide a
% 	  real, scalable, user-friendly  solution to most of the multihoming
% 	  and renumbering problems), but as you also know, proposals to do
% 	  any sort of geographic routing have usually been met with
% 	  hostility and derision from the ISP community and others, because
% 	  of the topological constraints and interchange requirements it
% 	  would impose on the ISPs.  I welcome you to try, but don't get
% 	  your hopes up.

	And why do you think that the ISP community and others will not
	meet the IPv6 routing proposal with anything less than the
	"hostility and derision" that came from the previous attempts
	to impose "topological constraints and interchange requirements"
	on them?

% 	- Are there not a large number of Class B addresses (and Class C
% 	  addresses, but maybe those have all been filtered out by now)
% 	  that were assigned before the registries were established, and
% 	  thus not aggregatable under the registry allocation prefixes?

	Yup, a bunch.

% 	- Why are we talking about this?  Yes, you could adopt the same
% 	  or a similar address allocation/aggregation policy in IPv4 as
% 	  has been specified for IPv6, if you were starting all over again
% 	  with IPv4.  But so what?

	Well, for two reasons:  a) IPv4 address delegation policy, since
	about 1996 has been done at a gross level, on continental bounds
	(e.g. the RIR model) so there is a rough alignment with the proposed
	IPv6 plan, at least as far as "modern" delegations are concerned.
	This is something that could be exploited for testing to see if the
	IPv6 delegation/aggregation plan is actually going to fly.
	b) We have IPv4 addresses as legacy environments that -RIGHT NOW-
	are showing problems with computing/maintaining state in a dynamic
	world. If we can "prove" the solution in the IPv4 world, then that
	would remove much of the "hostility & derision" when moving on to
	IPv6.  

	Two thoughts from here... :)

% 
% Steve
% 
% 

-- 
--bill

---

From: Steve Deering <[email-masked]>
Date: Tue, 25 Apr 2000 11:52:42 -0700

>	to impose "topological constraints and interchange requirements"

I was talking about the requirements of geographic addressing and routing.
The IPv6 addressing and routing plan does not impose those requirements.
Rather, the IPv6 addressing and routing plan is just the CIDR plan that
is being used today by that community for IPv4, with some policy proposals
to attempt to limit the number of prefixes that must be globally advertised,
something that many in that community have said over and over again is of
vital importance.

(Of course, some will respond with hostility and derision to any plan,
even if it's exactly what they would argue for, if it comes in IPv6
clothing.)

>% 	  thus not aggregatable under the registry allocation prefixes?

OK, so because of that, just changing the IPv4 Internet today to advertise
only /8s globally would not be functionally equivalent to just advertising
IPv6 TLAs, which was your original question.

>	IPv6 delegation/aggregation plan is actually going to fly.

Huh?  We have been "testing" that for some years in the IPv4 world, and
we have adopted it for IPv6.  What further testing do you have in mind,
and in what salient way do you think the IPv6 delegation/aggregation plan
is different?

>	would remove much of the "hostility & derision" when moving on to

Huh?  You want to stop routing to IPv4 prefixes that don't aggregate under
/8s in order to "prove" that we shouldn't allocate such prefixes in IPv6???

Steve

---

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

>  insure global reachability for all.

Sean said that traditional multihoming would be "very difficult".

You replied that "This is not true" (which I take to mean
that multihoming is not very difficult), and then go on to describe
something that sounds very difficult to me (maintain longer prefixes,
make multihomed customers pay for it, get the ISPs to agree to
handle such longer prefixes).  You say that "multihoming is still
quite posible", but nobody said that it was impossible, just
difficult.  For me, your statement certainly reinforces the idea
that multihoming in IPv6 is indeed very difficult.

I read your statement as follows:

    IPv6 does not solve the multihoming problem.  Instead, it tries
    to minimize the damage by:
    
    1. discouraging the use of multihoming, primarily may making
    multihomed customers pay more for it.
    2. forcing paths to multihomed sites to be less efficient (at
    least for all but one of the ISP connection points) and or,
    3. limiting the regions of the internet for which multihoming
    is effective for a given customer.

Is this an accurate representation?

PF

---

From: John Stracke <[email-masked]>
Date: Tue, 25 Apr 2000 18:41:56 -0400

Paul Francis wrote:

> handle such longer prefixes).

But these are the same problems that you have with multihoming in IPv4.  So
the assertion is that IPv6 doesn't make it any worse, and tries to make it
less necessary.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |"Fate just isn't what it used to be." --Hobbes|
[email-masked]|                                              |
\===============================================================/

---

From: Steve Deering <[email-masked]>
Date: Tue, 25 Apr 2000 15:54:46 -0700

At 1:11 PM -0700 4/25/00, Paul Francis wrote:
>For me, your statement certainly reinforces the idea that multihoming in
>IPv6 is indeed very difficult.

More accurately: multihoming in IP (any version) is indeed very difficult.
The problems are a fundamental consequence of having to do hierarchical
addressing and routing.  IPv6 is no worse than IPv4 in this regard, and
there are some features of IPv6 that might actually make make it better
(e.g., host support for multiple addresses on a single interface).

>Is this an accurate representation?

Not at all.  Try this:

    IPv4 has one, problematical solution to the site multihoming problem:
    advertise the site's prefix globally (or, at least, beyond more than
    a single ISP's domain).  This has obvious scaling problems as a
    solution to multihoming a very large number of sites (e.g., millions
    of households, as in Sean's example).

    People have accused IPv6 of lacking that one (non-scalable) solution
    to multihoming, based on a misunderstanding of the IPv6 address
    architecture.  That accusation is false, and nothing in IPv6 prevents
    the use of the same, lousy multihoming solution we have today for IPv4.

    IPv6 includes support for *additional* potential solutions to multihoming
    in which, rather than a site having a single prefix advertised globally,
    the site has multiple, aggregatable prefixes, and something more
    intelligent is done in the site's border routers and/or the the end
    hosts.  This is work-in-progress, and is likely to produce solutions
    with a different (but, we hope, acceptable in many contexts) set of
    shortcomings.

Steve

---

From: Steve Deering <[email-masked]>
Date: Tue, 25 Apr 2000 20:45:07 -0700

>over with a clean slate.  You could (at least theoretically) emulate this in

Of course.  I interpreted Bill's question as how would this be different
than limiting IPv4 prefix advertisements to only /8s *today*, i.e., without
renumbering the IPv4 Internet, so I answered accordingly.  I didn't think
to interpret the question the way you did, because the answer is so obvious
it wouldn't have made sense to ask.

>v4 can ever have.  Of course, this isn't really a feature.

Right.  IPv4 could in theory have 2^32 TLAs and IPv6 could in theory have
2^128 TLAs.  Are you saying that 2^32 TLAs would be OK?

Sheesh -- we get flamed for trying to impose a limit on the number of TLAs
and we get flamed for the possibility that the number TLAs might not be
limited...

Steve

---

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

> Sean said that traditional multihoming would be "very difficult".

Actually, Sean's statement was that  "IPv6's current addressing
architecture" makes multihoming very difficult, and that is the point
that is untrue.

> handle such longer prefixes).

This is exactly what we have in IPv4 today, except that multihomed
customers aren't really paying. And maybe they won't pay in IPv6
either. The market can sort that out. The point of the IPv6 addressing
architecture is to make that sort of multihoming a _possibility_ and
an _optimization_ rather than a _requirement_. In contrast, today's
IPv4 has lots of long prefixes in the DFZ with no clear way of placing
an upper bound on the number of prefixes that must be maintained in
the DFZ to provide reachability to all sites. In IPv6, the small
number (8K's worth) of TLAs should do the trick. That still leaves
room for many more "value-add" routes when one considers that today's
IPv4 already can/must handle 75K worth of prefixes in the DFZ. The
difference is in IPv4 it is a requirement to maintain all 75K+ routes
in order to just get reachability.

> You say that "multihoming is still quite posible", but nobody said
> that it was impossible, just difficult.  For me, your statement
> certainly reinforces the idea that multihoming in IPv6 is indeed
> very difficult.

As others have pointed out, IPv6 is also developing a multiple
addresses per end-node approach to multihoming. This approach appears
to be more scalable that the current IPv4 solution. Indeed, people
seem to point to multihoming as one of the biggest threats to
continued scaling of the IPv4 routing infrastructure. So one of IPv6's
multihoming approaches is no worse than IPv4, while another appears to
be significantly better. So once again (in contrast to assertions made
by some), IPv6 *does* have some features that should make IPv6 routing
scale better than it does in IPv4.

> Is this an accurate representation?

Absolutely not, as I hope has now been made clear.

Thomas

---

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

>  the use of the same, lousy multihoming solution we have today for IPv4.

Just for the record, I was *not* suggesting that IPv4 solves the
multihoming problem (I said nothing about it one way or the other).
I understand that internet-wide advertising of multiple prefixes
for multihomed sites does not scale, and so does not constitute a
solution.  (I would not use the word "solution" to describe IPv4's
defacto approach to multihoming.)

>  with a different (but, we hope, acceptable in many contexts) set of

Ok, so I think we may be in factual agreement if not in agreement
on emphasis or tone.  So, let me repeat my representation here and
ask you if the (hopefully acceptable) shortcomings would likely

>    is effective for a given customer.

Keep in mind that these three characteristics are gleaned (and then
negatively spun) directly from what Thomas wrote.  The negative spin
was a reaction to what I percieved as a misrepresentation of the
difficulties by Thomas.

Alternatively, maybe you could just point me to the work-in-progress
you refer to (even if it is in the form of IPv6 mailing list archives).
(I'm aware of the IDs on router renumbering, DNS suffix changing, and
the one about using mobility mechanisms for dealing with multihoming.)

PF

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 26 Apr 2000 14:42:30 -0700

Steve,

> I interpreted Bill's question as how would this be different

Perhaps it is obvious to you, however it has been implied that one of the
advantages of v6 is that it has a limited number of TLAs which would be found
the the DFZ of the v6 Internet.  My point was that this is not an advantage of
v6 but rather an advantage of starting fresh and that the limitations on TLAs
is not an artifact of the v6 protocol, but rather an administrative limit
established by policy -- something quite malleable over time (perhaps more so
now given the creation of ICANN).

> IPv4 could in theory have 2^32 TLAs and IPv6 could in theory have

No more than I would assume you'd say 2^128 TLAs would be OK.
 
Rgds,
-drc

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Apr 2000 21:30:48 -0400

> So one of IPv6's multihoming approaches is no worse than IPv4, 
> while another appears to be significantly better. 

...in terms of its impact on the routing system.  it's not clear
that having multiple addresses per host is significantly better
for applications in general.

my guess is that some applications will do well with multiple-address
style multihoming, while others will not.

but even if multiple-address style multihoming isn't a suitable 
replacement for all applications of single-address multihoming,
it's still nice to have as an option.

Keith

---

From: Steve Deering <[email-masked]>
Date: Wed, 26 Apr 2000 19:16:01 -0700

At 2:42 PM -0700 4/26/00, David R. Conrad wrote:
>the the DFZ of the v6 Internet.

The truth is subtly different than what what was implied or thought to be
implied, as I have tried to explain (with limited success, obviously), but
that's beside the point of your message:

>My point was that this is not an advantage of v6 but rather an advantage
>of starting fresh and that the limitations on TLAs is not an artifact of
>the v6 protocol, but rather an administrative limit established by policy

Yes, that's right.  If I understand correctly, you are upset by the
imprecise shorthand of saying "this is an advantage of IPv6 over IPv4"
and would prefer that we were careful always to say "this is an advantage
of the IPv6 addressing plan over the addressing plan of the existing IPv4
Internet, an advantage of starting fresh".  Fair enough.

Or are you asking us not to mention it at all, perhaps because there is
a plan to undertake a major renumbering of the IPv4 Internet so that
there will be a similarly small limit on the number of globally-advertised
IPv4 prefixes required to ensure reachability of all IPv4 customers?

>-- something quite malleable over time (perhaps more so

In what way do you think the creation of ICANN might have made it easy or
easier to impose address changes on IPv4 customers?

>No more than I would assume you'd say 2^128 TLAs would be OK.

So you agree there is a need to limit the number of TLAs to a number less
than that permitted by the address size, even for IPv4.  The longer address
of IPv6 does not introduce a new problem in this regard, contrary to what
you seemed to imply -- whatever method or policy you would use to limit
the number of TLAs in IPv4 could just as well be used in IPv6.  Or do you,
perhaps, think we really ought to be moving to a version of IP with 16-bit
addresses, to avoid the risk of creating too many TLAs?  :-)

Steve