Subject: RE: Proposal for site-local clean-up

From: "Bound, Jim" <[email-masked]>
Date: Tue, 12 Nov 2002 10:28:40 -0500

I also totally agree.

/jim
[In matters of style, swim with the currents....in matters of principle,
stand like a rock.  - Thomas Jefferson]

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Tuesday, November 12, 2002 9:31 AM
> To: Brian Haberman
> Cc: Margaret Wasserman; Brian E Carpenter; [email-masked]
> Subject: Re: Proposal for site-local clean-up
> 
> 
> On Tue, 12 Nov 2002, Brian Haberman wrote:
> > Margaret Wasserman wrote:
> > > 
> > >>
> > >> Current text:
> > > 
> > > 
> > > Hi Brian,
> > > 
> > >> >    Site-local addresses are designed to be used for addressing
> > >> inside of
> > >> >    a site without the need for a global prefix.  
> Although a subnet ID
> > >> >    may be up to 54-bits long, it is expected that 
> globally-connected
> > >> >    sites will use the same subnet IDs for site-local and global
> > >> >    prefixes.
> > >>
> > >> Proposed new text:
> > >>
> > >>    Site-local addresses are designed to be used for 
> addressing inside of
> > >>    a site which is not connected to the Internet and 
> therefore does not
> > >>    need a global prefix.  They must not be used for a 
> site that is
> > >> connected
> > >>    to the Internet. Using site-local addresses, a subnet 
> ID may be up to
> > >>    54-bits long, but it is recommended to use at most 
> 16-bit subnet IDs,
> > >>    for convenience if the site is later connected to the 
> Internet using a
> > >>    global prefix.
> > > 
> > > 
> > > I would support this change.  However, I doubt that we will get 
> > > consensus to make this change before the addressing 
> architecture is 
> > > issued as an RFC.  I guess we'll see how things develop 
> in Atlanta.
> > > 
> > >> Alternatively, we could spend the next 5 years discussing the 
> > >> unnecessary complexities of using site-locals on connected sites.
> > > 
> > > 
> > > This is _exactly_ what I am hoping to avoid.
> > > 
> > > Let's limit site-locals to the well-understood case, and focus on 
> > > solving the real problems:
> > > 
> > >         - Getting IPv6 finalized and ready for wide-scale 
> deployment
> > >         - Multi-homing
> > >         - Renumbering
> > >         - Security model for shared IPv4/IPv6 networks
> > 
> > I agree with Brian and Margaret.
> 
> Also totally agree.
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Nov 2002 15:41:05 -0800

> Unfortunately it's too late to catch the addressing architecture
> document unless we recall it from the RFC Editor and cycle it
> through the IESG again. But I propose that we do exactly that,
> in order to change the following paragraph in section 2.5.6:
> 
> Current text:
> 
>> Site-local addresses are designed to be used for addressing inside of
>> a site without the need for a global prefix.  Although a subnet ID
>> may be up to 54-bits long, it is expected that globally-connected
> Site-local addresses are designed to be used for addressing inside of
> a site which is not connected to the Internet and therefore does not
> need a global prefix.  They must not be used for a site that is connected
> to the Internet. Using site-local addresses, a subnet ID may be up to
> 54-bits long, but it is recommended to use at most 16-bit subnet IDs,
> for convenience if the site is later connected to the Internet using a
> global prefix.
> 
> Otherwise, we will need a whole new RFC just for this paragraph.
> 

i will not make sarcastic remarks.  i will not make sarcastic
remarks.  i will not make sarcastic remarks.  i will not make
sarcastic remarks.  i will not make sarcastic remarks.  i will not
make sarcastic remarks.  i will not make sarcastic remarks. :-)

if there is real consensus on this, processwise it could be done
with a note to the rfc editor or in the 48 hour edit call as s/he
is doing the final edits.

randy

---

From: "NOISETTE Yoann FTRD/DMI/CAE" <[email-masked]>
Date: Thu, 14 Nov 2002 10:09:54 +0100

Alain,

How could we use "well-know global-adresses" in this aim ?
Indeed, as I understand the draft, the site-local addresses pointed out
in paragraph 7 are reserved for this, and will be the same wherever this
mechanism will be deployed... How can global addresses provide the same
service ??
Did I miss something ?

Yoann

-----Message d'origine-----
De : Alain Durand [mailto:[email-masked]]
Envoye : mercredi 13 novembre 2002 19:57
A : NOISETTE Yoann FTRD/DMI/CAE
Cc : [email-masked]
Objet : Re: Proposal for site-local clean-up

NOISETTE Yoann FTRD/DMI/CAE wrote:

>Hi all,
>
>I would possibly agree with this change, but it must be clear that some
>ongoing work or considered solutions will be restricted or even totally
>impossible after this new statement becomes effective.
>For instance, draft-ietf-ipv6-dns-discovery-07.txt gives many examples
>of a Customer site, using site-local addresses (in particular for DNS
>discovery), and this Customer site is connected to an ISP (thus
>certainly I presume to the Internet)...
>
That document could be changed to use global addresses instead of site
local
if Brian's proposal gets adopted.

- Alain.

---

From: "Richard Draves" <[email-masked]>
Date: Tue, 19 Nov 2002 11:43:13 -0800

> I think, but I'm not certain, that most of the large sites 
> that do this have completely different DNS content in the 
> two-faces i.e. it is more like two separate DNS services than 
> two-faces of the same DNS database. That is, the DNS outside 
> the firewall contain a subset of the RRs and 
> names, and there isn't necessarily a dynamic update path 
> between the two DNSes.
> 
> Do you have examples of folks that have small setups of 
> two-faced DNS where e.g. dynamic DNS update works while still 
> keeping site-locals on the inside and global addresses 
> visible through both faces?

This is a good point. I think you are right - usually the internal &
external DNS services have separate databases. My expectation is that
when the internal DNS service resolves a name to an RR set that includes
site-local addresses, then the external DNS service fails to resolve the
name. This reduces the chance for confusion if you query the "wrong" DNS
service or query them in the wrong order.

Rich

---

From: "Brian Zill" <[email-masked]>
Date: Tue, 19 Nov 2002 14:50:20 -0800

Hi Jim,

> > There needs to be a way to get an address when you don't
> > have a provider. This means either scoped addresses as we
> > have defined them already (and in multi-link locations, this 
> > means either site-local or multi-link subnet routers and 
> > link-local), or some sort of provider-independent address 
> > (note there are various types of these as well, depending 
> > upon whether we believe they should be explicitly 
> > non-routable, or privately routable between multiple 
> > non-connected 'sites').
> 
> I cannot see anyway to route site-locals across multiple 
> sites?  Your not saying to do this are you?

No, I'm not.  Site-locals should not be routed across sites.  I was
addressing the suggestion others have made which was to use some sort of
yet-to-be-defined provider-independent addresses instead of site-locals
in some situations.  My point on that topic is that there are a range of
different properties such addresses could have (one of which is that
they may or may not be routable across sites).  I believe at least some
of the arguments people were having were the result of different
unstated assumptions about what the properties of such addresses would
be. 

> Part of the issue for all this mail is not to kill SLs but
> to make sure we understand them and how to use them and how
> to manage them and what their affect to users will be.

That would be my preference as well.

--Brian

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 19 Nov 2002 20:08:44 -0500

Hi Brian,

ACK.  I get it now and agree with your point. thanks

/jim
[Honor, Commitment, Integrity]

> From: Brian Zill [mailto:[email-masked]] 
> Sent: Tuesday, November 19, 2002 5:50 PM
> To: Bound, Jim; [email-masked]
> Subject: RE: Proposal for site-local clean-up 
> 
> 
> Hi Jim,
> 
> > > There needs to be a way to get an address when you don't have a 
> > > provider. This means either scoped addresses as we have 
> defined them 
> > > already (and in multi-link locations, this means either 
> site-local 
> > > or multi-link subnet routers and link-local), or some sort of 
> > > provider-independent address (note there are various 
> types of these 
> > > as well, depending upon whether we believe they should be 
> explicitly
> No, I'm not.  Site-locals should not be routed across sites.  
> I was addressing the suggestion others have made which was to 
> use some sort of yet-to-be-defined provider-independent 
> addresses instead of site-locals in some situations.  My 
> point on that topic is that there are a range of different 
> properties such addresses could have (one of which is that 
> they may or may not be routable across sites).  I believe at 
> least some of the arguments people were having were the 
> result of different unstated assumptions about what the 
> properties of such addresses would be. 
> 
> to manage 
> > them and what their affect to users will be.
>

---

From: "Michel Py" <[email-masked]>
Date: Thu, 21 Nov 2002 09:04:43 -0800

Erik,

>> Michel Py wrote:
>> Where does this come from? There is nothing in Richard's
>> text that implies anything about the ISPs _using_ site
>> locals. It talks about _filtering_ them.

> Erik Nordmark wrote:
> Sorry, I meant to say "using them by configuring site
> boundaries" but I agree that it is sufficient to filter
> them.

In other words: put them in the bogon list. Which they already should be
doing, so what is the issue here? There is no automatic relation between
the site boundary and the address range.

Michel.

---

From: Dan Lanciani <[email-masked]>
Date: Thu, 21 Nov 2002 15:07:01 -0500 (EST)

Tim Chown <[email-masked]> wrote:

|On Mon, Nov 18, 2002 at 10:49:42PM -0500, Dan Lanciani wrote:
|> 
|> We have always been told that stable global v6 addresses will not be available
|> to end users, or at least will not be available to end users at a low cost.
|
|Told by who?

Folks on this list every time provider-independent global addresses or stable
identifiers are brought up...

|I can see ISPs wanting to charge for extra services where they
|can, and thus for a static /48 as they do now for a static single IPv4
|address.  But I would hope that enough ISPs would offer free static /48's
|to take custom from those who charge.

Given that this is not happening now for single static v4 addresses, your
analogy would seen to suggest the opposite.

|The only "snag" is that such ISPs
|with 10M customers would need a lot more than a /32, esp. taking into
|account the HD-ratio.

This isn't just a "snag."  The hierarchical addressing architecture consumes
address space exponential in the number of providers in the chain.  This makes
it very difficult to break away from the limited business models currently
contemplated.  In order to be the kind of provider you suggest the ISP probably
has to move "up" a level in the chain.  Suddenly that huge address space is
looking a lot smaller...

Erik Nordmark <[email-masked]> wrote:

|If the ISP provide the disservice of unstable IP addresses I think we have
|a large class of problems. The fact that site-local addresses might ameliorate
|some of those problems doesn't magically make such ISP disservice useful.

No, but the existence of an alternative may help to avoid the disservice in
the first place.  By taking away the alternative you give the ISPs a huge
lever to charge whatever the market will bear, at least until NAT is available.
By reducing the need for (and thus the perceived value of) stable addresses
you may be able to reduce their cost.

Keith Moore <[email-masked]> wrote:

|> We have always been told that stable global v6 addresses will not be available
|> to end users, or at least will not be available to end users at a low cost.
|
|I think this depends on what you mean by "stable".  For some reason the
|community has been reluctant to specify a number here, and the result
|is that people have widely varying ideas about what we can expect in practice.

The community has been reluctant to specify a number because it isn't clear
that stability is other than a binary attribute.  The worst part of keeping this
whole stability issue in limbo is that it's always possible to argue that things
will be "stable enough" that we don't have to solve the renumbering problem.
This in turn means that lack of stability will always be an encumbrance and
thus stability will command a premium.

|I don't think we want to let the reliable operation of applications be
|an accident, nor do I think we want to trust market forces to sort this
|out. 

I agree.  This is exactly why we desperately need scoped addressing or a
comparable mechanism that allows users to control the stability of their
networks.

|> Unless you are proposing to revise the whole address allocation architecture
|> *and* have a way to force ISPs to change their business models I think we must
|> accept this as a given.
|
|I don't think it's necessary to "force" anything, and casting things in these
|terms makes them seem more difficult than they really are.

I am merely observing current business practices and projecting a reasonable
continuation of those practices.  You on the other hand keep implying that
there will be a significant change in the business models, but you decline to
provide any plausible justification for your expectations.  Repeatedly asserting
that everything is going to be copacetic will not make it so.

|> I think you have made an unreasonable leap by dropping the "stable" qualifier.
|> The value/importance of _stable_ local communication is almost certainly much
|> higher than the value/importance of _stable_ global communication.  
|
|No.  You erroneously assume that different applications are used for local
|and global communications,

No.  The assumption is that people have different expectations and needs for
local versus global connectivity.  This is not my assumption but the assumption
of the v6 addressing architecture.  This assumption, while aesthetically
unappealing, is clearly correct for many users.  This assumption is behind the
compromise of giving up portable globals in exchange for a local solution that
is better integrated than NAT.

|and you are over-generalizing the case for 
|stable global communications from two very specific cases.  Too many people
|think that the Internet only needs to support web and email.  If that were
|the case we wouldn't need IPv6 at all.  
|
|The 'local' versus 'global' distinction is a false one.

These would be great points if you were arguing for (and I were arguing
against) a return to user-owned portable global/stable addresses.  But I've
never seen you arguing for such a return while I in fact have tried to make
the case for portable globals.  The v6 addressing architecture has already
taken away the ability to have stable global addressing without the (presumably
paid) cooperation of your ISP.  You are not proposing to fix this.  You are
proposing to also take away the ability to have stable local addressing.  Your
argument that we should give up stable local communication because it would be
nice if global communication were stable is specious.

If you would like to campaign for a return to user-owned global/routable/stable
addresses I'll support you 100%.  If that battle were won, the need for scoped
addressing would be significantly reduced.  But win that battle before you try
to take away stable locals.

|I run NFS over TCP 
|over IPv6 over long distances, and it works.

I ran RVD over the ARPANet before NFS ever existed.  Unfortunately, we are
in the minority of users.  The v6 architecture was designed to mimic (perhaps
even to the point of caricature) what the v4 internet has become: predominantly
a big cloud of ephemeral, dynamically-addressed clients talking to a smaller
cloud of static servers.  The v6 address architecture does not lend itself to
the peer-to-peer applications that were possible in the flat, pre-aggregation
v4 internet.  That doesn't mean that there won't be peer-to-peer applications
in v6, but they will end up using the same kinds of kludgy rendezvous protocols
that dynamically addressed v4 nodes now use.

|And yes, I'm screwed if 
|my ISP changes my IP address (fortunately they have agreed to not do that).  
|I also regularly send print jobs over the same connection.

I'm happy for you if you have a relationship with an ISP that will allow you
to keep stable address space when/if v6 gets beyond its experimental stage.
But don't you think you are being a bit shortsighted to try to take away the
only kinds of stable addresses that will be available to people who do not have
such relationships?

|> |In any case, for a home user I suspect that the value/importance of
|> |local communication would typically be less than the value/importance
|> |of global communication.
|> 
|> Again assuming we are talking about _stable_ communication, I believe that 
|> you are incorrect.  Granted those of us who depend on our home networks for
|> automation and such are currently on the bleeding edge, but what about the
|> future when every stereo and tv is on the net?  It's one thing to have to
|> re-click that remote link in the browser, but quite another to have your
|> stereo refuse to change channels.  Consumers are not going to pay their ISP
|> a premium to keep their stereos working.  I know it sounds nice in theory,
|> but look what happened to Divx.  If you take away scoped addressing we _will_
|> use NAT.
|
|Threatening to destroy the utility of IPv6 if you don't get your way 
|won't get you much support here.  Perhaps you should take another tack.

So in other words you don't have a solution for the problem without using
NAT or site locals?

|I don't understand why you expect that ISPs will treat v6 exactly the
|same as v4,

I've explained this several times already, but I'll explain it again.  ISPs
use addresses as a surrogate measure of bandwidth.  They use the number of
addresses to control the number of machines using bandwidth.  They use the
(lack of) stability of addresses to control server usage because servers are
perceived to consume more bandwidth (and in any case are a "premium" usage).
Nothing in the change from v4 to v6 in any way affects these considerations.

Now, as I've asked several times before, can you please explain why you think
things will change?

|when if they do it this way there is no reason for their 
|customers to pay for this additional service.

Are you talking about v6 as an additional service over v4 or about stable
addresses as an additional service?  If the latter then the answer is that
they will pay for the same reason they pay now plus (if you have you way)
they will pay to keep their stereo and tv going smoothly right up until
v6 NAT is implemented in all the consumer/retail router appliances.  If
the former then I think the answer is that most typical end users will not
seek out v6 as an additional service at all since it offers virtually no
benefit to the them while provoking significant upgrade costs.  They may
be forced to accept v6 first by claims that there are no more v4 addresses
and (much) later by owning widgets that use v6 exclusively.

In any case, I thought you said above that you did want to trust market forces
to sort things out.  You seem to now be falling back on an (IMHO) extremely
naive analysis of how market forces will sort things out...

|perhaps ISPs will charge 
|more for v6 than for v4, and they'l claim that they're doing so because 
|v6 addresses are stable.   

Perhaps.  I'm not sure what difference it makes.

|> Depriving users of the tools necessary to make productive use
|> of their networks without paying for stable globals for all internal nodes
|> will just encourage yet another round of kludges.
|
|Bottom line is that we need addresses to be (reasonably) stable at both
|the local and the global level.

We would like global addresses to be stable, but clearly we have a current
existence proof that we do not need this.  The world is getting on just fine
with unstable v4 addresses for lowly end users.  Even if we did need stable
global addresses the _need_ for stable global addresses would not obviate the
need for stable local addresses.  Perhaps the ready _availability_ of stable
global addresses would obviate the need for separate stable local addresses
(or perhaps not) but we are a far cry from being able to guarantee such
availability.

|It's not sufficient to just have stable
|local addresses

It may not be sufficient to have stable locals, but clearly it is necessary.

|- especially given the problems that SLs cause. 

The difficulty of implementing a solution has nothing to do with its
sufficiency.

Erik Nordmark <[email-masked]> wrote:

|Sorry for the delayed response - didn't see me in the to: or cc: fields.

I try to keep all the mail to the list just to the list...

|> |In terms of the stability of the addresses one has to take into account
|> |both stability as it relates to local communication and stability for
|> |global communication.
|> 
|> We have always been told that stable global v6 addresses will not be
|> available to end users, or at least will not be available to end users at a
|> low cost. Unless you are proposing to revise the whole address allocation
|> architecture *and* have a way to force ISPs to change their business models
|> I think we must accept this as a given.
|
|The temporal stability of addresses have a temporary component - it isn't
|black and white.

That is at best unclear.  Ultimately I think many users will find that
stability is a binary property.  Either some outside party can change the
address out from under you or they can't.

|Crystal ball:
|I wouldn't be surprised if small sites renumber the IPv6 addresses once
|a year with an overlap (both new and old working for a week perhaps). 

How much will I have to pay to get this "small site" level of service
for my home?

|I see no reason why one would ever want to change them once a day.

Obviously there is no reason for a user to want to do this, but ISPs certainly
have reasons.

|Taking together globally things means that there will be lots of renumbering
|in progress at any given time (given millions of sites and a reasonably long
|overlap).

I agree that there will be lots of renumbering going on.

|Thus I'm not too worried about e.g. my home site changing IPv6 prefixes
|all the time.

I am worried.

| Of course, there is a concern for applications which keep
|a connection open for a long time (weeks),

My distributed home automation system's processes keep their connections open
constantly from the point where they are started in /etc/rc to the point where
the system(s) crash.  My systems have reached uptimes of over a year.  I have
big batteries on my UPS's and a backup generator for when they start to get low.

|but I suspect that such applications
|are, or need to be, capable of reconnecting since they need to be able to deal
|with peer failure.

My applications are fully capable of reconnecting in any sequence after any
machine or process dies for whatever reason.  But that is completely different
from being able to reconnect after addresses have changed.

|> I think you have made an unreasonable leap by dropping the "stable"
|> qualifier. The value/importance of _stable_ local communication is almost
|> certainly much higher than the value/importance of _stable_ global
|> communication.  
|
|Even with the "stable" qualifier my opinion is the same. 
|You are welcome to disagree.

I do disagree, but I get the feeling that it doesn't matter much.

|> But my NFS client is simply not prepared to have its server's
|> address renumbered out from under it. My multi-hour build will fail unless
|> I notice the problem and fire up adb on the kernel in a hurry.  Similarly my
|> print job will fail if the printer and/or client is/are renumbered in the
|> middle of a tcp session. 
|
|You seem to be assuming flash renumbering without overlap.

Yes, that is the only reasonable assumption to make.  Just as ISPs now use
short DHCP leases and related dynamic adderssing techniques to discourage
what they perceive as "bandwidth hungry server activity" they will use frequent
renumbering to achieve the same goals.  Without site locals they will have the
added advantage of being able to disrupt not only your "server's" accessibility
from the internet, but your stereo and your tv as well.  At least they will be
able to do this until v6 NAT appears.

Please explain why you assume that ISPs will change their business models
under v6.

|> My distributed home automation system, while quite tolerant
|> of temporary lost connections and machine reboots, can not deal with
|> addresses changing out from under it.  This is hardly unreasonable because
|> the tools to deal gracefully with such situations have not yet been
|> invented.  To make such things work now each application would have to
|> implement its own procedures to deal with unstable addresses.  This is
|> obviously not acceptable to application writers.
|
|And the tools to deal in a robust manner with multiple-scopes of addresses
|have not been applied to your home automation system either.

Sure they have.  As far as I can tell, my applications would work just fine
with site-locals and the default address selection rules.  I wouldn't even have
to play DNS games because all these applications look up their servers or peers
under a sub-domain I set up for that purpose.  All I would have to do is
populate that sub-domain with stable site-locals.

|To be it makes more sense to get applications to 
| - not cache DNS answers forever

So how long can you cache DNS answers?

| - be prepared to restart connections after redoing a DNS lookup 
|   if the connections are open for a long time (days or more).
|I think this is less work, since many applications can get away with
|doing nothing, than having all applications handle different scope addresses.

I think you are trivializing an extremely complicated process.  To make this
work well DNS has to become a fully push system and domain names have to replace
literals pretty much everywhere.  We are talking about a major paradigm shift
for applications.  This at the same time that other site-local detractors are
encouraging the use of literals in, e.g., web pages.  Can we see some commitment
from application writers that they actually plan to do as you suggest?  I don't
want to hear later that, well, this is too much to expect from applications and
you should really pay for those stable addresses.

But I begin to recognize the same argument that was used against global
identifiers.  Addresses are going to be stable *enough* and renumbering is
going to be infrequent *enough* and dynamic DNS is going to work well *enough*
and applications are going to learn to cope with dynamic addresses *enough*
and ISPs are going to become philanthropic *enough* that somehow all mixed
together things will work well *enough*.  The only difference is that the
previous argument went on, ``and if you really need local communication
stability you can always use site-local addresses.''  I'm still extremely
dubious that things will just work out.  It's getting very, very late in
the game to be deferring the solution with yet another round of buck-passing.

|> We understand that sites are administrative.
|
|Section 4 in draft-ietf-ipngwg-scoping-arch seems to say something differnet.
|A site doesn't span multiple administrations, but it is limited
|to a single geographic location, such  as an office, an office complex, or 
|a campus. 

Your implication before seemed to be that sites locals didn't make sense
because the geographic description could span administrative domains.  I
don't really follow your reasoning either way, but it doesn't matter.  My
house is a single administrative domain and a single geographic location.

|> |So let's not loose sight of the fact that the goal is a robust network.
|> 
|> I think that the goal is a useful network--useful not only for ISPs and
|> application vendors but for consumers.
|
|Agreed. I don't think I was saying anything different.

Actually, I think there is a big difference.  You can make the network very
robust and easy to maintain for ISPs while at the same time making it less
useful for consumers.  You can make the network an easier environment for
application programmers while at the same time making it less useful for
consumers.  I've noticed that the v6 design process has paid a great deal
of attention to the needs of the ISP, some attention to the needs of the
application developer, and very little attention to the needs of the end
user.  In fact, many important end-user issues have been treated as after-
thoughts or addressed only under pressure from the media (e.g., privacy
concerns over MAC IDs).  Several of the proposals for fake multi-homing
(where you pay both providers but get no benefit from the redundancy) would
have made for really funny reading were the problem not so serious.  A complete
lack of user-controlled address space is going to make v6 a very hard sell...

				Dan Lanciani
				ddl@danlan.*com