Subject: A simple question

From: "Tony Hain" <[email-masked]>
Date: Fri, 18 Apr 2003 15:12:54 -0700

Keith Moore wrote:
> It doesn't solve all problems, but introduction of 
> scoped addresses causes far more problems than it solves.

I would like to understand how many people that voted YES on the
question of deprecating SL concur with Keith's assertion.

Tony

Note: I cc'd the IETF list to catch those who may have been in the room
in SF, but aren't on the IPv6 list.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Apr 2003 16:12:16 -0700

TH> I would like to understand how many people that voted YES on the
TH> question of deprecating SL concur with Keith's assertion.

Tony,

let me turn it around:

please point us to some text that gives a clear and complete discussion
of the benefits that accrue from this new feature, as well as a fair
consideration of its difficulties.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 18 Apr 2003 16:54:43 -0700

> let me turn it around:

Not at this time. I am looking for a simple yes/no answer to a simple
question:
How many people that voted YES on the question of deprecating SL concur
with Keith's assertion.
KM> It doesn't solve all problems, but introduction of
KM> scoped addresses causes far more problems than it solves.

Tony

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Apr 2003 17:14:03 -0700

Tony,

TH> Not at this time. I am looking for a simple yes/no answer to a simple

yes, I understood your question.  the reason I posed a different
question was to seek some dialogue about content, rather than debating
process issues.

d/

---

From: Mark Prior <[email-masked]>
Date: Sat, 19 Apr 2003 20:04:51 +0930

>question was to seek some dialogue about content, rather than debating
But your question is phrased as if something was being added rather 
than removed.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Apr 2003 07:07:19 -0700

Mark,

>>question was to seek some dialogue about content, rather than debating
MP> But your question is phrased as if something was being added rather 
MP> than removed.

glad you noticed that.  it was intentional.

site local is, in fact, an addition to the IP architecture and that is
what is causing the controversy.  For example, it has prompted the
suggestion that applications be made to know the difference between site
local vs. global IP addresses.

when we go around making basic additions to an architecture, we should
try to be very clear on how it will be used, how it will impact the rest
of the architecture, and what the benefits and problems are likely to
be.

Hence my original query.

d/

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 01:32:46 +0700

Date:        Sat, 19 Apr 2003 07:07:19 -0700
    From:        Dave Crocker <[email-masked]>
    Message-ID:  <[email-masked]>

  | site local is, in fact, an addition to the IP architecture and that is
  | what is causing the controversy.

No, it isn't.   It is a cleaned up replacement for 1918 addresses.

  | when we go around making basic additions to an architecture, we should
  | try to be very clear on how it will be used, how it will impact the rest
  | of the architecture, and what the benefits and problems are likely to
  | be.

This "addition" was made years ago.   It is used now.   The only thing
being contemplated now is removing it without providing a replacement.

kre

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 15:13:29 -0400

>   | site local is, in fact, an addition to the IP architecture and
>   | that is what is causing the controversy.
> 

which by itself is reason enough to kill it.

---

From: [email-masked]
Date: Sat, 19 Apr 2003 15:23:23 -0400

> No, it isn't.   It is a cleaned up replacement for 1918 addresses.

Unbfortunately, I don't see where the biggest problems with 1918 addresses
were cleaned up for site-local.  Addresses will still leak out, and it
still has scoping problems.  You're still left wondering "Is this address
I was just handed an in-scope address from another part of my own network,
or is it a bogon I was handed by somebody else from part of THEIR net?"

The problems with 1918 space were well understood at the time:

   A major drawback to the use of private address space is that it may
   actually reduce an enterprise's flexibility to access the Internet.
   Once one commits to using a private address, one is committing to
   renumber part or all of an enterprise, should one decide to provide
   IP connectivity between that part (or all of the enterprise) and the
   Internet.  Usually the cost of renumbering can be measured by
   counting the number of hosts that have to transition from private to
   public. As was discussed earlier, however, even if a network uses
   globally unique addresses, it may still have to renumber in order to
   acquire Internet-wide IP connectivity.

   Another drawback to the use of private address space is that it may
   require renumbering when merging several private internets into a
   single private internet. If we review the examples we list in Section
   2, we note that companies tend to merge. If such companies prior to
   the merge maintained their uncoordinated internets using private
   address space, then if after the merge these private internets would
   be combined into a single private internet, some addresses within the
   combined private internet may not be unique. As a result, hosts with
   these addresses would need to be renumbered.

Unfortunately, people seem to want to forget about those two paragraphs. I'm
afraid that unless site-local includes a 'MUST renumber' requirement for *BOTH*
cases, it's a complete and total non-starter in my book.

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 03:28:54 +0700

Date:        Sat, 19 Apr 2003 15:13:29 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | > No, it isn't.   It is a cleaned up replacement for 1918 addresses.
  | which by itself is reason enough to kill it.

Nothing of the kind.   1918 addresses were created because there was
demonstrated demand for stable local use only addressing.   Nothing
has changed in the Internet to cause that demand to go away.

We either provide a mechanism, or the users provide one of their own.

kre

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 03:41:37 +0700

Date:        Sat, 19 Apr 2003 15:23:23 -0400
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | Unbfortunately, I don't see where the biggest problems with 1918 addresses
  | were cleaned up for site-local.

Two aspects.   First, they're clearly of local use (defined in the 
architecture), hence if they do leak, at least it is obvious what is
happening.

More importantly ...

  | The problems with 1918 space were well understood at the time:
  | 
  |    A major drawback to the use of private address space is that it may
  |    actually reduce an enterprise's flexibility to access the Internet.

Is not true for site locals, as no-one anticpiates that a SL address is
all an enterprise will be using (unless it is not connected to the
internet, in which case questions of its flexibility of access don't arise).

For internet access, a global address is used.   Sites (and hosts) have both.

Similarly:

  |    Once one commits to using a private address, one is committing to
  |    renumber part or all of an enterprise,

is not true of SL addresses, as one doesn't "renumber" them, one just
augments with a global address.

You may notice that it isn't *just* site locals that provide the cleanup
here, it is the whole IPv6 architecture, considered as a whole.   That
includes having multiple prefixes announced to nodes, and the ability to
seemlessly add new ones.

  |    Another drawback to the use of private address space is that it may
  |    require renumbering when merging several private internets into a
  |    single private internet.

This one was certainly true of the original site local ("may require").
(Only may because it all depends on how the merge gets done, and the
actual subnet numbers).   Now that site locals have been extended to use
fec0::/10 instead of fec0::/48 it is much less likely (but still not
impossible).

Some kind of global assignment policy for those 38 bits would fix this,
but adds the costs of managing such a scheme.

  | Unfortunately, people seem to want to forget about those two paragraphs.

No, this is exactly the kind of thing that was considered in the SL design.

  | I'm afraid that unless site-local includes a 'MUST renumber' requirement
  | for *BOTH* cases, it's a complete and total non-starter in my book.

IPv6 requires renumbering when an address that has been used is no longer
appropriate (which will generally be because of changed topology, which
may be local topology changes - moving a host to a different LAN, or global
ones - connecting to a different provider).   That is the only reason.
As long as prefixes remain usable, they can keep on being used, with other
prefixes added as required.

kre

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 16:59:21 -0400

> demonstrated demand for stable local use only addressing.  

1918 addresses were created because there was a need for isolated networks to
be able to get address space, and having them pick space at random was
believed to be problematic.

> Nothing

what has changed is that we now have experience with RFC 1918, and we know now
that it is far more of a mess than was anticipated.

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 17:27:13 -0400

>   | Unbfortunately, I don't see where the biggest problems with 1918
>   | addresses were cleaned up for site-local.
> 

right.  but the anticipated use was such that if 1918 addresses leaked, this
would be treated as an indication of an error - namely that a non-isolated
network was connected to the Internet - and that the correction would be to
renumber the formerly isolated network.  the intent of 1918 was to enable
correction of the error of giving a non-isolated network non-unique address
space, not to encourage that error to the point that it became common
practice (as has happened).

> internet, in which case questions of its flexibility of access don't arise).

on the contrary, having an enterprise use both SLs and globals creates
significant new problems of its own, and results in even less flexibility
than if SLs were used only by isolated networks.

> augments with a global address.

this is a bug, not a feature.

> includes having multiple prefixes announced to nodes, 

multiple addresses at a node were available in IPv4, but the problems
associated with doing this have never been solved, not even in IPv6.  so while
having multiple prefixes per node is clearly useful for renumbering, it's not
at all clear that this is a "cleanup" to the IP architecture.  it's more
complexity that has to be dealt with.

> fec0::/10 instead of fec0::/48 it is much less likely (but still not

depends on how subnets are allocated.  my guess is that sites are more likely
to allocate subnet bits from left to right, rather than allocating from the
right and picking the leftmost subnet bits at random - so that collisions are
still likely whenever sites merge. 

> No, this is exactly the kind of thing that was considered in the SL design.

unfortunately, many important considerations were ignored in that design.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 04:22:20 +0700

Date:        Sat, 19 Apr 2003 16:59:21 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | 1918 addresses were created because there was a need for isolated
  | networks to be able to get address space, and having them pick space
  | at random was believed to be problematic.

Yes, and nothing has changed.

If anything, the demand now is greater than it was when 1918 addresses
were first created, as addresses now are much less stable - 1918 addresses
also fill the role of stable addressing for internal site use.

  | what has changed is that we now have experience with RFC 1918, and we
  | know now that it is far more of a mess than was anticipated.

Which explains some of the cleanups.

But even ignoring that, you cannot just wish the demand away.   One way
or another, the users are going to meet their demands.   If that means
just picking space at random again, that's what they'll do (which will
likely mean that they'll need to use NAT as well, which with SL they don't).

If you (and/or the WG as a whole) can come up with a replacement that is
better than site local, and meets the objectives, that's fine.  Until then
don't destroy what we have now, which works now (as in, in in day to day use 
now).

kre

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 16:28:30 -0500

Thus spake "Keith Moore" <[email-masked]>
> > Nothing of the kind.   1918 addresses were created because there
> > was demonstrated demand for stable local use only addressing.
>
> 1918 addresses were created because there was a need for isolated
> networks to be able to get address space, and having them pick space
> at random was believed to be problematic.

Perhaps that's why we allocated those addresses, but that's not the most
common usage anymore; IP networks not connected to the Internet have become
vanishingly rare.

Today, sizeable numbers -- perhaps even the majority -- of residential
broadband and corporate users sit in RFC1918 space behind NATs.  This is not
a small mess you can wipe under the carpet and ignore.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 16:13:48 -0500

> which by itself is reason enough to kill it.

I detest NAT and private addresses nearly as much as you do, but the simple
matter is that many, if not most, people are going to continue using these
technologies with IPv6 whether the IETF standardizes it or not.

Today, NAT is a solution to political and business problems, even if IPv6
fixes the technical problems NAT was originally invented to solve.  The IETF
cannot eliminate these political and business problems by fiat, nor can it
prevent vendors from selling IPv6 NAT devices.

You are fighting the good fight, but you will surely lose nonetheless.

S

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 17:42:56 -0400

> common usage anymore; IP networks not connected to the Internet have become

so we should move 1918 to Historic.

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 17:42:21 -0400

On Sun, 20 Apr 2003 04:22:20 +0700

> Yes, and nothing has changed.

wrong.  we know now that 1918 addresses created a big mess.  and nothing about
IPv6 use of SLs reduces that mess.

> don't destroy what we have now, which works now (as in, in in day to day use

no, you have it backwards.  SLs destroy the utility of IPv6.

---

From: [email-masked]
Date: Sat, 19 Apr 2003 17:51:19 -0400

> For internet access, a global address is used.   Sites (and hosts) have both.

So if it's expected that both global and site-local addresses are available,
why are we bothering with making things more complicated?

> augments with a global address.

That's exactly *why* they're broken - if you've suddenly had a global
address show up, there's now a danger of leaking a local address, so it's
not safe to use site-local anymore.

> prefixes added as required.

Well.. all you need to do to fix this is to make a rule that if a
global prefix becomes available, the site-local prefix is no longer
appropriate and must be withdrawn.

This *still* leaves the problem of using site-local behind a NAT, though.

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 04:49:44 +0700

Date:        Sat, 19 Apr 2003 17:27:13 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | not to encourage that error to the point that it became common
  | practice (as has happened).

Usage alters to meet the demands of the users.  That's nothing new.

  | on the contrary, having an enterprise use both SLs and globals creates
  | significant new problems of its own, and results in even less flexibility
  | than if SLs were used only by isolated networks.

Nothing that IPv4 doesn't have as well (if perhaps less commonly).

  | multiple addresses at a node were available in IPv4, but the problems
  | associated with doing this have never been solved, not even in IPv6.

True.   But it is still used regardless.   There are unsolved problems
should be a challenge, not something to fear.

  | so while having multiple prefixes per node is clearly useful for
  | renumbering,

Yes - but more than that - as long as addresses reflect topology, multiple
addresses are the only way to have multiple topological attachments,
aren't they?

This is seen both in a host that is connected to two LANS, and an organisation
that has two ISPs.

So, unless there's some routing revolution, you're just going to have
to learn to deal with multiple addresses, and unless LL addresses go
away, you're also going to have to deal with scoped addresses.

  | so that collisions are still likely whenever sites merge. 

I think I'd say possible, rather than likely.   But of all the problems,
this is the one that bothers me least - sites aren't required to merge
after all (when that does get to be a requirement, it is likely that
far more significant changes are made than just "let those two sites have
unified site local addresses).   After all, you want to abolish the things
completely - if it would be acceptable to not have them (and do remember,
no organisation is going to be compelled to use them) then worrying about
how to unify if they do exist them can't be high on anyone's agenda can it?

That is, merging site locals would only be an issue of site locals are
actively being used - if they're useless, and problematic, as you're
claiming, then surely people won't be using them (the "I can't get enough
address space" excuse for using 1918 addresses won't exist after all).

If no-one uses them, merging won't be a problem, and nor will any of the
other issues you see, surely?

So, if you're worried about this, then you must be assuming that they
will in fact be used - which to me means, that you can see that there is
actually a demand for something to solve the problems that (apparently)
only SL addresses currently can do (that's obvious, as if there was some
other available solution, then people would use that, rather than these
problematic SL things, wouldn't they???)

So...

  | unfortunately, many important considerations were ignored in that design.

Let's see your design that handles the issues that you must agree that the
users need solved, and which actually takes note of all of those other
considerations.

Until we have that, and agree that it is a better design, let's just agree
that there really is no choice - we either keep SLs in the design (however
far from absolute perfection that actually are) or the users will invent their
own variations, in a thousand different ways - which I really can't believe
that you consider a preferable answer.

kre

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 17:13:55 -0500

Thus spake "Robert Elz" <[email-masked]>
> For internet access, a global address is used.   Sites (and hosts) have

I had always planned on using only SL addresses within the enterprise, and
then NATing those SLs to public addresses at the ISP.  That way, none of the
enterprise network is polluted with (frequently changing) global
addresses -- just like common IPv4 practice today.

To assign more than one address to every host means the host must have an
intelligent means of deciding which address to use.  I don't trust the hosts
(either OS or the user) with that decision any more than I trust them with
QOS.

S

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 05:13:26 +0700

Date:        Sat, 19 Apr 2003 17:42:21 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | wrong.  we know now that 1918 addresses created a big mess.

No, we don't know that, because that's incorrect.   1918 addresses
are just numbers, they can't have created the mess.   The mess was created
by the demands of the users that led to the creation of the 1918 addresses.
That is, the mess would still have been there, but worse, had 1918 never
existed.

  | and nothing about IPv6 use of SLs reduces that mess.

I think it does, but even if you're right, the mess is there anyway.
It isn't going away, whatever you do with SLs.

This is just like not liking shit, so you're going to ban the sewer system.
Great plan.

  | no, you have it backwards.  SLs destroy the utility of IPv6.

There's a quote I remember that seems apt, I'm sure someone will
remember who it was said this ...

	"yawn.  I'm tired of baseless assertions."

kre

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 18:27:35 -0400

> > may be local topology changes - moving a host to a different LAN, or
> > global ones - connecting to a different provider).   That is the only
> > reason. As long as prefixes remain usable, they can keep on being used,
> > with other prefixes added as required.
> 

this only solves one of several problems with site-locals, and it removes one
of the few supposed benefits of site-locals - that such addresses will be
stable across prefix changes.

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 17:40:32 -0400

> technologies with IPv6 whether the IETF standardizes it or not.

yawn.  I'm tired of baseless assertions.

many of the reasons for using NAT do not apply to IPv6.   if you're going
to use NAT, you may as well use IPv4.  a big reason to move to IPv6 is to
get away from the problems that are caused by NATted IPv4 networks.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 05:22:37 +0700

Date:        Sat, 19 Apr 2003 17:51:19 -0400
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | So if it's expected that both global and site-local addresses are available,
  | why are we bothering with making things more complicated?

Because we need stable addresses for local use.

Something tells me you've never actually lived in an environment where your
global address changes moderately frequently.   If you had, you wouldn't
be so quick to ignore this need.

  | That's exactly *why* they're broken - if you've suddenly had a global
  | address show up, there's now a danger of leaking a local address, so it's
  | not safe to use site-local anymore.

What is the danger here, and why do I, the user, care?   What I know is
that I want me local communications to just keep on working smoothly,
whatever happens to external connectivity and the addresses I get from
there.

  | Well.. all you need to do to fix this is to make a rule that if a
  | global prefix becomes available, the site-local prefix is no longer
  | appropriate and must be withdrawn.

Can't possibly work.

  | This *still* leaves the problem of using site-local behind a NAT, though.

First, while I can imagine people existing who would be stupid enough to
do that, I find it hard to figure out what their reasoning would be.

But if you assume that there are people (and there most probably are) who
are so sold on the "benefits" of NAT, that they're going to use NAT no
matter how much you show them that there is in fact no benefit at all
(which for a site with an IPv6 global /48, and site locals, is certainly
true) then why would you care what address they're using behind the NAT?
That is, whether it is SL, LL, or some random "global" prefix they calculated
by tossing coins.

I find it almost inconceivable to believe that anyone is deciding the fate
of SL addressing by reference to NAT - that's simply too ludicrous (and sad)
to contemplate.

kre

---

From: Daniel Senie <[email-masked]>
Date: Sat, 19 Apr 2003 18:35:11 -0400

At 05:28 PM 4/19/2003, you wrote:
>IP networks not connected to the Internet have become
>vanishingly rare.

Umm, how do you know? If they're not connected, you may just not be aware 
of them. Please let's not base standards work on unquantified assumptions.

Example of usage: I use RFC 1918 space for private networks within server 
farms. There's no connection to the public network from this private 
segment. Servers connect to both public and private networks. Backups, NFS 
mounts, SNMP and SQL data flows over the private network. The isolated 
network segment keeps traffic off the public network for performance reasons.

In my experience it's common to find configurations of this sort in server 
farms. Often the setups use several levels of isolated networks, with VPN 
access for administrative users. Sometimes it's done as a 
belt-and-suspenders, providing a measure of additional protection (if you 
can't route packets, they won't come) beyond whatever protections are in 
firewall and server configurations, but more often it's for performance 
reasons.

All the world of private addressing is not NAT, regardless of how many 
times people say it is.

Now back to the IPv6 discussion.

I am saddened by the fact that Tony's simple question could not be 
addressed. Site local addressing in IPv6 is a concept which has been 
mentioned in RFC 1884, 2373 and 3513, the progression of Proposed 
Standards. This is a string of documents dating back to 1995. For eight 
years this concept was apparently considered a good thing. The discussion 
on the mailing lists makes it sound like site-local addressing is a new 
idea. I'd like to know why it's taken eight years for folks to decide it's 
bad. Is it that folks are just now implementing IPv6? Is it because the 
documents these eight years never made the concept clear, and now it 
appears too hard to implement? In all those years, has no vendor 
implemented site local? Are there any other features we should reconsider 
as long as we're ripping the documents open?

It is not unprecedented to change or remove a feature as a document 
advances through the standards track. Such changes, however, can have 
significant impact on already-implemented and deployed solutions. Such 
matters should be considered carefully in that light. Perhaps removal of 
features should receive substantially more scrutiny after publication on 
the standards track.

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 18:35:55 -0400

>   | significant new problems of its own, and results in even less
>   | flexibility than if SLs were used only by isolated networks.
> 

there's a reason that most v4 hosts don't have multiple addresses with varying
scopes - it doesn't work well, and it creates problems for apps.  putting
sitelocals in v6 is trying to impose those problems on all host.

> should be a challenge, not something to fear.

by that logic we should make the architecture as 'challenging' as possible.
personally I think getting the network to work well is enough of a challenge
without adding needless complexity.

> addresses are the only way to have multiple topological attachments,

yes there are other justifications for multiple prefixes.  I think that
overall they are valuable enough that I'm not suggesting that we get rid of
them.  what we need to do is to get rid of the idea that it matters which
address you use.

> away, you're also going to have to deal with scoped addresses.

LL use can and should be reserved for bootstrapping and diagnostics.

> address space" excuse for using 1918 addresses won't exist after all).

SLs aren't useless - it's just that their use causes so many problems
that we're better off providing that functionality in other ways.

> problematic SL things, wouldn't they???)

no, it's the other way around - the expectation of using SLs thus far has
pre-empted development of better solutions.  (by your logic the network
already works as well as it possibly can, if a better network were possible
then it would exist, wouldn't it?)

> that there really is no choice - we either keep SLs in the design 

we've already agreed to get rid of them.  it's just that some people are in
denial about that.

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 19 Apr 2003 16:37:37 -0600 (MDT)

> From: Robert Elz <[email-masked]>
> To: Keith Moore <[email-masked]>

> We either provide a mechanism, or the users provide one of their own.

There's something about this long controversy I don't udnerstand.
Why do you need to provide any mechanism that does not already exist?
Do you want to prevent people from using RFC 1918 addresses mapped to
IPv6 addresses in the usual way?  Could you prevent that use of RFC 1918
addresses if you wanted to?

What about the new IPv4 site-local, automatically allocated addresses?
Do you want to prevent their use as IPv6 mapped addresses?  Could you?

Vernon Schryver    [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 18:46:17 -0400

> then NATing those SLs to public addresses at the ISP. 

we can't stop you from screwing up your network.  just don't expect us to
endorse such practices, and don't expect apps to work across your network
boundary.

> That way, none of the

and the network is dysfunctional, just like common IPv4 practice today.

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 18:43:51 -0400

> That is, the mess would still have been there, but worse, had 1918 never

not clear.  as someone pointed out, the intended use case for 1918 has all but
disappeared, so maybe we wouldn't have had such a mess afterall. 

of course we would have had to have some kind of scoped addresses by now
anyway due to the address shortage in v4.  that doesn't justify putting them
in v6.

> This is just like not liking shit, so you're going to ban the sewer system.

well, the damage caused by SLs spreads to every aspect of the network from
apps on down.  so having SLs in v6 is like saying that since we are going to
have shit no matter what we do, we might as well spread it everywhere rather
than try to promote any kind of sanitation.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Apr 2003 05:42:23 +0700

Date:        Sat, 19 Apr 2003 17:13:55 -0500
    From:        "Stephen Sprunk" <[email-masked]>
    Message-ID:  <00d001c306c0$faeadf90$93b58742@ssprunk>

  | To assign more than one address to every host means the host must have an
  | intelligent means of deciding which address to use.

Yes, but the amount of intelligence actually needed is pretty minimal.
(It is actually harder to decide between multiple available global
prefixes, than to decide between global and site local - the former is
a difficult problem, the latter is almost trivial).

  | I don't trust the hosts (either OS or the user) with that decision
  | any more than I trust them with QOS.

But you do trust them to select a suitable outgoing interface, to
pick a usable router, and to choose amongst several different possible
addresses for the destination (over which you most often have no control).

This all seems rather arbitrary.

Forcing NAT on hosts & users because you're afraid that the OS/app
designers can't tell what's global and what is site local seems rather
heavy handed.   I'm sure glad I don't have to live with your policies.

kre

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 19:20:24 -0400

>   | To assign more than one address to every host means the host must have
>   | an intelligent means of deciding which address to use.
> 

disagree.  the app can choose any global prefix and reasonably expect it to
work, modulo link failures. but when choosing between a global and a site
local the app needs to know whether the site local address will be valid for
the hosts that need to use it, and it has no way to know this.   the app may
also have to choose which interface to use with the site-local prefix,
and it has no good way to know this either.

---

From: Ole Troan <[email-masked]>
Date: Sun, 20 Apr 2003 00:22:00 +0100

[...]

> LL use can and should be reserved for bootstrapping and diagnostics.

LL is used in applications already. e.g LL addresses are commonly used
to address BGP endpoints on exchanges. so unless you suggest to remove
LL addresses (and MPLS VPNs) implementations will need to handle
ambiguous and topologically scoped addresses, even without
site-locals.

/ot

---

From: [email-masked]
Date: Sat, 19 Apr 2003 19:48:58 -0400

> whatever happens to external connectivity and the addresses I get from

Right.  You the user *don't* care.  

Users are almost never network admins.  And the network admins presumably
care (although with the amount of 1918 leakage we see, that's a dubious
assertion as well).

>   | appropriate and must be withdrawn.

How is it any different than any *other* prefix becoming not appropriate
and being withdrawn?

There's this big assumption on the part of the pro-site-local crew that
we "need" a stable address.  I posit that this is a crock, and that
what we *need* to do is iron out the rough edges of IPv6 renumbering
so hosts don't care *what* they have, as long as they have *some*
prefix.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Apr 2003 16:37:00 -0700

Folks,

RE> First, they're clearly of local use (defined in the
RE> architecture), hence if they do leak, at least it is obvious what is
RE> happening.

And, yes, that sounds like 1918, for which there are no new
requirements.

oh. but wait. we *have* been given new requirements, including the
suggestion that applications now need to know about different kinds of
addresses.

Forgive me, but I do not recall that requirement being imposed in the
days of 1918, and could have sworn that it was something new. Such a
requirement only comes from a significant change to the architecture,
and that was my original contention.

(I really do wish folks would check their various *-bashing arguments at
the door.  I have no desire to re-live diatribes against NATs or even
1918, though it's worth noting that those caveats in 1918 only got there
because a few of us put up a fuss at the time.  At any rate, the
question at hand is about new-vs-old architecture, so could we please
focus on it?)

RE> Is not true for site locals, as no-one anticpiates that a SL address is
RE> all an enterprise will be using

And since that was also true in IPv4, we have nothing new, right?

Oh.

You mean SLs are only interesting because they derive from a very new
architectural feature, and we are only now trying to think through the
implications, and those implications are turning out to be widespread?

So, folks, could we please return to the content issue I tried to raise:

DC> site local is, in fact, an addition to the IP architecture and that is
DC> what is causing the controversy.  For example, it has prompted the
DC> suggestion that applications be made to know the difference between site
DC> local vs. global IP addresses.
DC>
DC> When we go around making basic additions to an architecture, we should
DC> try to be very clear on how it will be used, how it will impact the rest
DC> of the architecture, and what the benefits and problems are likely to
DC> be.

RE> is not true of SL addresses, as one doesn't "renumber" them, one just
RE> augments with a global address.

I like the "just". As in, one "just" re-design the Internet's applications.

RE> You may notice that it isn't *just* site locals that provide the cleanup
RE> here, it is the whole IPv6 architecture, considered as a whole.

Dandy.  Glad to move my query to the "as a whole".  Any relevant list of
benefits and detriments will be a constructive start.

However not just idealized, conceptual benefits, but thinking that shows
some dirt under the fingernails, from foraging through the messy details
of making this stuff work in a real-world system.

My own guess is that the implications have *not* been drawn. Hence
roughly 9 years years after the first draft of IPv6, we get broad
suggestions to make applications know about different kinds of
addresses.

The other requirement for differential address handling -- local-net vs.
routed -- is handled at the IP layer and is invisible to applications.
It is computationally cheap and offers a very, very big benefit, by
avoiding the choke-point hop through the local router.

Someone needs to provide a similar analysis for SLs, or any other sort
of major change to the architecture.

For example, note that dropping header checksums from IPv6 was, shall we
say, a rather astonishing suggestion, but Deering readily produced very
solid arguments for the benefits and very solid arguments showing a lack
of detriments.

Why is it unreasonable to expect the same for other such changes?

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Apr 2003 16:47:12 -0700

Folks,

DS> I am saddened by the fact that Tony's simple question could not be
DS> addressed. Site local addressing in IPv6 is a concept which has been
DS> mentioned in RFC 1884, 2373 and 3513, the progression of Proposed 
DS> Standards. This is a string of documents dating back to 1995. For eight
DS> years this concept was apparently considered a good thing.

The problem appears to have been that no one bothered to draw the
necessary implications and circulate them for explicit consideration. So
folks scanned a spec, didn't see anything that looked egregious, and
only now are realizing how extensive the impact is.

We have a very basic, very serious problem with coordination among
different parts of the IETF.  Our tendency is to task various folks with
doing a better "monitoring" job.

My guess is that, instead, we *all* need to do a better job of noticing
when we are specifying something that has an architectural impact, by
which I mean something that affects other parts of the Internet service.

Once upon a time, the Security Considerations section was pro forma.
These days, it is taken seriously, and specifications are required to
develop this section carefully.

More recently we have added IANA Considerations sections, to make sure
that administrative issues are handled more easily.

Perhaps it is time to require specifications to make explicit statements
about the impact the spec's features will have on architectural
providers and consumers. That is, the features of a specification draw
on system Internet services "below" and give services to parts of the
system "above".

Any specification that creates interesting features should be required
to specify its requirements on providers and its impact on consumers.

d/

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 20:00:49 -0400

> to address BGP endpoints on exchanges. 

I don't think of BGP as operating at level 7.

I don't have a problem with LL being used for a few special-purpose things
that can deal with it, so long as we don't expect LL to work for all or even
most apps.

---

From: Joe Abley <[email-masked]>
Date: Sat, 19 Apr 2003 20:06:10 -0400

> to address BGP endpoints on exchanges.

What exchanges do that?

Joe

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 19:15:07 -0400

>  Site local addressing in IPv6 is a concept which has been 
> years this concept was apparently considered a good thing. 

it is indeed unfortunate that it took several years before there was serious
consideration to the impact of site-local on networks, DNS, and applications. 
I view this as an indication of serious failures in our process - IPv6 was
approved (under pressure, it must be said) by the working group and IESG
despite serious technical omissions.  fortunately proposed standards are not
carved in stone, and these particular omissions are easy to fix.

> I'd like to know why it's taken eight years for folks to decide it's 
> bad.

because few serious applications people were in the discussion, and there
wasn't enough review by those people during Last Call.  most apps people
probably assumed that the changes between IPv4 and IPv6 would be transparent
to them, other than having to use a different size for the address.

also IPv6 took so long getting out the door that it was widely viewed as
on a distant horizon - something that could be dealt with when it finally
arrived (if that ever happened).

> Is it that folks are just now implementing IPv6?

no, but most of the early apps that were ported to IPv6 were two-party apps,
often apps that were used in conjunction with either a v4-v6 translator or
proxy.  many problems with SLs don't show up for these apps; they show up for
multi-party apps.  also, even though there were v6 stacks there were probably
not many early networks that made heavy use of both SLs and globals.

> features should receive substantially more scrutiny after publication on 

I don't disagree.  but surely the months of discussion on this topic qualify
as a substantial amount of scrutiny.  and surely you'd agree that features in
published documents that appear to cause problems should also receive a
substantial amount of scrutiny before advancing those documents?

---

From: Ole Troan <[email-masked]>
Date: Sun, 20 Apr 2003 01:14:30 +0100

> I don't think of BGP as operating at level 7.

well, BGP uses TCP as transport and most of the implementations I've
seen use POSIX socket API just like any other application. the socket
API needs let the application choose zone, and pick a suitable source
address accordingly.

> that can deal with it, so long as we don't expect LL to work for all or even

that is a big change in the IPv6 architecture. throwing all the cards
up in the air every second year or so (anyone recorded what the
frequency is for old and closed discussions reappearing on the ipng
list?) gets rather trying after a while. perhaps about time to shut
the IPv6 W.G down?

/ot

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 19:11:28 -0500

> | So if it's expected that both global and site-local addresses are
> | available, why are we bothering with making things more complicated?
>

Any unique global address will work fine for local use, even if you're
disconnected from the Net.  Or do you expect your global prefix(es) to be
withdrawn from hosts every time your upstream connection flaps?

> Something tells me you've never actually lived in an environment where
> your global address changes moderately frequently.   If you had, you
> wouldn't be so quick to ignore this need.

But haven't you heard?  With IPv6, renumbering will be so easy you'll do it
for fun!  </sarcasm>

The pain renumbering is one of the main motivators for NAT today, and I have
yet to see any reason to believe it'll be easier in IPv6.

>   | appropriate and must be withdrawn.

If site-locals and globals are to coexist, the obvious solution is to
specify that when the destination is SL, an SL should be preferred as
source, and likewise for globals.

Of course, that doesn't fix the case where you have multiple globals, or
multiple interfaces.  We haven't figured out how to fix that with IPv4
either, except for specific cases like "backside networks".

> do that, I find it hard to figure out what their reasoning would be.

Avoiding renumbering, avoiding exposing internal identities, etc.

It's all the same reasons you might use IPv4 NAT, with the possible
exception of address shortages.  I know several very large corps that use
legacy class B space inside and NAT to provider-assigned CIDR space
outside -- they're obviously not doing it because of address shortages,
they're doing it for administrative and scoping reasons.

> of SL addressing by reference to NAT - that's simply too ludicrous
> (and sad) to contemplate.

Well, IPv6 NAT proponents expected to use the SL prefix as their private
addressing, so eliminating SL will require another prefix for that purpose.
I don't see any other direct connection, however.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 19:19:30 -0500

> >   | To assign more than one address to every host means the host
> >   | must have an intelligent means of deciding which address to use.
> >
> disagree.  the app can choose any global prefix and reasonably expect
> it to work, modulo link failures.

Nit: the vast majority of apps today bind to INADDR_ANY (or its IPv6
equivalent), so it's really the OS which is choosing the source address.  If
the app binds a specific source address, it is invariably user-configurable
and thus not an application problem.

> but when choosing between a global and a site local the app needs to
> know whether the site local address will be valid for the hosts that need
> to use it, and it has no way to know this.

Well, since one can easily determine whether the destination address is SL
or not, picking a source address of the correct class is trivial.

> the app may also have to choose which interface to use with the site-
> local prefix, and it has no good way to know this either.

Ah, but it'll have a different SL address on each interface, so that's no
worse than having multiple global addresses.  The truly interesting case is
connecting to a LL address with multiple interfaces.

S

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 20:26:37 -0400

> > that can deal with it, so long as we don't expect LL to work for all or
> > even most apps.
> 
> that is a big change in the IPv6 architecture. 

anyone who ever thought that scoped addresses were generally applicable was
deluded.

---

From: Bill Manning <[email-masked]>
Date: Sat, 19 Apr 2003 17:24:39 -0700 (PDT)

% >>> So, unless there's some routing revolution, you're just going to have
% >>> to learn to deal with multiple addresses, and unless LL addresses go
% >>> away, you're also going to have to deal with scoped addresses.
% >>
% >> LL use can and should be reserved for bootstrapping and diagnostics.
% >
% > LL is used in applications already. e.g LL addresses are commonly used
% > to address BGP endpoints on exchanges.
% 
% What exchanges do that?
% 
% 
% Joe

	Akira Kato and I had a draft out on how this could be done
	and had working, inter-operable implementations (zebra, cisco)
	in two locations, NSPIXP3 and LAIIX.  The IDR wg chose another
	method and so this technique is not likely to be widely 
	endorsed as an IETF approved method. It is still supported in
	the code and some folks still use it.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Apr 2003 20:36:06 -0400

> equivalent), so it's really the OS which is choosing the source address.

one of the problems introduced by scoped addresses is that this is no longer
sufficient for some kinds of apps.

> If the app binds a specific source address, it is invariably
> user-configurable and thus not an application problem.

or to put it more clearly, the only way an app can choose reasonably
between multiple addresses of varying scopes is to be explicitly configured as
to how to do so.  otherwise, the app has no idea whether one scope or another
is more suitable for its purposes.   any assumptions about whether, for
instance, site-locals are more secure or more stable than globals, or
whether the app will need to communicate with off-site nodes, need to be
explicitly configured.

of course, if the app weren't being forced to choose between addresses of
differing scopes then it wouldn't need to bind to specific source addresses
(no more than v4 apps do), and such configuration would not be necessary.

> or not, picking a source address of the correct class is trivial.

wrong again.  it's not reasonable to assume that the source address will not
be used by off site nodes.  (of course, specific apps can make that
assumption, but the architecture should not)

> worse than having multiple global addresses. 

depends on what is driving the selection -  I don't think it's reasonable
to assume that all interfaces on a host are within a single site.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 19:27:38 -0500

>   | To assign more than one address to every host means the host must
>   | have an intelligent means of deciding which address to use.
>

Agreed.  But the former is a problem nobody has solved after a couple
decades' effort.  Choosing a source address today is a problem only for
dual-homed hosts, which are fairly rare; I see no compelling reason to bring
this afflication to every IPv6 host until the problem is solved.

> But you do trust them to select a suitable outgoing interface, to pick
> a usable router, and to choose amongst several different possible

Most hosts have one interface, one source address, and one default gateway
(or two that are equally valid).  Recall the KISS principle.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 19 Apr 2003 19:51:54 -0500

Thus spake <[email-masked]>
> so hosts don't care *what* they have, as long as they have *some*

Changing the address on a host's interface is easy -- too bad there's a lot
more involved in renumbering.

For one thing, we need a TCP that can support address changes during a
session, and it can't rely on a deprecation period.  Beyond that, we'll need
widespread deployment of DDNS, which scares the heck out of most DNS admins
I know, with or without PKI.

S

---

From: john heasley <[email-masked]>
Date: Sat, 19 Apr 2003 20:24:26 -0700

Sat, Apr 19, 2003 at 05:24:39PM -0700, Bill Manning:
> 	in two locations, NSPIXP3 and LAIIX.

but, why?

---

From: Bill Manning <[email-masked]>
Date: Sat, 19 Apr 2003 21:25:59 -0700 (PDT)

% Sat, Apr 19, 2003 at 05:24:39PM -0700, Bill Manning:
% > % >>> So, unless there's some routing revolution, you're just going to have
% > % >>> to learn to deal with multiple addresses, and unless LL addresses go
% > % >>> away, you're also going to have to deal with scoped addresses.
% > % >>
% > % >> LL use can and should be reserved for bootstrapping and diagnostics.
% > % >
% > % > LL is used in applications already. e.g LL addresses are commonly used
% > % > to address BGP endpoints on exchanges.
% > % 
% > % What exchanges do that?
% > % 
% > % 
% > % Joe
% > 
% > 
% > 	Akira Kato and I had a draft out on how this could be done
% > 	and had working, inter-operable implementations (zebra, cisco)
% > 	in two locations, NSPIXP3 and LAIIX.
% 
% but, why?

	why not?  back in the day, the pier wg identified several 
	apps that did not take to renumbering well.  BGP was one.
	couple that with the oddities of small bits of address 
	space that are needed at exchanges (and do not play well 
	w/ the (non)compelling arguements for aggregation) and it 
	seemed reasonable that, if massive aggregation was an 
	inevitable feature of IPv6, that moving exchange point 
	communications to linklocal addresses would make many 
	things simpler. No "special-use" ranges in v6 land
	for exchanges.  But it was not to be.  Check the IDR
	archives for details.

	we now have special blocks of IPv6 space that are not
	supposed to be aggregated for things like exchanges.
	massive aggregation is expected, except for these "special
	prefixes".  One more administrative thing to track. :(

--bill

---

From: Paul Vixie <[email-masked]>
Date: 20 Apr 2003 04:56:08 +0000

i'm sorry to come into this late.  something went by a while ago that's
quite interesting.  sherman, set the wayback machine for...

> > % >>> So, unless there's some routing revolution, you're just going to
> > % >>> have to learn to deal with multiple addresses, and unless LL
> > % >>> addresses go away, you're also going to have to deal with scoped
> > % >>> addresses.

having recently done some work to describe and differentiate what i now
call a "dns-aware application", the above statement strikes me as more
relevant than most of the discussion that has followed it.

an application which has to be aware of ip address content in any way is
a different beast altogether than one which treats them as opaque.  from
a C programmer's point of view, the difference can be determined by
searching the module's source for "s6_addr" and "sin6_".  if neither
appears then you're probably not dealing with an "address aware" module.
if either appears, then you'll need to look carefully at it to find out.

an "address aware" program (module, library, application, whatever) has
to know about things like LL scopes, and currently, about SL issues.  any
other, non-"address aware" program, just receives "address blobs" from one
place and carries them around opaquely until it's time to offer them up on
some other altar, never knowing or caring what's "in the bag."

that being the case, i think it's "just plain wierd" that anybody is
arguing about the conceptual or architectural or complexity cost of SL
since the number of "address aware" programs is expected to remain quite
low in v6, perhaps lower as an overall share than in v4.  and for those
few programs, LL scopes and SL issues will not be a noticeable share of
the overall cost or complexity of the program.

this is not to paint myself as a supporter (nor detractor) of SL.  it's
possible that SL is as bad as people say, or as misunderstood, or whatever.
i just don't think it's reasonable to use application complexity as an
indicator of SL's cost:benefit ratio, since most applications Just Won't
Care.

(when i first heard of SL i thought, oh good, it's like rfc1918 but at the
campus level rather than at the autonomous system level.  them someone told
me it wasn't really like that, so now i'm opinionless.)
-- 
Paul Vixie

---

From: Eliot Lear <[email-masked]>
Date: Sun, 20 Apr 2003 06:51:32 -0700

Hi,

Daniel Senie wrote:
> Example of usage: I use RFC 1918 space for private networks within 
> server farms. There's no connection to the public network from this 
> private segment. Servers connect to both public and private networks. 
> Backups, NFS mounts, SNMP and SQL data flows over the private network. 
> The isolated network segment keeps traffic off the public network for 
> performance reasons.

This has become an acceptable use of RFC 1918 addresses.  On the other 
hand, there is no need to support this sort of use in the v6 
architecture.  The address space is simply too vast for people to have 
to economize like this.

> All the world of private addressing is not NAT, regardless of how many 

My major concern that does drive NAT is the expressed desire on the IPng 
list to isolate sites from having to renumber.  That use of SLs requires 
NAT or proxy.  Rob may call it crazy, but the demand is there right now.

> years this concept was apparently considered a good thing. The 
> discussion on the mailing lists makes it sound like site-local 
> addressing is a new idea. I'd like to know why it's taken eight years 
> for folks to decide it's bad. Is it that folks are just now implementing 
> IPv6? Is it because the documents these eight years never made the 
> concept clear, and now it appears too hard to implement? In all those 
> years, has no vendor implemented site local? Are there any other 
> features we should reconsider as long as we're ripping the documents open?

Quite simply it is something we seem to have forgotten about: learning 
from operational experience.  Since 1995 the use of private address 
space has changed, as has been said.  Also, I don't think people fully 
understood the ramifications of SLs.  I certainly didn't, initially.  We 
also learned that using EUI-64s as end identifiers has certain privacy 
considerations, so this is not a first.  I think we do have to take some 
care when making changes to the addressing architecture.  If the 
decision of the group holds, it seems to me that those of us who voted 
"YES" have the burden to now provide an alternative that addresses the 
real requirements that SLs attempt to tackle.

> features should receive substantially more scrutiny after publication on 

I agree.  The vote was for deprecation.  That means we need to deprecate 
in favor of something better.

Happy holidays,

Eliot

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 10:19:11 -0400

> the overall cost or complexity of the program.

the existence of scoped addresses in v6 forces a greater percentage of
programs to be address aware.  some programs that could avoid being
address aware in ipv4 cannot do so in v6 and provide the same functionality.

---

From: Markku Savela <[email-masked]>
Date: Sun, 20 Apr 2003 18:29:33 +0300

> address aware in ipv4 cannot do so in v6 and provide the same functionality.

I want to see an existing sample of an application that fails with
sitelocals (or to make it even more simple, an application that fails
on IPv4 link locals, will do also).

However, theoretical examples wont do. I want to see a program name
and an URL where I can download source for a study. Surely, if many
applications fail with site locals, there can be at least one existing
open source application?

Just ONE such example, please?

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 11:35:50 -0400

> on IPv4 link locals, will do also).

NetSolve  	http://icl.cs.utk.edu/netsolve/
PVM		http://www.epm.ornl.gov/pvm/pvm_home.html

either of these will fail if run on nodes with a mixture of scoped and global
addresses.  

for that matter, so will SIP.

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 13:07:19 -0400

> Keith,
> For the benefit of us uninformed lurkers who learn best by example,
> could you provide one?

Already done, see my previous message.

> Also, I'm wondering how the SL/1918 address-scoping debate plays in
> the context of firewalls.  Don't firewalls provide an even more random
> form of address scoping that apps must cope with?  Or not?

It's a separation of function issue.  Ideally, apps try to send messages to
their peers; the network makes a best effort to deliver them there, modulo
policy.  That way, the apps can concentrate on their intended purposes, and
the network concentrates on its intended purpose - neither needs to absorb
the complexity required to second-guess the other.  Each has a clear set of
expectations, there's an obvious separation between the two, and if something
fails the problem is clearly on one side or the other.  Separation of function
minimizes complexity and improves robustness. also, there's less incentive for
an arms race between apps and the network, which also helps to keep complexity
down.

Specifically, in a world where all addresses used by apps are global, if a
firewall blocks traffic from host A to host B, there's nothing that an app on
host A can or should be expected to do about it.  The app may not be able to
tell whether it's due to a network failure or a firewall, but it doesn't
matter too much - the most the app can do is retry at a later time. (I'd argue
that ICMP should allow the app to distinguish the two, for the sake of error
reporting, and to distinguish permanent failures due to policy based filtering
from temporary failures due to link outages.  But it appears that we need
fixes to both firewalls and APIs to make this work well.)

Scoped addresses muddy this picture, because experience indicates that apps
will be expected to cope with a mixture of scoped and global addresses.  Once
scoped addresses are introduced, the app has to perform functions
traditionally performed by the network. If host A cannot reach host B, it
might be due to policy or a network failure, or it might be that the address
that A has for B is not valid in the scope that A is using.  There's no way
that A can know this.  A might need to try sending to B from a different
interface.  Or it might need to try to route the message through a peer that
does have access to B's scope.  Or it might need to be able to try multiple
addresses for B.  Or all of the above.  But since A doesn't have access to the
network topology information anyway (unless it's explicitly configured to know
such things), this involves something between trial-and-error and network
probing.  Basically the app is expected to absorb a lot of complexity just to
function in these cases, and even then, the app is not likely to function
reliably. For that matter, since apps now have more reason to try to route
traffic to their destination by any means available (including
application-level tunneling), it becomes much more difficult to make effecitve
firewalls.  Even "legitimate" programs will be forced to employ such tactics.

So scoped addresses increase complexity of both apps and networks.

---

From: Richard Carlson <[email-masked]>
Date: Sun, 20 Apr 2003 12:00:55 -0500

At 07:20 PM 4/19/03 -0400, Keith Moore wrote:
>work,

I completely disagree with this assumption.  Firewalls and address filters 
mean that no app can make any reasonable assumption.  Some addresses will 
work and others will fail.  The app is left with no clues as to why the 
connection failed.  Assuming it's just a link failure and retrying sometime 
in the future things will work is a receipt for user frustration.

>modulo link failures. but when choosing between a global and a site

The decision process is not forced on the app/host by the existence of the 
site-local prefix.  It is due to the emergence of firewalls and address 
filters.  The reality is that non-global routing scopes exist today.  The 
question is - how do we provide some feedback to apps that they are trying 
to cross a scope boundary that it's a permanent error condition (5xx in 
SMTP verbiage)?  One proposed notification method is the site-local 
prefix.  Other methods can be created, but something needs to be done and 
simply killing site-locals and ignoring the underlying scoping issue is a 
non-starter.

Rich

------------------------------------

Richard A. Carlson                              e-mail: [email-masked]
Network Research Section                        phone:  (630) 252-7289
Argonne National Laboratory                     fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439

---

From: Daniel Senie <[email-masked]>
Date: Sun, 20 Apr 2003 14:16:12 -0400

At 01:00 PM 4/20/2003, Richard Carlson wrote:
>connection failed.  Assuming it's just a link failure and retrying 
>sometime in the future things will work is a receipt for user frustration.
>

You mean aside from applications understaning that an ICMP Destination 
Unreachable / Administratively Prohibited response from the site firewall?

For that matter, IPv6 machines arguably could try their Site Local address 
and be given that same feedback from the border router or firewall, and use 
the response as an indication to go use their assigned global address. It's 
not clear to me that the host or application need contain the intelligence 
(nor is there any way to determine scoping unassisted, IMO), however 
through use of ICMP responses it certainly should be possible to determine 
reachability or lack thereof. It may be useful to expand the responses 
routers and firewalls give to hosts within sites to help accomplish this.

We have the problem of scoped addresses whether the "site local" mechanism 
is retained or not. Providing guidance on the responses an application is 
to receive in response to scoping controls (firewalls) would be useful 
regardless. If this problem is worth solving for the already-common case of 
firewalls, solving it for site-local addressing does not seem to be too 
much of a stretch.

---

From: Richard Carlson <[email-masked]>
Date: Sun, 20 Apr 2003 13:55:56 -0500

At 02:16 PM 4/20/03 -0400, Daniel Senie wrote:
>>> have
>>I completely disagree with this assumption.  Firewalls and address 
>>filters mean that no app can make any reasonable assumption.  Some 
>>addresses will work and others will fail.  The app is left with no clues 
>>as to why the connection failed.  Assuming it's just a link failure and 
>>retrying sometime in the future things will work is a receipt for user 
>>frustration.
>>
>>The decision process is not forced on the app/host by the existence of 
>>the site-local prefix.  It is due to the emergence of firewalls and 
>>address filters.  The reality is that non-global routing scopes exist 
>>today.  The question is - how do we provide some feedback to apps that 
>>they are trying to cross a scope boundary that it's a permanent error 
>>condition (5xx in SMTP verbiage)?  One proposed notification method is 
>>the site-local prefix.  Other methods can be created, but something needs 
>>to be done and simply killing site-locals and ignoring the underlying 
>>scoping issue is a non-starter.
>

An ICMP message is one way of providing this information.  There may be 
others, I don't know by folks are free to develop them.

>and be given that same feedback from the border router or firewall, and 
>use the response as an indication to go use their assigned global address. 
>It's not clear to me that the host or application need contain the 
>intelligence (nor is there any way to determine scoping unassisted, IMO), 
>however through use of ICMP responses it certainly should be possible to 
>determine reachability or lack thereof. It may be useful to expand the 
>responses routers and firewalls give to hosts within sites to help 
>accomplish this.
>
>regardless. If this problem is worth solving for the already-common case 
>of firewalls, solving it for site-local addressing does not seem to be too 
>much of a stretch.

Exactly, the only thing an address with a site-local prefix tell me is that 
a filtering router or firewall is guaranteed to be in some arbitrary 
path.  I'm mystified as to why an app would treat it any differently that 
an IPv6 address generated with any other prefix.

Rich

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 15:10:59 -0400

> and be given that same feedback from the border router or firewall

how does any party - the host, border router or firewall - know whether the SL
address is from that site or some other site?  SLs are inherently ambiguous.

> , and use 
> the response as an indication to go use their assigned global address. 

if the destination has a global address, it should *always* be used in
preference to the site local, at least in the absence of external
configuration.

> is retained or not. 

I disagree, or at least, I think it's misleading to use  the term "scoped
addresses" to cover all filtering, because this is conflating two things - use
of filtering on one hand and use of ambiguous addresses on the other.  It's
useful to be able to refer to a host even if you can't send traffic there.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 15:26:24 -0400

> path. 

but you don't know which paths, so you don't know how to use that.

> I'm mystified as to why an app would treat it any differently that 

some people believe that SLs would be more secure than globals, even though
this is an unwarranted assumption.  some people believe they would  be more
stable than globals, but providing stable local addresses isn't a good
solution to the renumbering problem - it's not as if all of the important
apps affected by renumbering are local.  some people believe SLs would be more
efficient.  some apps writers would avoid using SLs whenever possible because
they're not portable (and they'll lose when SLs are all that are available),
some apps writers will use them in preference to globals (and they'll lose
when they're expected to communicate across site boundaries), and other apps
writers will try to deal with all cases (adding a lot of complexity and still
not able to avoid the app failing for apparently arbitrary reasons). any of
these makes the behavior of apps less predictable.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 20 Apr 2003 14:44:21 -0500

> > Also, I'm wondering how the SL/1918 address-scoping debate
> > plays in the context of firewalls.  Don't firewalls provide an even
> > more random form of address scoping that apps must cope with?
> > Or not?
>
> ...
> Scoped addresses muddy this picture, because experience indicates
> that apps will be expected to cope with a mixture of scoped and
> global addresses.  Once scoped addresses are introduced, the app
> has to perform functions traditionally performed by the network. If
> host A cannot reach host B, it might be due to policy or a network
> failure, or it might be that the address that A has for B is not valid in
> the scope that A is using.

So you're not arguing against scoped addresses per se, you're arguing
against having both scoped and global addresses on the same host?  I see the
same problem occuring if a host has two global addresses which are treated
differently by the firewall(s), so it's not truly a problem with SL.

The only SL-specific problem is when naughty applications pass network-layer
addresses across site boundaries; such applications must be "address aware"
anyways, so understanding SL isn't much of an incremental burden.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 20 Apr 2003 14:50:00 -0500

Thus spake "Daniel Senie" <[email-masked]>
> >The question is - how do we provide some feedback to apps that
> >condition (5xx in SMTP verbiage)?  One proposed notification
> >method is the site-local prefix.  Other methods can be created, but
> >something needs to be done and simply killing site-locals and
> >ignoring the underlying scoping issue is a non-starter.
>
> You mean aside from applications understaning that an ICMP
> Destination Unreachable / Administratively Prohibited response from
> the site firewall?

Many firewalls simply drop packets which are prohibited without sending ICMP
responses, not to mention all the places that filter all ICMP
indiscriminately.

> For that matter, IPv6 machines arguably could try their Site Local
> address and be given that same feedback from the border router or
> firewall, and use the response as an indication to go use their assigned
> global address.

The vast majority of applications do not pick their source address, nor is
there a compelling reason for them to do so.  A large number of applications
don't even handle multiple destination addresses properly, so expecting this
additional intelligence for the source address is irrational.

S

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 16:00:15 -0400

> against having both scoped and global addresses on the same host?

it turns out that this doesn't solve the problem.  the addresses will still
leak.  apps will still be expected to cope with the mixture of ambiguous and
unambiguous addresses.

> I see the
> differently by the firewall(s),

I see that as a different problem - in particular, in that case there's no
need for apps to cope with ambiguous IP addresses.  as a result it's much
clearer that it's unreasonable to expect apps to talk to the nodes whose
traffic is being filtered.

> addresses across site boundaries

which is a perfectly healthy and reasonable thing for apps to do.
(not that they can tell where those site boundaries are anyway)

> ; such applications must be "address aware"

using an address as an opaque identifier doesn't require address awareness.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 16:22:54 -0400

> there a compelling reason for them to do so. 

not in IPv4.  if IPv6 has site locals more applications will need to do so.

> A large number of applications

again, you're trying to extrapolate from ipv4 experience to ipv6, but such 
experience isn't necessarily a good indicator when ipv6 presents a more 
challenging environment than ipv4.  then again, if dealing with multiple
addresses for a host was hard in ipv4, it's not going to be easier in ipv6.

---

From: Daniel Senie <[email-masked]>
Date: Sun, 20 Apr 2003 20:19:03 -0400

>responses, not to mention all the places that filter all ICMP

Agreed, however: a) on the "protected" side of a firewall (for those 
firewalls that are configured for an "inside" and an "outside") this might 
not be the case as often, and b) if there's a strong need for appropriate 
ICMP responses to make IPv6 function well, then an RFC stating as much 
could be published. Firewall vendors could choose whether to implement 
such, but if that's an enabler for functionality then customers of such 
vendors will raise their voices.

>additional intelligence for the source address is irrational.

At which point they might as well just select their global address unless 
the destination address for a service is site local. This decision could 
(should?) be in the hands of the IP stack, unless the application 
specifically asks for such control.

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Apr 2003 22:13:19 -0400

> b) if there's a strong need for appropriate 
> could be published.

like, for instance, a need for path mtu discovery to work reliably?
(since v6 routers don't fragment packets)

> >there a compelling reason for them to do so.  A large number of
> >applications don't even handle multiple destination addresses properly, so
> >expecting this additional intelligence for the source address is
> >irrational.
> 

I disagree that the IP stack can supply reasonable defaults in the face of
multiple scopes.  The criteria for choosing a source address varies widely
from one application to another.  Some applications need stable addresses,
others need addresses usable from all of their potential peers, others need to
choose the source address that results in the best performance (where there is
more than one meaning of 'best performance').  The default address selection
rules are at best a guess.  

We should let the network do routing, so that hosts and apps aren't expected
to make routing decisions.

---

From: S Woodside <[email-masked]>
Date: Mon, 21 Apr 2003 01:16:34 -0400

> Just ONE such example, please?

ohPhoneX

http://xmeeting.sourceforge.net/

Uses the H.323 stack for VoIP.

--
www.simonwoodside.com -- 99% Devil, 1% Angel

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Apr 2003 07:28:35 -0400

--On Sunday, 20 April, 2003 22:13 -0400 Keith Moore 
<[email-masked]> wrote:

>> At which point they might as well just select their global
>> address unless  the destination address for a service is site
>> local. This decision could  (should?) be in the hands of the
>> IP stack, unless the application  specifically asks for such
>> control.
>
> I disagree that the IP stack can supply reasonable defaults in
> the face of multiple scopes.  The criteria for choosing a
> source address varies widely from one application to another.
> Some applications need stable addresses, others need addresses
> usable from all of their potential peers, others need to
> choose the source address that results in the best performance
> (where there is more than one meaning of 'best performance').
> The default address selection rules are at best a guess.
>
> We should let the network do routing, so that hosts and apps
> aren't expected to make routing decisions.

Keith,

I don't understand your point here, and would like to.  It seems 
to me that your first paragraph ("I disagree...") suggests that 
the applications need to specify the addresses/interfaces 
because they know their needs and the stack can't figure it out. 
And the second argues for pushing the decisions onto the 
network, which has no information at all (and, if it had it, 
could probably apply it only by changing addresses mid-flight -- 
NAT-like or worse).  That suggests to me a conclusion of "not 
application, not stack, not network either" which leaves very 
few options.

If I ignore that apparent contradiction, I'm left with the 
conclusion that we need some new addressing and routing 
abstractions so that the applications can tell the stack (and 
the stack might tell, or negotiate with, the network) what 
considerations they need optimized and do so without specifying 
specific addresses or inspecting components of addresses.  It 
seems to me that such abstractions would also eliminate one of 
the arguments against site local: having an application able to 
tell the stack:

	* I need a local address
	
	* I need an appropriate address for routing to <DNS name>
	
	* I need a completely-global address

Are all far more reasonable than having the application itself 
recognize particular addresses or prefixes and trying to figure 
out which ones make sense in its context.  It also _might_ 
suggest that we need to reexamine ICMP in the IPv6 context to be 
sure that, if the stack needs information from the network to 
make satisfactory choices along these lines, it can ask them 
without, e.g., trying to set up one or more TCP connections (or 
sending UDP packet using an unspecified protocol) and waiting 
for the responses or timeouts.

Is that really where we need to be headed and, if so, is anyone 
doing the work rather than being stuck on "local-good / 
local-bad", "scope-necessary / scope-bad", types of arguments?

      john

---

From: Leif Johansson <[email-masked]>
Date: Mon, 21 Apr 2003 22:29:57 +0200

>to them, other than having to use a different size for the address.
I believe this is essentially correct.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 21 Apr 2003 14:48:41 -0700

>I believe this is essentially correct. 

s/applications/applications and security/

PKI ipAddress [RFC 3280, 4.2.1.7] altSubject name is
a good example of how application and security folks
have/haven't dealt with IPv6 addressing issues.

Kurt

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Apr 2003 13:50:45 +0300 (EEST)

On Sat, 19 Apr 2003, Bill Manning wrote:
[...]
> 	prefixes".  One more administrative thing to track. :(

Please stop this.  There is nothing of the kind.  The prefixes are not 
special.  They are not expected to be routable, so there are no additional 
administrative things to track.

Addressing for exchanges killed the need to using LL's with BGP, as simple 
as that.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 22 Apr 2003 14:32:46 +0200

just to provide a "simple" answer to a simple question:

NO - I do not agree with Keith's assertion as quoted.
YES - I agree with what I *believe* Keith wanted to say, which is that 
"introduction of *site-scoped* addresses causes far more problems than it 
solves".

I do NOT believe that introduction of link-local addresses causes far more 
problems than it solves.

My position on SL should be well known. I'll try to avoid repeating the 
rest of my arguments once again in this discussion tree.

                Harald

--On fredag, april 18, 2003 15:12:54 -0700 Tony Hain <[email-masked]> 
wrote:

> --------------------------------------------------------------------
> 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: Joe Abley <[email-masked]>
Date: Sat, 19 Apr 2003 19:05:10 -0400

On Saturday, Apr 19, 2003, at 18:22 Canada/Eastern, Robert Elz wrote:

> available,
> your

The rhetoric would have us believe that frequent renumbering with IPv6 
is seamless and effortless. I don't personally buy that, but there are 
some assumptions there that perhaps should be challenged more directly 
rather than in this oblique fashion.

If we accept the premise that frequent renumbering in IPv6 is not 
seamless and is in fact painful and worth avoiding, then rather than 
hiding the source of the pain behind a NAT perhaps we should try to 
eliminate it: find a mechanism which facilitates pervasive multi-homing 
with some stable view of layer-3 addressing from the layer above, 
across re-homing events.

That would solve multi-homing, session stability across renumbering 
events and changing providers all in one hit.

There's a party going on in multi6, and you're all invited. (well, 
we're all in the kitchen at the moment, but we'll move out onto the 
deck if more people show up).

Joe

---

From: Bob Natale <[email-masked]>
Date: Sat, 19 Apr 2003 21:40:03 -0400

At 4/19/2003:07:47 PM, Dave Crocker wrote:

Hi Dave,

I regret that this is going to sound like I'm tooting
my horn or something like that, but I'm just noting it
for emphasis:  I made almost exactly the same argument
for an "Architectural Considerations" section on a par
with "Security Considerations" in IDs and RFCs on the
"problem statement" list in the early days of that list.
I am hopeful that your raising it will have more impact.

I seriously believe that lack of architectural coordination
across the IETF's many efforts casts a pall on our work
in subtle ways which have far more impact on many of the
larger constituencies for our work.

I would only add that the implications of your wording of
your last statement -- 

"Any specification that creates interesting features should be required
to specify its requirements on providers and its impact on consumers."

-- might be a bit too optimistic...I don't think it goes
quite far enough in noting that it will probably take
review by members of the small cadre of IETF architecture
experts to be sure that all relevant requirements and
impacts have been accounted for.  Many document authors
(like me, for instance) might not know enough about IP-wide
and Internet-wide architecture issues to do a thorough job
on their own.  (Of course, I guess that's true of the already
mandatory "Security Considerations" section too! :-)

Cheers,

BobN
- - - - -
>_______________________________________________
>This message was passed through [email-masked], which is a sublist of [email-masked]. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Apr 2003 18:47:13 -0700

Bob,

BN>  I made almost exactly the same argument
BN> for an "Architectural Considerations" section on a par

excellent. two, independent occurrences of a crazy idea by unrelated
lunatics probably means there is some merit to it. (by which i mean that
any desire to dismiss the idea because it is easy to dismiss the
proposer gets more difficult when there are multiple, independent
proposers. And, yes, it must be saturday night, for this kind of
writing.)

BN> "Any specification that creates interesting features should be required
BN> to specify its requirements on providers and its impact on consumers."

BN> -- might be a bit too optimistic...I don't think it goes
BN> quite far enough in noting that it will probably take
BN> review by members of the small cadre of IETF architecture
BN> experts to be sure that all relevant requirements and

that's fine.  the point of the exercise is to require specification
authors to pay significant attention to the question.  this actively
creates a dialogue on the issues, rather than hoping that some clever
architect notices this particular document.

d/

---

From: Terry Gray <[email-masked]>
Date: Sun, 20 Apr 2003 08:47:43 -0700 (Pacific Standard Time)

Keith,

Thanks.

-teg

---

From: Randall Stewart <[email-masked]>
Date: Mon, 21 Apr 2003 16:12:52 -0500

> and it has no good way to know this either.

Keith:

I agree 100%.. it is quite difficult to choose a site local... and a
real pain to be able to tell which interface to use or if the
peer host can really speak on that site local.... very very
ugly... and I say this with respect to trying to make things
work in the kame SCTP implementation.. As far as I am concerned
we could do with-OUT site-locals.. but of course I have
said this before too :>

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 21 Apr 2003 14:22:01 -0700

> (since v6 routers don't fragment packets)

This is veering a bit off topic, but in the plpmtud bof at IETF 56
we were shown a method for determining path mtu that does not rely
on ICMPs. (ICMPs are untrustworthy and unreliable in any case, so
let's stop this red herring before it goes any farther.)

Thanks,

Fred
[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Mon, 21 Apr 2003 16:27:10 -0500

> and thus not an application problem.
Nit2Nit :>

That may be.. but it sure does not help us poor kernel developers any
:-<

> or not, picking a source address of the correct class is trivial.

I don't know if that is true.. if a host has multiple sites
on it and each site is multi-homed... aka

-------Intf-A---+----------+----Intf-D------
                 |          |
-------Intf-B---+----------+----Intf-C------

Say Intf-A/Intf-B are on one site
and
Intf-C/Intf-D are on another site..

Then if the SCTP stack is told to send a INIT -> out to a SL
address on Intf-A selecting the source address is somewhat ok
if the routing is set up.. but what other addresses do I list
in my INIT?

Ideally I would like to list the address for A and B. This way
my peer could take advantage of my multi-homing.. but instead
I can't... since when the peer receives the INIT it would have
no way of knowing the scope for the address and what interface
the address went with...

Other more complicated scenario's can also be imagined with
the above.. multiple sites on each host.. some shared some
not.. aakk... yuck...

It seems to me that with all the available address space having
a SL is just a waste.. If an enterprise is worried about
security put up something that is real aka a firewall.. not a
NAT...It does not really add anything but it does drag
along an ugly abomination that was needed as a stop-gap measure
for the  address shortfall.. Now we have the solution we are
dragging the old junk along.. how silly...

This SL thing seems to me like a un-needed complication..

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Apr 2003 09:36:49 -0400

> I do NOT believe that introduction of link-local addresses causes far more 

I see scoped addressing as a general problem, of which v6 site-locals and v4
link-locals are both examples.  That said, I think v6 link-locals as "mostly
harmless" provided that we use them only for things like router discovery.
If we started expecting ordinary applications to be able to use them, I'd move
them back to the "harmful" category - they'd have most of the problems of
site-locals.

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 22 Apr 2003 06:56:04 -0700 (PDT)

Just one follow-on here - I'm seeing postings from others that
seem to imply that we need IESG review because that's where the
clue is, while Dave is pointing out that the IESG isn't the only
source of Internet architecture clue.

As I read Dave's note, this suggestion is an invitation for
people to develop clue before involving IESG folk, rather than
another black hole to absorb IESG time and effort (no matter how
noble the effort)...

Better for scaling, no?

SPencer

---

From: Bob Natale <[email-masked]>
Date: Tue, 22 Apr 2003 11:42:57 -0400

At 4/22/2003:09:56 AM, Spencer Dawkins wrote:

Hi Spencer,

Yes, you are right that inviting people to "develop
clue" before involving the IESG would be more scalable
(or at least it would reduce the workload in terms of
submitted documents! :-).  But I am doubtful about the
results of such an approach in terms of near-term quality
and productivity (e.g., "re-work" by some reviewing
body).

My own initial view was that *review* (and possible
revision) of such an "Architecture Considerations"
section should be done by the IAB.  I realize that
suggestion might be impractical from organizational
and/or procedural aspects that I am unfamiliar with
or have not fully considered.  But I was expecting
we'd need more "top down" control in this area...at
least in the beginning.

Speaking as a member of the hoi polloi, I am often
dismayed at how much I *don't* know about Internet-
wide architecture (e.g., mobile IP implications,
internationalization considerations, multi-media
transfer protocols, etc.) when thinking about the
*few* things I do understand a bit. :-(  On the
positive side, I comfort myself with the thought
that no *one* person knows it all...and am thankful
that groups like the IAB and IESG are out there
to protect the 'net from me!  :-)

Cheers,

BobN

---

From: Paul Vixie <[email-masked]>
Date: 22 Apr 2003 17:15:08 +0000

> rather than in this oblique fashion.

yesterday we had to change an AAAA RR and PTR RR because one of our
servers got a new GigE interface to replace the old FastE.  no part
of ipv6 renumbers seamlessly, from where i sit.

> with some stable view of layer-3 addressing from the layer above, 

we did.  it was called A6.  now we're apparently on to something else,
like for example nothing, or for example pretending it's not a problem
after all.
-- 
Paul Vixie

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Apr 2003 13:46:38 -0400

> like for example nothing, or for example pretending it's not a problem

a6 wasn't even a start of a solution to the renumbering problem.
at best, it was a distraction, and a disaster waiting to happen.

note that a6 wouldn't have done anything to relieve the burden associated
with the case you cited - a host changing its network interface.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 22 Apr 2003 13:54:03 -0400 (EDT)

Perhaps it would be easier without the PTR RR?

Then renumbering becomes a (possibly dynamic) update to the forward name.
Sounds pretty easy...

Regarding the second problem, Novell invented such a scheme many years
ago. It gave the host a separate network number and address from those of
the interfaces.  We approximate this scheme today in IPv4 using loopback
interfaces, frequently with /32 masks.  In this scheme, the interface
addresses are just part of the path to the host, but not actually the host
itself.

		--Dean

---

From: Paul Vixie <[email-masked]>
Date: 22 Apr 2003 18:40:02 +0000

> at best, it was a distraction, and a disaster waiting to happen.

i agree to disagree.

> note that a6 wouldn't have done anything to relieve the burden
> associated with the case you cited - a host changing its network
> interface.

true enough, but you can bet that if there were dns support for
the macroscopic problem, then i would be pushing some kind of dns
support for the microscopic problem as well.  as it is, there's
no foundation for it, other than campus-wide /128 "host" routes
which would scale poorly.
-- 
Paul Vixie

---

From: Rob Austein <[email-masked]>
Date: Tue, 22 Apr 2003 15:09:34 -0400

At Sun, 20 Apr 2003 08:47:43 -0700 (Pacific Standard Time), Terry Gray wrote:
> the context of firewalls.  Don't firewalls provide an even more
> random form of address scoping that apps must cope with?  Or not?

To a first approximation, firewalls are an attempt to impose tighter
scoping on applications that (in the opinion of the entity operating
the firewall) cannot be trusted to make their own scope decisions.
Very different trust relationship from a situation in which the
applications themselves chose between multiple address scopes.

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 22 Apr 2003 15:57:39 -0700 (PDT)

Hi, Rob,

I agree with your take from the network side, I'm thinking Terry
may be looking at it from the applications side (what's the
difference between one perfectly lovely address that fails
unpredictably and another perfectly lovely address that also
fails unpredictably? and the unknowable firewall topology is
probably within a first approximation of the unknowable site
topology).

But Terry can tell me I'm not thinking straight, if needed...

Spencer

--- Rob Austein <[email-masked]> wrote:
> plays in

---

From: David Morris <[email-masked]>
Date: Tue, 22 Apr 2003 16:35:31 -0700 (PDT)

> of ipv6 renumbers seamlessly, from where i sit.

IPV6 renumbering was guaranteed to always be problematic when the address
was defined to include the MAC address of the adapter. A mystery to me
from the day I first heard the design but since there is nothing I could
do to expect to change the design, I've not bothered to to try and
understand the rationale.

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Apr 2003 23:12:09 -0400

let me see if I can clarify this by restating it.

1. Apps know best what kinds of services they need.  The network doesn't know
this unless the app has some way of telling the network 
(e.g. TOS/QoS/diffserv/intserv/packet-class flavor-of-the-year).

2. The network knows best where hosts are located, and how to get packets from
here to there (if possible). The network also knows whether it's permitted to
send packets from here to there (perhaps limited by available routes or
policy, perhaps limited by packet filtering).  Most apps don't know these
things and shouldn't have to know them.  However it can be useful if the
network has some way to tell hosts and apps that it's not possible to get
packets from here to there, and the reason for that.  Traditionally ICMP has
fulfilled this role.

Now there are apps that have to know about network topology, such as network
management tools.  But in general we don't want to burden hosts and apps with
having to have this kind of knowledge, because there's no good way to get it
from the network, and to make it work reliably would require requiring the
network to feed routing and policy information to potentially all hosts.

3. Neither the kind of service being requested/provided nor information
about whether traffic is permitted should be wired into an IP address -
First because it forces a binding between policy and/or service and network
location which is inflexible and doesn't scale well; second because it
invites/begs/demands hosts and apps to know about network topology - i.e. to
second-guess the network.

4. Hosts shouldn't have to pick the "right" source or destination address in
order to get the network to do its job of getting the bits from here to there
(for some well-defined "here" and "there"), because hosts don't have the
requisite knowledge to do this, and because a requirement to pick the right
destination address means that addresses don't have a consistent meaning from
one source host to another.  To the extent that a host has to pick the "right"
interface, it needs to be possible to make the right choice from information
that the host normally has at hand (like matching prefix lengths).

Similarly, using address selection as a means to select a particular service
quality, or a particular security level, etc. is a best a stopgap measure 
because once again it requires apps to know about specific address ranges
and/or network topology.  

Note that scoped addresses make it difficult for each of the network, hosts,
and apps to do  their jobs - the network can't tell whether it can get the
traffic to the destination because the destination address is ambiguous (so
for instance, how can it tell the difference between "prohibited" and "no
route to destination" and "no such host" - and while it might have unambiguous
rules for how to route such addresses, that doesn't mean the traffic went to
the right place); hosts can't tell which interface to use to send the traffic;
and apps can't tell whether or not the address is usable to reach the desired
peer (either locally or by another peer).

--

Does any of the above mean that apps should never explicitly select source
and/or destination addresses or interfaces?  No, it means our network
architecture should not expect ordinary apps to make such selections
in order to sucessfully obtain services from the network. 

Now, because of mobile IP and privacy addresses, we're still going to have
situations where apps need to give their hosts an idea of what kinds of
addresses they need.  E.g. Does the app need an address that continues to work
as the host moves, or will the in-care-of address do?  Does it prefer an
address that is stably associated with the host, or is a temporary address
more appropriate?  But the answers to both of these questions *are* things
that the app can be expected to know.  Furthermore, unlike service quality or
security, these things inherently require address selection.  And unlike
site-local, these properties are essentially opaque to other hosts in the
network - thus we cannot expect/demand that other hosts use information
embedded in the address and behave differently for different kinds of
addresses.

And of course it will always be possible to set up or encounter situations
where apps that have knowledge about the network topology (or which
exhaustively try all known source/destination pairs) can succeed where apps
that don't go to extreme measures will fail.  In some ways this is an argument
about how we divide up the burden - which burdens we should place on hosts and
apps and which ones we should place on the network.  And the essence of the 
argument is:  don't expect either one to make decisions about things it
doesn't know about.  And this further argues for not having more addresses for
a host than necessary,  for not using multiple addresses as a mechanism to
provide different levels of access to a host, and for eschewing ambiguous
addresses.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Apr 2003 08:28:28 +0300 (EEST)

> understand the rationale.

Who said IPv6 addresses based on MAC addresses should be used on servers?

We certainly don't.  Manually configuring is the thing.

FWIW, that process could be simpler too, though.  But that's mostly
implementation issues.  An example is using RA's for setting default route
but not configuring the address, and manually configuring only the EUI64
part but using the advertised /64.  If it comes to making renumbering
easier, I might document these as ways to make it easier.

---

From: S Woodside <[email-masked]>
Date: Wed, 23 Apr 2003 03:16:44 -0400

> probably within a first approximation of the unknowable site

The differences:
- firewalls are a necessary evil for security, whereas site locals are 
(maybe) not
- firewalls are a simple on/off switch and easy to change, whereas site 
locals have complex state and are hard to change

Firewalls and NAT / site-locals might seem to be entangled, but it's 
just a coincidence. They both work best in the same place in the 
network, so many firewalls also do NAT.

simon

---

From: Tim Chown <[email-masked]>
Date: Wed, 23 Apr 2003 09:44:21 +0100

> We certainly don't.  Manually configuring is the thing.

although not with <prefix>::1, at least pick a random-ish 64-bit host
part to make the port scanners have to work rather harder...

tim

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Apr 2003 12:54:47 +0300 (EEST)

> part to make the port scanners have to work rather harder...

Yep.  For example, we use a very simple numbering which makes all the
hosts within a site unique (so, there will not be an address collision
even if server A is moved from link 1 to link 2 where server B is).

Works Just Great (tm).  (Except implementation support could be better 
:-).

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 23 Apr 2003 05:17:30 -0700 (PDT)

Dear Keith,

This posting was so helpful that we should probably change the
thread subject! 

I have a few questions/comments.

Spencer

> (e.g. TOS/QoS/diffserv/intserv/packet-class

Agreed.

> packets from here to there, and the reason for that. 

Agreed.

I would be thrilled if we spent some time thinking about ICMP in
an architectural way - however beautiful it was before ICMP
black holing, what we have now isn't consistently usable today.
We're spending time on point solutions (Matt Mathis on non-ICMP
path MTU discovery as one example), but is this the best we can
do?
> network to feed routing and policy information to potentially

Agreed. We've been discouraging hosts from listening to routing
protocol exchanges for some time now.

> second-guess the network.

Agreed.

> that the host normally has at hand (like matching prefix

Agreed.

> because once again it requires apps to know about specific

Strongly agreed here.

> peer (either locally or by another peer).

This was my point (perhaps I wasn't clear enough) about the
difference between site-local and firewalling - if your peer
isn't reachable because of an explicit decision from a network
operator (firewall), that's one class of problem; if your peer
isn't reachable because you have an address that doesn't work,
BUT YOU COULD HAVE BEEN GIVEN ANOTHER ADDRESS THAT WOULD HAVE
WORKED (site-local), that's a different class of problem.

The thing that bugs me is, I don't have any idea how the
application can tell that they have the second class of problem
- even ignoring ICMP Unreachable black-holing for a moment. Am I
missing something? (I don't think I'm a Genius of IPv6)

Agree.

> embedded in the address and behave differently for different

From RFC 3344, the current Mobile IP spec:

1.1. Protocol Requirements

[deleted down to]

   A mobile node must be able to communicate with other nodes
that do
   not implement these mobility functions.  No protocol
enhancements are
   required in hosts or routers that are not acting as any of
the new
   architectural entities introduced in Section 1.5.

And I agree I'm extrapolating, but - I always thought language
like this said Mobile IP is a host IP networking thing, not a
host application thing.

I'm not sure I'm understanding what you're saying - are you
saying that my mobile host should know it's mobile (I believe
you), or that Mozilla on a mobile host should know it's mobile
(I'm struggling here)?

My understanding of Mobile IP was that the mobile host knows,
not Mozilla (or, at least, Mozilla works if it doesn't know).

Re: security - are you thinking of applications that prefer
site-local (in IPv4, probably NATed 1918 addresses) for
"security", or is there another common use of
addresses-for-security I don't know about?

> provide different levels of access to a host, and for

Agreed, because I think you're using "hosts" and "apps" almost
interchangeably here, to mean "not the network".

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 07:42:08 -0700

Thank you, this was the only simple answer to the simple question. 

For the followup question: 
Do you believe that the IETF created the architectural concept of
addresses with a limited scope?

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Harald Tveit Alvestrand
> Sent: Tuesday, April 22, 2003 5:33 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: A simple question
> 
> 
> > Note: I cc'd the IETF list to catch those who may have been in the 
> > room in SF, but aren't on the IPv6 list.
> >
> >

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 08:01:51 -0700

Dave Crocker wrote:
> DS> Standards. This is a string of documents dating back to 1995. For 
> DS> eight years this concept was apparently considered a good thing.
> 
> The problem appears to have been that no one bothered to draw 
> the necessary implications and circulate them for explicit 
> consideration. So folks scanned a spec, didn't see anything 
> that looked egregious, and only now are realizing how 
> extensive the impact is.

What they are missing is that a defined prefix doesn't create the
problem that they are complaining about. Limiting the usable scope of
addresses is an operations decision. The mismatch between the
operational reality of limited scope addresses and the app developer
fantasy that there is a single flat routing space is the core problem
here.

Defining a prefix for those only made it *possible* for apps to
recognize which ones might be restricted. It does not *make* apps deal
with the problem of leaking addresses outside their scope of relevance
(unless you take the viewpoint that end users actually expect
applications to work right, and will require it once it is possible).
Applications are not required to understand topology, unless and until
they insist on passing around topology specific information. If any
process is going to pass around topology specific information, it MUST
understand the topology it is describing. 

There is no magic here, and defining a prefix didn't change the
architecture. Operational decisions established the architecture, and it
is our job to define the technologies that work within that
architectural reality. We can choose to continue to declare a
'flat-earth' and insist that applications and name resolution
infrastructure are free to arbitrarily pass around topology specific
objects, or we can choose to recognize the reality of the deployed
network and build the technologies that allow applications to operate
correctly within it. 

Tony

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 23 Apr 2003 17:33:03 +0200

> addresses with a limited scope?

no; I believe the community-that-became-the-IETF created the Internet by 
*denying* that concept, which was already well known long before TCP/IP.

Because of the realities of 32 bits of address in IPv4, that denial became 
more and more untenable as the years went by, until RFC 1597 
re-acknowledged the existence of such IPv4 addresses in 1994.

                   Harald

---

From: [email-masked]
Date: Wed, 23 Apr 2003 12:56:13 -0400

> missing something? (I don't think I'm a Genius of IPv6)

Nope.  That's the problem in a nutshell (almost).  One of the main b0rkedness
in site-local is almost exactly your second case - if your peer isn't reachable
because you've been given a site-local address that doesn't work because it's
mis-scoped, but you could have been given another global address that would
have worked.....

I'm having a hard time thinking of a case where an organization would have
a site-local that worked and global that didn't.  Using our net as an
example, AS1312 has 128.173/16 and 198.82/16.  If we *had* an IPv4 site-local
that covered both nets, I can't see any sensible reason to let those packets
pass, while preventing a host using a 128.173 address from using the 198.82
address of a peer.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 10:12:08 -0700

> re-acknowledged the existence of such IPv4 addresses in 1994.

Though IP addresses that were only reachable from a limited part of the
network existed long before 1994. These were implicit through filtering
of routing announcements, or explicit through access control mechanisms.
So to clarify the question, do you believe the establishment of a set of
local use prefixes is the root cause of the unsolved problems that
applications developers are complaining about? 

Tony

---

From: Daniel Senie <[email-masked]>
Date: Wed, 23 Apr 2003 14:28:44 -0400

>applications developers are complaining about?

There will always be addresses which are administratively scoped, 
regardless of whether those addresses are from global space, or from 
RFC1918 (or equivalent) private space. That scoping will be instituted by 
policy at border routers, firewalls, and even filtering mechanisms on hosts 
(which may be outside the view of the applications, such as how IPTables 
operates on *nix machines.) The IPv6 mechanism to give hosts a-priori 
knowledge that the "site local" block is flawed in that it cannot truly 
provide the scoping information, since it does not address the wider issues 
associated with administrative address scoping. Indeed, the site local 
mechanism reminds me in a way of Steve Bellovin's "evil" bit in his RFC 
published on the first day of this month.

There will remain a need and desire for private address space, be that the 
assigned "site local" block (without the "special treatment" in the 
stacks), RFC 1918 space, or a combination. I think it would be useful to 
decouple the issue of the special treatment of the Site Local address block 
from the religious war over whether private address space and other 
mechanisms sometimes associated are beneficial or not. In reviewing the 
recent discussion, it is clear the two are being intertwined, and it 
appears to be adding to the heat, and producing no light.

Separately, if there is genuine interest in addressing the scoping problem, 
I suggest that be addressed separately. A proper effort might encompass 
mechanisms to deliver indications to applications as to the scoping 
limitations causing communications to be blocked, as well as wire protocol 
issues to carry such signalling. In a broader sense, there is a need to 
deal with signalling issues as well. There are network operators, firewall 
vendors and network administrators who've been taught ICMP packets are 
inherently dangerous and must be filtered. The work output of such efforts 
should span the Internet Area producing standards track documents to 
specify how to properly implement mechanisms in hosts, routers and 
firewalls, and the Operations Area to provide BCPs giving guidance to 
network administrators and service providers on the operational needs of 
such issues.

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Apr 2003 15:24:24 -0400

--On Wednesday, 23 April, 2003 14:28 -0400 Daniel Senie 
<[email-masked]> wrote:

>> So to clarify the question, do you believe the establishment
>> of a set of local use prefixes is the root cause of the
>> unsolved problems that applications developers are
>> complaining about?
>
> There will always be addresses which are administratively
> scoped, regardless of whether those addresses are from global
> space, or from RFC1918 (or equivalent) private space. That
> scoping will be instituted by policy at border routers,
> firewalls, and even filtering mechanisms on hosts (which may
> be outside the view of the applications, such as how IPTables
> operates on *nix machines.) The IPv6 mechanism to give hosts
> a-priori knowledge that the "site local" block is flawed in
> that it cannot truly provide the scoping information, since it
> does not address the wider issues associated with
> administrative address scoping. Indeed, the site local
> mechanism reminds me in a way of Steve Bellovin's "evil" bit
> in his RFC published on the first day of this month.

Yes!

> There will remain a need and desire for private address space,
> be that the assigned "site local" block (without the "special
> treatment" in the stacks), RFC 1918 space, or a combination. I
> think it would be useful to decouple the issue of the special
> treatment of the Site Local address block from the religious
> war over whether private address space and other mechanisms
> sometimes associated are beneficial or not. In reviewing the
> recent discussion, it is clear the two are being intertwined,
> and it appears to be adding to the heat, and producing no
> light.

Also Yes.

> Separately, if there is genuine interest in addressing the
> scoping problem, I suggest that be addressed separately. A
> proper effort might encompass mechanisms to deliver
> indications to applications as to the scoping limitations
> causing communications to be blocked, as well as wire protocol
> issues to carry such signalling. In a broader sense, there is
> a need to deal with signalling issues as well. There are
> network operators, firewall vendors and network administrators
> who've been taught ICMP packets are inherently dangerous and
> must be filtered. The work output of such efforts should span
> the Internet Area producing standards track documents to
> specify how to properly implement mechanisms in hosts, routers
> and firewalls, and the Operations Area to provide BCPs giving
> guidance to network administrators and service providers on
> the operational needs of such issues.

Yes!!!!

Tony, I think this pretty well reflects where I've found myself 
going on this, fwiw.   From an applications standpoint, the 
scoping issues, and what is, or is not, "topology information", 
just obscure the problem.  "The problem", from an applications 
point of view, is that, if we are going to stop pretending that 
the address space is completely flat and global --and I agree 
that to do otherwise is unrealistic at this stage-- then we need 
a model by which the application can specify to the stack what 
it needs/ expects, and the stack can tell the application 
whatever the latter really needs to know about what is 
happening.   Of course, to do that, the stack may need to be 
able to pass directions to the network or make inquiries and get 
information back.  But, to the degree to which we believe in 
layered protocol stacks at all (hourglass or otherwise), the 
application should be totally insensitive to where the stack 
layer(s) with which it communicates get their information.

Having the application try to figure this all out by breaking 
down IPv6 addresses (site local or otherwise) just isn't the 
right way to do it --at least without a really drastic 
rethinking of the architecture.   That is partially because of 
the flip side of the arguments I've understood you to be making 
about scope: the application can't know enough in our current 
model to do the right thing, and knowing about how to handle one 
particular address prefix or format won't make a serious dent in 
the problem. ICMP, as now defined and used, won't help with the 
problem for a reason much more pervasive than the one Daniel and 
others have identified: most of our current applications have no 
interaction with either ICMP or IP -- they call on TCP or UDP 
functions and don't know about the internet layer.  The Internet 
layer doesn't have any path (by "signalling" or otherwise)to 
pass information back to the apps.

So, I would suggest that we really do have a problem here. 
Unless we have a realistic proposal for a routing fabric that is 
not dependent on the addresses used, the solution-set almost 
certainly includes being able to use multiple addresses per 
host, with different semantics associated with those addresses. 
As the competence level of the average ISP declines (which seems 
to have been a clear trend for the last several years), 
multihoming (in some form) needs to increase as the only 
satisfactory alternative... and it better not be only for the 
rich or the huge.  The idea of a single, exclusively-global, 
flat address space has been history for years; we clearly aren't 
going to get back there as long as different providers charge 
differently for different paths (independent of any of the 
enterprise localization, firewall, RIR-granted PI space, or 
other issues).

But, unless we are prepared to discard the model of a layered 
stack architecture, or accept our applications becoming as (or 
more) complex and knowledgeable about network architectures as 
switches get in the PSTN, then we should be looking at stack 
abstractions that permit applications to express their needs, 
and get information back, without deducing network topology, 
transport or mobility economics, etc.  Maybe that  to get there 
means that we need to revisit, not just ICMP as Daniel suggests, 
but the "no TCPng" decision... I don't know.  But, if we can 
figure out a way to clean this up and make it work well, we 
could easily end up with a stronger justification for deploying 
IPv6 than anything (at least anything real) we have had to date.

Where does SL and its relationship to applications fit into 
this?  Oddly, I don't think it does except in the very useful 
sense of having (finally) forced a broader range of people to 
think about the problem.   From an application-writer/designer 
standpoint, I know I don't want to think about SL (nor do I want 
to think about RFC 1918 addresses or anything else that requires 
me to make decisions I don't have the needed information to 
make).  I'm not opposed to those addresses existing, or in favor 
of them, I'm just committed to a network and implementation 
model in which they are kept below me in the stack. 
Consequently, the only thing I want to need to know about an IP 
address is how to pick it up from one source, carry it around 
opaquely, and ultimately pass it to something else or use it in 
an opaque way in a protocol transaction.  The challenge to those 
of you who are for, or against, SL at the IP level is to justify 
it in a context in which applications really don't need to know 
anything about them, or other address scope/ reachability/ 
routability issues except through the addressing-independent 
abstractions that we can agree on.  If the applications don't 
need to know, and can function in a multiple-address-per-host 
environment without --in the application-- having to determine 
which one to use by some type of iteration process, then you 
need to justify specialized addresses only in terms of their 
requires lower in the stack.  If the applications do need to 
know, then the complexity costs appear to be high enough to 
present an insurmountable barrier.

  regards,
        john

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 12:25:29 -0700

Daniel Senie wrote:
> ... The IPv6 mechanism to give hosts a-priori 
> associated with administrative address scoping. 

You assume an outcome ('flawed') without first discussing the full set
of requirements. 

> appears to be adding to the heat, and producing no light.

I have no argument with discussing them separately, as long as we don't
end up with the usual discussion where it is the private address space
causing the problems. There is a general lack of recognition that
private addresses only exposes the underlying mis-match in the
perceptions of scope. 

> scoping problem, 
> I suggest that be addressed separately. 

Reset your clocks to 1995 ...

> A proper effort might encompass 
> issues to carry such signalling. 

You assume such signaling would somehow solve the problem of A using a
literal referral to C that Bl is the address it is using, when C can
only see Bg. How is A supposed to know that Bl has a scope limitation
when it can get there without receiving any signaling? How is the
infrastructure supposed to know that A intends to tell C a literal
address rather than a name? If Bl & Bg had indicators of scope
differentiation in the prefix, A could recognize the difference if it
bothered to look. It wouldn't have to, but if it didn't it would either
have to refer the name, or provide C with the entire list so it could
figure out which one works. Brian's C000 thread was exploring this
space. 

> In a broader sense, there is a need to 

I agree education is appropriate. Part of that is educating the
application development community that the real network has addressing
with limited scopes of relevance, so blindly assuming a flat routing
space and passing around topology specific information will result in
broken apps.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 15:26:07 -0400

> path MTU discovery as one example), but is this the best we can

I don't think we're likely to be able to dispense with ICMP.  Maybe we
can find more ways to make it more trustworthy.  Or maybe we just need
to discourage people from filtering it.

> > Note that scoped addresses make it difficult for each of the
> > network, hosts, and apps to do  their jobs - the network can't tell
> > whether it can get the traffic to the destination because the
> > destination address is ambiguous (so for instance, how can it tell
> > the difference between "prohibited" and "no route to destination"
> > and "no such host" - and while it might have unambiguous rules for
> > how to route such addresses, that doesn't mean the traffic went to
> > the right place); hosts can't tell which interface to use to send
> > the traffic; and apps can't tell whether or not the address is
> > usable to reach the desired peer (either locally or by another
> > peer).
> 

What I want to say is that if the peer isn't reachable because the
host or application didn't choose the right source or destination
address, this is never the host or the application's problem - it's
always the network's problem - because I don't see any way to allow 
hosts and apps to reliably make the "right choice" in the absence of
routing information, and which allows addresses to be used in referrals.
(and while separating endpoint identifiers from addresses might be a
laudible architectural goal, we're nowhere near being able to integrate
it into the current archtitecture).

> > Now, because of mobile IP and privacy addresses, we're still going
> > to have situations where apps need to give their hosts an idea of
> > what kinds of addresses they need.  E.g. Does the app need an
> > address that continues to work as the host moves, or will the
> > in-care-of address do?  Does it prefer an address that is stably
> > associated with the host, or is a temporary address more
> > appropriate?  But the answers to both of these questions *are*
> > things that the app can be expected to know.  Furthermore, unlike
> > service quality or security, these things inherently require address
> > selection.  And unlike site-local, these properties are essentially
> > opaque to other hosts in the network - thus we cannot expect/demand
> > that other hosts use information  embedded in the address and behave
> > differently for different kinds of addresses.  
> 
> that do not implement these mobility functions.  No protocol
> enhancements are required in hosts or routers that are not acting as
> any of the new architectural entities introduced in Section 1.5. 
> 

I'm saying that if your application knows that a particular connection
is only likely to be open for a short time, and/or that it can reliably
recover from broken connections, and that the source address isn't going
to be used for referrals to peers on other hosts, then it might want to
somehow tell its TCP/IP stack this, so the stack can use the in-care-of
address as the source address rather than the home address, thereby
bypassing any tunneling that might otherwise take place.  

Which isn't quite the same thing as letting an app know it's on a mobile
host - though that would also be useful for some apps.  

> addresses-for-security I don't know about?

I don't think address selection is an appropriate means for an
application to specify security.  That's what IPsec and/or TLS are
for.  (and yes, we need IPsec APIs)  

nor do I think that an application should invest greater or less trust
in traffic that is sourced from or sunk to a particular address, at
least not without specifically being configured to do so, and certainly
not based on whether the address is site-local.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 12:56:47 -0700

John C Klensin wrote:
> ... Maybe that  to get there 
> but the "no TCPng" decision... I don't know. 

Maybe that is the path out. 

>  But, if we can 

Depends on where you are in the world, and how much IPv4 address space
you are sitting on. I am aware of organizations in the US today that
can't get enough IPv4 address space fast enough by current ARIN policy
to meet a viable business plan for ramp up rate. 

> ... I'm just committed to a network and implementation 
> an opaque way in a protocol transaction. 

But you just said you wanted to keep it below you in the stack. You
can't have it both ways... You either get to keep it below you by
passing around name objects, or you are taking on the responsibility of
getting it right because you are passing around topology information.

>  The challenge to those 
> abstractions that we can agree on.  

I don't care if it is TCP-ng, or something else between IP & the app
that takes care of figuring out the topology difference, but signaling
by itself won't solve the problem of literal referrals. If the app is
going to insist on passing around topology information, it has to make
sure that matches the topology being used.

> If the applications don't 

The current IPv4 network already requires this of applications, the
developers simply choose to ignore reality. There is nothing different
in a unique prefix for local use, other than the ability for the app
(stack) that chooses to look to figure out that some pairings won't
work. If the app does as it currently will and passes an out-of-scope
address, the application will fail. This is not a new requirement, it is
simply exposing the fact that applications have been ignoring reality
for a long time now. If there are other ways to mitigate the issue, I am
all for developing them. My primary issue is that there are a variety of
things people want to use SL for and removing an existing mechanism
without appropriate replacements for all of them first is an
irresponsible act.

Tony

---

From: S Woodside <[email-masked]>
Date: Wed, 23 Apr 2003 16:49:48 -0400

On Wednesday, April 23, 2003, at 03:24  PM, John C Klensin wrote:

>  As the competence level of the average ISP declines (which seems to 
> have been a clear trend for the last several years), multihoming (in 
> some form) needs to increase as the only satisfactory alternative... 
> and it better not be only for the rich or the huge.

Yes!

Speaking from the Community Wireless Networking perspective, massive 
multihoming is a really good thing not just because of the problems 
with ISPs but because it's the most /appropriate/ (not necessarily 
easiest to wrap mind around) solution to the classic problem of CWN: I 
have this mesh of fixed homes with various antennas on their roofs 
pointing at each other ... some of them have ISP accounts some don't 
... how do I start routing traffic through there from internal nodes to 
other internal nodes, or from inside to outside and vice-versa???

(a current solution using NAT (meshAP/locustworld) is not the answer 
... various tunnelling methods would squander bandwidth)

simon

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 23 Apr 2003 13:55:34 -0700 (PDT)

OK, I AM intrigued by this:

> to discourage people from filtering it.

Any thoughts on the effectiveness of a BCP that says, message
type by message type and return code by return code, "filtering
this at a network edge does/does not make sense"?

We've been digging our toes in the sand on a Phil Karn proposal
to do TCP far-end link-up notification via retransmitted TCP
packets (for a few years). Architecturally, this is the kind of
thing ICMP is meant for, but I'm told repeatedly that new
ICMP-based mechanisms are non-starters on today's network...

Spencer

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Apr 2003 13:57:13 -0700

Tony,

On Wednesday, April 23, 2003, at 12:56  PM, Tony Hain wrote:
> I am aware of organizations in the US today that

As this would appear to be an indication of a failure of allocation 
policy, a discussion of details on an appropriate list ([email-masked] 
would probably be best) would be appreciated.

Rgds,
-drc

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 17:59:37 -0400

> addresses is an operations decision. 

Tony, this discussion is about ambiguous addresses.  Your persistent
attempt to conflate it with packet filtering and/or routing policy isn't
shedding any light on the argument.  And you're smart enough to know
the difference.

> recognize which ones might be restricted.

But it doesn't help apps know *how* those addresses are restricted.

>  It does not *make* apps deal

Experience indicates that this is exactly what happens.  You cannot
expect apps to not leak addresses outside of their scope because apps do
need to pass addresses around and they have no way of being aware of
their scope boundaries.  The way to solve this problem is to make
addresses unique.

> they insist on passing around topology specific information. 

Another attempt at disinformation on your part.  The fact that the
current internet architecture doesn't provide us with reliable endpoint
identifiers that are independent of topology information is not a
justification for asserting that applications should not pass around the
best endpoint identifiers that are available to them.  And very few
applications use these as anything other than opaque tokens.

> architecture. 

defining a prefix didn't change the architecture - asserting that the
same prefix could be reused in multiple locations did change the
architecture.

> Operational decisions established the architecture, and
> it is our job to define the technologies that work within that
> architectural reality.

indeed.  this is precisely why we are deprecating site locals - because
they do not work within the architectural reality.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 18:07:31 -0400

> If the app is

agreed.  and by far the easiest way to do this is to have all points on
the network use consistent names for points in the network topology.

the real problem is that people have been conditioned to believe that
ambiguous addresses are a security feature, when what this actually
serves to do is reduce their ability to apply security in depth.

> developers simply choose to ignore reality. 

until recently 'reality' was that the vast majority of ipv4 hosts had
only one network interface, and one address, and most of the rest
of the hosts could act as if they only had one interface and one
address.  so application writers were paying attention to reality, even
if they weren't handling (or able to handle) every case that might
potentially arise.

> My primary issue is that there
> are a variety of things people want to use SL for and removing an
> existing mechanism without appropriate replacements for all of them
> first is an irresponsible act.

we need a list of these things, so we can work on a list of
replacements.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 18:12:27 -0400

> space and passing around topology specific information will result in

This is ridiculous.  Tony, we understand that we don't have a
completely connected network.  We've understood that for years. 
But we're not willing to adopt your delusions that this is the same
problem as having ambiguous addresses.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 15:47:37 -0700

Keith Moore wrote:
> Tony, this discussion is about ambiguous addresses.  Your 
> persistent attempt to conflate it with packet filtering 
> and/or routing policy isn't shedding any light on the 
> argument.  And you're smart enough to know the difference.

Yes, but you keep changing the argument. On 4/18 it was:
>> introduction of scoped addresses causes far more problems than it
solves.

Today it is ambiguity. I was trying to separate the discussion by
focusing explicitly on the scoped address issue. 

> But it doesn't help apps know *how* those addresses are restricted.

No, but a limited hint is useful in many situations. Should we have
better tools? By all means. That does not mean we get rid of something
that has some utility before we show that it has none because there are
alternatives.

> Experience indicates that this is exactly what happens.  You 
> cannot expect apps to not leak addresses outside of their 
> scope because apps do need to pass addresses around and they 
> have no way of being aware of their scope boundaries.  The 
> way to solve this problem is to make addresses unique.

I do not buy the assertion that 'apps need to pass addresses around'. It
is possible for apps to choose passing around names and let the topology
get sorted out by the name resolution infrastructure. As I said to JCK,
you can't have it both ways. You can either choose to keep it all below
the app layer by passing around names, or if the app chooses to reach
down and get topology information it has bought into the responsibility
to understand what it is doing.

> Another attempt at disinformation on your part.  The fact 
> that the current internet architecture doesn't provide us 
> with reliable endpoint identifiers that are independent of 
> topology information is not a justification for asserting 
> that applications should not pass around the best endpoint 
> identifiers that are available to them.  And very few 

You insist on the right to reach down and get lower layer information,
but refuse to accept the responsibility that goes along with having it.
??? If the app chose to use a name as the endpoint identifier, it would
have the conflict.

> defining a prefix didn't change the architecture - asserting 
> that the same prefix could be reused in multiple locations 
> did change the architecture.

This is more an argument to define ways to disambiguate the current
space than it is to remove a well-known prefix for use in local scopes.
Get your arguments straight, and you will realize all this deprecate SL
nonsense is a waste of time. We need to solve the fact that apps refuse
to acknowledge they are ignoring topological reality, and the ambiguity
argument become simply a matter of subnet routing collisions during
mergers.

> indeed.  this is precisely why we are deprecating site locals 
> - because they do not work within the architectural reality.

No, the apps that insist on reaching down and getting lower layer
information that they don't understand is what doesn't work. Deprecating
SL makes absolutely no difference to this, because the same issues will
crop up for globally unique local scope addresses. Before you say it,
the 'connect to the wrong node' argument is an IPv4 artifact. With IPv6
auto-conf, or even manual conf using a discarded MAC, the probability of
a SL address actually pointing to two nodes is close to zero, and even
lower than that for those both being reachable from participants in the
same multi-party app. 

Go back through all your arguments about the evil's of SL, and see how
many go away if the prefix is disambiguated. Then look at the fact that
A can't tell C the difference between Bl & Bg unless there is some
indicator. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 15:51:40 -0700

> we need a list of these things, so we can work on a list of 

I am accepting comments for:
http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-00.txt

Tony

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 23 Apr 2003 17:44:31 -0500

Thus spake "Tony Hain" <[email-masked]>
> If Bl & Bg had indicators of scope differentiation in the prefix, A could
> recognize the difference if it bothered to look. It wouldn't have to, but
> if it didn't it would either have to refer the name, or provide C with the
> entire list so it could figure out which one works. Brian's C000 thread
> was exploring this space.

"Global" addresses can be scoped by administrative/security devices just as
easily as non-globals, so a scope indicator in the address is merely a hint
which may lead the app/stack astray.  The only way to determine if a given
address, global or otherwise, will work is to try using it.

SL does not solve -- nor did it create -- this problem any more than RFC1597
did.

S

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Apr 2003 15:53:36 -0700

Keith Moore wrote:
> But we're not willing to adopt your delusions that this is 
> the same problem as having ambiguous addresses.

I am focusing on your 4/18 assertion: introduction of scoped addresses
causes far more problems than it solves.

I am not talking at all about ambiguity.

Tony

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 23 Apr 2003 18:08:27 -0500

> shedding any light on the argument.  And you're smart enough to know

And you're conflating ambiguous addressing with scoping.

> You cannot expect apps to not leak addresses outside of their scope
> because apps do need to pass addresses around and they have no
> way of being aware of their scope boundaries.  The way to solve this
> problem is to make addresses unique.

Give everyone global addresses and the scoping problem remains unchanged.
Even "global" addresses are scoped by administrative or security policies.

Having a prefix set aside for private addresses, whether SL or RFC1918, is
convenient for humans, that's all.  It may make scoping easier or more
common, but it's not the cause.

> same prefix could be reused in multiple locations did change the

Perhaps.  There is no functional difference unless multiple instances of the
same address are actually _reachable_ by a third party; the mere existence
of duplicates does not change the architecture.

S

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 19:34:13 -0400

> > attempt to conflate it with packet filtering and/or routing policy
> > isn't shedding any light on the argument.  And you're smart enough
> > to know the difference.
> 

nope.  the property that I'm concerned about is not that an address
may only be usable within a particular portion of the network, it's
that the address is ambiguous.  so given an address there's no way to
know whether or not it is valid, or why it doesn't seem to work to let
you connect with the host/peer/server you think it's associated with.

> > defining a prefix didn't change the architecture - asserting that
> > the same prefix could be reused in multiple locations did change the
> > architecture.
> 
> Perhaps.  There is no functional difference unless multiple instances
> of the same address are actually _reachable_ by a third party; the
> mere existence of duplicates does not change the architecture.

wrong.  it's useful to have unique names for hosts (or points on the
network) even if they're not directly reachable by everyone who might
possess those names.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 19:38:25 -0400

> >  Tony, we understand that we don't have a 

ambiguity is certainly one class of problems that site locals cause.

now whether you define scoped addresses as "names for locations in the
network whose meanings are relative to a particular subset of the
network, and which may have other meanings in other subsets of the
network", or "addresses are only reachable from a particular portion of
the network" is, I suppose, fairly arbitrary. I've been using the former
definition.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 23 Apr 2003 18:29:18 -0500

> > My primary issue is that there are a variety of things people want to
> > use SL for and removing an existing mechanism without appropriate
> > replacements for all of them first is an irresponsible act.
>

Top of the list: a portable but unroutable prefix, say a /48, that doesn't
require recurring fees to an RIR or ISP.  I don't require it to be unique
(since it's unroutable), but that's your call.

S

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 19:59:00 -0400

> that has some utility before we show that it has none because there
> are alternatives.

it's not as if all of the utility for scoped addresses is positive.  it
does make sense to get rid of things with significant negative utility,
particularly when the supposed positive utility is not compelling.

site-local is not useful as a limited hint that the addresses are
restricted, because the scope of such restrictions is still invisible to
apps, and because there is no policy for use of site-local by apps which
will work reliably across different network setups. and any measures
that apps might undertake to work in the presence of site-locals will
work even better (more efficiently and more reliably) if globals are
used.

> I do not buy the assertion that 'apps need to pass addresses around'.

you're simply mistaken about that.  until we have reliable, universal, 
distinguished names for (possibly virtual) hosts that can be used as
endpoints in TCP and UDP, etc., and as long as there is ever a need
to unambiguously refer to a network location, we're going to need to
pass addresses around.

> It is possible for apps to choose passing around names and let the
> topology get sorted out by the name resolution infrastructure.

not in any naming system that we have today, or are likely to have
deployed within ten years.

> As I said to JCK, you can't have it both ways. You can either choose
> to keep it all below the app layer by passing around names, or if the
> app chooses to reach down and get topology information it has bought
> into the responsibility to understand what it is doing.

not if the app treats the addresses as opaque tokens. 

> but refuse to accept the responsibility that goes along with having
> it.???

overloading of IP addresses to be multiple things (among them endpoint
identifiers, interface identifiers, network locations, host
identifiers, even authentication principals) is deeply embedded in the
IP architecture.  you may think it's a poor compromise, and lots of
people would agree with you.  but nobody has demonstrated a
complete solution that appears to be a better way for things to work. 
and given this deliberate overloading, it's disingenous for you to claim
that addresses are inherently lower layer information (more correctly,
they're shared between layers), and that apps that use addresses as
opaque tokens somehow have some new responsibility for dealing with
ambiguity that you've decided to burden them with.

> space than it is to remove a well-known prefix for use in local

I don't believe there is a good way to disambigate the current SL space;
there simply aren't enough bits available.  Nor do I believe (for
reasons cited elsewhere) that it is desirable to burden hosts and apps
with having to deal with more addresses than are necessary to name the
network locations to which they are attached, nor to embed information
about reachability within addresses, nor to expect hosts and/or apps to
select the "right" set of addresses to get from point A to point B.  

so there are indeed other problems with site local even if you make them
globally unique; it's just that lack of uniqueness is the worst problem.

> information that they don't understand is what doesn't work.

wrong.  if they tried to treat those identifiers as anything other than
opaque tokens, I might agree with you.  but very few apps do that, and
I'm not worried about those that do.  indeed, it's the expectation that
apps need to start treating addresses as other than opaque tokens, for
instance by having to use different addresses in different situations
in order to reach the same point on the network, that I'm arguing
against.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Apr 2003 17:38:51 -0700

Folks,

I would like to strongly encourage everyone to recast this discussion
from the perspective of the Senie/Klensin postings.  They are cogent,
coherent and constructive.  They even smack of serious architecture.

And that is more than most of the rest of this thread can claim.

d/

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 21:31:56 -0400

Daniel Senie writes:

> > scoping problem, I suggest that be addressed separately.

I guess it depends on what you define as "the scoping problem".  If the
problem is that the network can impose apparently arbitrary restrictions
on whether hosts can communicate between point A and point B (for
arbitrary A and B) I don't see that as an architectural problem, nor
something that should be the responsibility of applications to solve. 

and if you define the problem as that hosts are expected to be able to
simultaneously have access to multiple scopes that must be accessed via
different source addresses or different network interfaces or different
tunnels, and to be able to provide connectivity to each of those for
applications on that host, I still have to question whether giving each
scope a separate address prefix is a constructive way to implement that.

so is there a definition for "the scoping problem" that you have in
mind?

> whatever the latter really needs to know about what is 

I don't see why it's unrealistic to have a global address space that
encompasses all hosts that are connected any network that is connected
to the Internet, and to expect applications to use that global address
space.  I agree that we cannot expect complete or near-complete
connectivity.

In my mind, the reason we need feedback from the network to applications
about when applications try to violate administrative prohibitions on
use of the network is not so that applications can try to route the
messages through other paths (though it does enable that to some
limited degree) but so that applications can provide accurate
indications to their users as to why they're failing.

> ICMP, as now defined and used, won't help with the 
> layer doesn't have any path (by "signalling" or otherwise) to 

I don't see why TCP and/or UDP stacks can't provide such interfaces
to applications, even though of course this means that there will need
to be other interfaces (invisible to applications) between TCP and IP
and UDP and IP to pass that information upstream.

> host, with different semantics associated with those addresses. 

the solution set to what?  I don't see what problem this is attempting
to solve, but I do see lots of problems that this creates.

> enterprise localization, firewall, RIR-granted PI space, or 

radical idea: we need to get away from the notion that the IP address is
a path specifier and back to the notion that an IP address is a
location or interface identifier or (possibly virtual) host identifier.

> transport or mobility economics, etc. 

I don't think these things need to be provided in the "stack" at all -
for the same reason that apps don't want to cope with them - neither the
host nor the app has the information needed to make those decisions. 
and lacking a uniform address space, there's no basis for lower layers
to make the decisions.  (for some reason a potentially-changing set of
IP addresses doesn't strike me as a good endpoint identifier for any
layer)  so we need a uniform location name space to be used by higher
layers, and we need for the network to make the path selection
decisions.  now maybe these decisions need to be made at border routers
rather than core routers (so that finer details of path selection are
handled in the periphery where you get better scaling, and the core
routers just forward things along pre-determined paths) but you don't
want to push the routing information all the way to hosts.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 23 Apr 2003 20:41:42 -0500

> that the address is ambiguous.

As Mr. Hain pointed out, last week your argument was about scoping and apps
picking addresses, not about private addresses.

> so given an address there's no way to know whether or not it is valid,
> or why it doesn't seem to work to let you connect with the
> host/peer/server you think it's associated with.

You have no way of knowing if any address is reachable from any particular
location.  That is not a property specific to private addresses.

> network) even if they're not directly reachable by everyone who might

Useful, yes; a fundamental part of the architecture, no.

Removing private addresses from the IPv6 architecture is a fundamental
change from IPv4: site-locals are not a new addition, just a different name.

If site-locals are deprecated, the NAT/stable address/whatever crowd will
just pick a different prefix to use.  Worst case, they'll all pick different
ones.  RFC1597 didn't cause the scoped-address mess; it just provided a
reasonably safe sandbox and standard semantics.

S

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Apr 2003 22:12:35 -0400

> As Mr. Hain pointed out, last week your argument was about scoping and
> apps picking addresses, not about private addresses.

indeed, there are several arguments.  ambiguity is the biggest problem,
but there are others.  nor are they independent of one another - the
problems interrlate.  having ambiguous addresses makes the address
selection problem more difficult, but the need to employ address
selection is a problem even if all addresses are global. also, when I've
been using the word "scoping" I've been talking about the scope in
which an address is defined (has a well-defined meaning) rather than the
scope in which an address could be used- I argue that we need globally
scoped addresses even if they can only be used within a limited portion
of the network.

> > so given an address there's no way to know whether or not it is
> > valid, or why it doesn't seem to work to let you connect with the
> You have no way of knowing if any address is reachable from any
> particular location.  That is not a property specific to private
> addresses.

they're different.  if you have a globally scoped address you can
try to send to it, and the network will make a best effort to get it
there, modulo policy.  if it doesn't know how to get the packet there,
and the network "should" send an ICMP that explains the reason it can't
get there.  and that address will reach the same location/host from any
point in the network. 

if you have an ambiguous address you can try to send to it, but the
network can't tell where it's intended to go.  to the extent that the
network tries to route it somewhere, it may not end up at the
location/host the sender intended, and there's no way for anyone to know
that the packet is being misrouted.  if an error is returned it is
pretty much useless - either the host is down or the network interpreted
the address in a different scope that was intended or the sending host
picked the wrong interface.

note that if you had a globally unique address that only works within a
limited scope, it acts like any other globally scoped address.

> > > Perhaps.  There is no functional difference unless multiple
> > > instances of the same address are actually _reachable_ by a third
> > > party; the mere existence of duplicates does not change the
> > > architecture.
> >
> > network) even if they're not directly reachable by everyone who
> > might possess those names.
> 

disagree.  the internet protocol fundamentally depends on addresses
being global - routing between arbitrarily connected IP networks cannot
work without this property.  furthermore there are several deep
assumptions that IP addresses are uniquely assigned to hosts - for
instance, IP addresses are used as TCP endpoint identifiers, and
round-trip estimates are made on a per-host basis.

> change from IPv4: site-locals are not a new addition, just a different

False.  IPv4 only had private addresses for use in isolated networks,
and this was a late addition, and we've learned from experience that
this was a mistake.

> If site-locals are deprecated, the NAT/stable address/whatever crowd
> will just pick a different prefix to use. 

and the boogey man will come, and we'll all be attacked by terrorists
flying cessna 172s.  sorry, but I'm sort of fed up with living in a
country that does its best to control its citizens through irrational
and ungrounded fear, all the while pretending that it's good for you and
ignoring the real problems that exist.  I've got a pretty low tolerance
for such tactics these days.

yes, we have to give people good ways to solve real problems that they
have.  no, we don't have to legitimize every bad idea that people have
put into practice merely because somebody is doing it.

Keith

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Apr 2003 22:55:23 -0400

--On Wednesday, 23 April, 2003 12:56 -0700 Tony Hain 
<[email-masked]> wrote:

>> means that we need to revisit, not just ICMP as Daniel
>> suggests,  but the "no TCPng" decision... I don't know.
>
>> could easily end up with a stronger justification for
>> deploying  IPv6 than anything (at least anything real) we
>> have had to date.
>
> Depends on where you are in the world, and how much IPv4
> address space you are sitting on. I am aware of organizations
> in the US today that can't get enough IPv4 address space fast
> enough by current ARIN policy to meet a viable business plan
> for ramp up rate.

I want to leave most of that discussion for some ARIN-related 
list, as David Conrad suggested.  But, for the record, I was 
trying to dodge the question of whether address space 
exhaustion, by itself, was  "strong enough" or "sufficient" 
reason to get IPv6 deployed and, especially, to avoid the 
rathole-populating discussion about alternatives.  Since I am on 
record as believing that, by some reasonable measures, we have 
already run out of address space and IPv6 is not yet widely 
deployed, I would suggest that we have a solid example that it 
has not [yet?] proven to be sufficient.

>> Consequently, the only thing I want to need to know about an
>> IP  address is how to pick it up from one source, carry it
>> around  opaquely, and ultimately pass it to something else or
>> use it in  an opaque way in a protocol transaction.
>
> But you just said you wanted to keep it below you in the
> stack. You can't have it both ways... You either get to keep
> it below you by passing around name objects, or you are taking
> on the responsibility of getting it right because you are
> passing around topology information.

I strongly suspect that we are using words in ways that results 
in miscommunication, because I think there is a third 
alternative.  That alternative may fall into the category you 
describe as "passing around name objects", or maybe it doesn't. 
>From my perspective --which is definitely the applications end 
of the stack looking down-- the problem is all about data 
abstraction.  I'm going to try to switch terminology here in the 
hope that it will help clarify things.  Suppose the application 
gets a well-constructed handle, and passes that handle "around" 
--either to other applications or to different interfaces to the 
stack/network.  I don't see the application as dealing in 
topology information by doing that, even if the handle 
ultimately identifies information that is deeply 
topology-sensitive and/or if the process that produces the 
handle uses topological information, or probes the network to 
develop such information.  The important thing from that 
perspective is that the application is dealing with the handle 
as an opaque object, without trying to open it up and evaluate 
its meaning or semantics (with regard to the network or 
otherwise).

>From that point of view, having an application go to the stack 
and say "given these criteria, give me a handle on the interface 
or address I should use" or "given this DNS name, and these 
criteria, give me a handle on the address I should use" does not 
involve the application being topology-aware, nor does it imply 
the application doing something evil because it picks an address 
(or virtual interface, or...) without understanding the 
topology.  The handle is opaque and and an abstraction -- as far 
as the application is concerned, it doesn't have any semantics, 
regardless of whether lower layers of the stack can derive 
semantics from it or from whatever they (but not the 
application) can figure out it is bound to.

If the application is calling on, e.g., TCP, then it might pass 
some criteria to TCP, or might not, and TCP might either pass 
enhanced criteria to the handle-generating layer or generate the 
handle itself.  Again, the application doesn't care -- it just 
needs to deal with an abstraction of the criteria in application 
terms.   I think that, from the application standpoint, it makes 
little difference whether the criteria involve routing, speed, 
reliability, or any of several potential QoS or security issues.

I'll also be the first to admit that we have handled the set of 
issues this implies rather badly with IPv4 (and they certainly 
are not new issues).  We have gotten away with it because the 
number of _hosts_ that need to understand, and choose between, 
multiple addresses for themselves has been extremely small, at 
least since routers were introduced into the network 
architecture.  Because it could mostly be seen as a router 
problem, applications in IPv4 mostly punted (for better or 
worse).  Also, since CIDR went in, we basically haven't given a 
damn when users who can't qualify for PI space can't multihome 
(at least without resort to complex kludges).   IPv6, with its 
multiple-address-per-host architecture, turns the problem from 
"mostly theoretical" to an acute one.  It does so with or 
without SL addresses being one of those on a host that has 
public (global or otherwise) addresses as well.

Finally, from the standpoint of that hypothetical application, 
the syntax and construction of that opaque handle are 
irrelevant.  In particular, it makes zero difference if it is a 
name-string that lower layers look up in a dictionary or a 
symbol table, or [the name of] some sort of class object, or 
whether it is, e.g., an IP address.  The only properties the 
application cares about is that it is a handle that it got from 
somewhere that satisfies criteria it specified or that were 
specified for it.

>>  The challenge to those
>> of you who are for, or against, SL at the IP level is to
>> justify  it in a context in which applications really don't
>> need to know  anything about them, or other address scope/
>> reachability/  routability issues except through the
>> addressing-independent  abstractions that we can agree on.
>
> I don't care if it is TCP-ng, or something else between IP &
> the app that takes care of figuring out the topology
> difference, but signaling by itself won't solve the problem of
> literal referrals. If the app is going to insist on passing
> around topology information, it has to make sure that matches
> the topology being used.

Well, at least intuitively, I agree with you about signaling. 
In most of the application contexts I can think of, signaling 
has more to do with the efficiency of communicating "you lose, 
maybe you should try something else" from lower in the stack to 
an application.  What is important, IMO, is not losing, rather 
than telling me more efficiently that I have.  But (and I am not 
speaking for Daniel here) it also isn't the point.  The notion 
of an application-opaque handle, whose semantics are invisible 
to the application but defined by stack layers that have access 
to whatever information is really needed, is, by contrast, 
exactly the point.

>> environment without --in the application-- having to
>> determine  which one to use by some type of iteration
>> process, then you  need to justify specialized addresses only
>> in terms of their  requires lower in the stack.  If the
>> applications do need to  know, then the complexity costs
>> appear to be high enough to  present an insurmountable
>> barrier.
>
> The current IPv4 network already requires this of
> applications, the developers simply choose to ignore reality.
> There is nothing different in a unique prefix for local use,
> other than the ability for the app (stack) that chooses to
> look to figure out that some pairings won't work. If the app
> does as it currently will and passes an out-of-scope address,
> the application will fail. This is not a new requirement, it is
> simply exposing the fact that applications have been ignoring
> reality for a long time now.

See above.  Applications have gotten away with ignoring that 
reality because the occurrences have been infrequent -- with one 
important class of exceptions, we have had few machines with 
multiple addresses (and multiple interfaces) since routers 
became common in the network.  The exceptions have been larger 
web hosts which support pre-1.1 versions of HTTP and hence use 
one address per DNS name.  But, for them, hosts opening 
connections to them use the address that matches the DNS name 
(hence no need to make choices or understand topological 
information) and the servers either use "address matching the 
one on which the connection was opened" or an arbitrary address 
on the interface --since the interface is the same, and its 
connectivity is the same, it really makes no difference.  If the 
reason for multiple addresses per host (or interface) in IPv6 is 
to support different scopes (or connectivity, or multihoming 
arrangements), then it does make a difference, and will make a 
difference for a significant number of hosts.  And _that_ 
implies a new requirement.

> If there are other ways to
> mitigate the issue, I am all for developing them. My primary
> issue is that there are a variety of things people want to use
> SL for and removing an existing mechanism without appropriate

Tony, there is a difference in perspective here.  I'm going to 
try to identify and explain it, with the understanding that it 
has little to do with any of the discussion above, which I think 
is far more important.  From your point of view, as I understand 
it, this feature has been in IPv6 for a long time, no one 
questioned it, or the problem(s) it apparently solved, for 
equally long, some implementations were designed to take 
advantage of it, and now people are coming along and proposing 
to remove it without a clearly-better solution to address those 
solved problems.  From the viewpoint of many or most of the 
applications-oriented folks on this list, and maybe some others, 
the applications implications of the SL idea (and maybe the 
"multiple addresses" idea more generally) are just now becoming 
clear.  What is becoming clear with them is that the costs in 
complexity, in data abstraction failures, and in damage to the 
applications view of the hourglass, are very severe and, indeed 
that, from the standpoint of how applications are constructed, 
SL would never have worked..    From that perspective, when you 
argue that applications are already doing bad things, the 
applications folks respond by saying "but IPv6 should make it 
better, or at least not make it worse".

Those differences lead to discussions about religion and 
ideology, which get us nowhere (although they generate a lot of 
list traffic).  It is clear to me (from my particular narrow 
perspective) that our getting to this point at this time 
indicates a failure on the part of several generations of IESG 
members (probably including me).  It also identifies a series of 
issues in how we review things cross-area (or don't do that 
successfully) and reinforces my perception that shifting the 
responsibility for defining standards away from a 
multiple-perspective IESG and onto WGs with much narrower 
perspectives would be a really bad idea.

But, unfortunate though it may be, we have gotten here.  We 
differentiate between Proposed and Draft standards precisely to 
make it easier to take something out that doesn't work, or 
--more to the point in this case-- doesn't appear to do the job 
it was designed to do at a pain level no worse than what was 
anticipated.  I don't think essentially procedural arguments 
about how much proof is required to take something out get us 
anywhere at this stage.  Instead, we should be concentrating on 
the real character of the problem we are trying to solve and 
ways in which it can be solved without doing violence to 
whatever architectural principles we can agree upon.

      john

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Apr 2003 22:57:26 -0400

Keith,

I am going to try to address the pieces of this that weren't 
covered --in a context I'm more comfortable with-- in my 
response to Tony's note.

--On Wednesday, 23 April, 2003 21:31 -0400 Keith Moore 
<[email-masked]> wrote:

> I guess it depends on what you define as "the scoping
> problem".  If the problem is that the network can impose
> apparently arbitrary restrictions on whether hosts can
> communicate between point A and point B (for arbitrary A and
> B) I don't see that as an architectural problem, nor something
> that should be the responsibility of applications to solve.
>
> and if you define the problem as that hosts are expected to be
> able to simultaneously have access to multiple scopes that
> must be accessed via different source addresses or different
> network interfaces or different tunnels, and to be able to
> provide connectivity to each of those for applications on that
> host, I still have to question whether giving each scope a
> separate address prefix is a constructive way to implement
> that.

Here, I have to agree with Tony, or at least a position I think 
Tony would take.

We have two very serious network problems right now.  There are 
probably others (I could even name some candidates), but let's 
concentrate for the moment on these two.

	* We don't have a routing architecture that is
	independent of the structure of IP addresses.  I wish we
	did.  I think the fact that we don't is going to lead us
	into [other] very serious problems in the long term.
	But the fact remains that we don't have anything
	resembling an IP-address-independent routing fabric
	proposal on the table, certainly not one that is
	complete enough to be plausible.
	
	* We are seeing more and more requirement for
	multihoming of one type or another, whether you count
	community wireless schemes or other small-group or
	small-ISP models into the mix or not.

One implication of the first problem is that one can't solve the 
second one by giving everyone who wants to connect to more than 
one provider independently-routable PI space.  Now, if we don't 
come up with a solution to both of those problems, it doesn't 
make any difference what features are in IPv6, because IPv6 will 
fail, and it will fail because the Internet --at least the 
Internet as we know it-- will fail.  I think we even know what 
the alternative looks like, at least in general terms, with 
islands of walled gardens, each with independent address spaces, 
and connected by bilateral agreements being the most likely of 
those alternatives.  Those proposals have been around for years, 
we know what they look like, and they don't provide the 
edge-oriented, end-to-end, "dumb" network we all believe is the 
core strength of the Internet.

So, while I've got serious misgivings about site-local 
(partially because I think I'd prefer to see globally-unique 
addresses even if they can only be routed locally and partially 
because I see "local" as a hierarchy), and have as little (or 
less) desire to see applications obligated to screw around in 
topology as you do, I'm not willing to give up on multiple 
addresses per host, or multiple prefixes, unless there is a 
clear proposal for an alternative on the table.

At least so far, "give every host one address and let the 
network (the routers?) sort out the routing" seems to me to 
reproduce the current IPv4 situation.  That doesn't seem to me 
to be a solution because it:

	* Assumes that everyone who has a LAN that they want to
	connect to multiple providers will have routable PI
	space.  Or
	
	* Assumes that everyone who has a LAN that they want to
	connect to multiple providers will be able to do so by
	punching holes in CIDR blocks.

>From my perspective, those two approaches don't scale.  Or they 
scale only at the price of assuming that only those with huge 
networks (or enough resources to convince backbone ISPs to 
violate CIDR and polute routing tables with small blocks) 
deserve to multihome.  The latter violates my religion about the 
network, your mileage may differ.

> John Klensin writes:
>
>> Tony, I think this pretty well reflects where I've found
>> myself  going on this, fwiw.   From an applications
>> standpoint, the  scoping issues, and what is, or is not,
>> "topology information",  just obscure the problem.  "The
>> problem", from an applications  point of view, is that, if we
>> are going to stop pretending that  the address space is
>> completely flat and global --and I agree  that to do
>> otherwise is unrealistic at this stage-- then we need  a
>> model by which the application can specify to the stack what
> I don't see why it's unrealistic to have a global address
> space that encompasses all hosts that are connected any
> network that is connected to the Internet, and to expect
> applications to use that global address space.  I agree that
> we cannot expect complete or near-complete connectivity.

But, if we have a one-address-per-host global address space -- 
which I think is what you are asking for-- and don't have 
near-complete connectivity, then we are either going to see 
rising times to set up the typical TCP connection, and a lot of 
UDP attempts fall off the edge, or we are going to need a lot 
more PI space.  I don't see realistic alternatives for the 
reasons discussed above.  Do you?  And, if so, what are they?

> In my mind, the reason we need feedback from the network to
> applications about when applications try to violate
> administrative prohibitions on use of the network is not so
> that applications can try to route the messages through other
> paths (though it does enable that to some limited degree) but
> so that applications can provide accurate indications to their
> users as to why they're failing.

Keith, while I'm very much in favor of accurate feedback, 
messages with the ultimately semantics of "you lose" have a long 
and well-documented history of being unpopular with users.  In 
that regard, while they inspire rather different families of 
sick jokes, there really isn't much difference among a cute 
cartoon of something crashing and burning; getting a message 
containing network gobblygook about timeouts, firewalls, or 
address scopes; having a code of a few letters, several digits, 
and another letter or two appear after the codeword "reply"; or 
suddening seeing a blue screen with possibly-irrelevant nonsense 
in white characters in the middle.  I'd rather focus on getting 
the network to work better and more often, while reporting 
accurately on failures if there is no alternative but to fail.

>> problem for a reason much more pervasive than the one Daniel
>> and  others have identified: most of our current applications
>> have no  interaction with either ICMP or IP -- they call on
>> TCP or UDP  functions and don't know about the internet
>> layer.  The Internet  layer doesn't have any path (by
>> "signalling" or otherwise) to  pass information back to the
>> apps.
>
> I don't see why TCP and/or UDP stacks can't provide such
> interfaces to applications, even though of course this means
> that there will need to be other interfaces (invisible to
> applications) between TCP and IP and UDP and IP to pass that
> information upstream.

They can't provide it because we don't have a model, or set of 
abstractions, for providing it.  If it is important, maybe we 
had better get started.

>> Unless we have a realistic proposal for a routing fabric that
>> is  not dependent on the addresses used, the solution-set
>> almost  certainly includes being able to use multiple
>> addresses per  host, with different semantics associated with
>> those addresses.
>
> the solution set to what?  I don't see what problem this is
> attempting to solve, but I do see lots of problems that this
> creates.

See above and the note to Tony.

>> As the competence level of the average ISP declines (which
>> seems  to have been a clear trend for the last several
>> years),  multihoming (in some form) needs to increase as the
>> only  satisfactory alternative... and it better not be only
>> for the  rich or the huge.  The idea of a single,
>> exclusively-global,  flat address space has been history for
>> years; we clearly aren't  going to get back there as long as
>> different providers charge  differently for different paths
>> (independent of any of the  enterprise localization,
>> firewall, RIR-granted PI space, or  other issues).
>
> radical idea: we need to get away from the notion that the IP
> address is a path specifier and back to the notion that an IP
> address is a location or interface identifier or (possibly
> virtual) host identifier.

Sure.  Good idea.  I anxiously await your I-D for how we are 
going to route packets from host to host if we make that change.

>> stack architecture, or accept our applications becoming as
>> (or  more) complex and knowledgeable about network
>> architectures as  switches get in the PSTN, then we should be
>> looking at stack  abstractions that permit applications to
>> express their needs,  and get information back, without
>> deducing network topology,  transport or mobility economics,
>> etc.
>
> I don't think these things need to be provided in the "stack"
> at all - for the same reason that apps don't want to cope with
> them - neither the host nor the app has the information needed
> to make those decisions.  and lacking a uniform address space,
> there's no basis for lower layers to make the decisions.  (for
> some reason a potentially-changing set of IP addresses doesn't
> strike me as a good endpoint identifier for any layer)  so we
> need a uniform location name space to be used by higher
> decisions.  now maybe these decisions need to be made at
> border routers rather than core routers (so that finer details
> of path selection are handled in the periphery where you get
> better scaling, and the core routers just forward things along
> pre-determined paths) but you don't want to push the routing
> information all the way to hosts.

I'm not sure about all of the implications of this, but it is 
quite possible that we agree.  But there is no way I can 
evaluate the above without a real proposal.  There, the 
advocates of multiple prefixes have a very considerable 
advantage over these speculations in the form of documents on 
the table.

         john

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 00:18:16 -0400

> core strength of the Internet.

I don't doubt this, but it's fairly clear to me that having multiple
addresses per host and expecting hosts to make decisions about which
prefix to use is also highly undesirable - in the sense that it will
drastically limit the set of applications that can work well.  But yes,
we have more of a chance of things working if they're all using a
single shared address space, than we do with disjoint address spaces.

I also don't see how this problem is any different between IPv4 and
IPv6, except that we might eventually expect IPv6 to scale to more
prefixes than IPv4.  Yes, v6 hosts have the code to handle multiple
prefixes and addresses, but that doesn't mean that the apps can deal
reasonably with them.  And in my experience even the simplest apps fail
to deal reasonably with multiple prefixes.  (trial-and-error, waiting
tens of seconds to timeout before proceeding to the next address, is
not reasonable)

But we need to distinguish between what we can do in the short term and
what we need to do in the long term.  In the short term our choices are
either to allow some form of provider-independent addressing (with all
that this means for the scalability of routing) or to expect hosts and
apps to deal with multiple prefixes.  Which choice is better is not
obvious - it depends on whether you want to optimize IPv6 for easy
deployment or eventual scalability.  Your answer to this question
probably depends on what layer you live at.

In the longer term we need to develop a way of doing a mapping from
location names or endpoint names to paths through the network, one that
preserves the uniqueness and structure of IPv6 addresses.

> 	punching holes in CIDR blocks.

To my routing-naive mind, two mechanisms seem worth investigating:

- One is a mapping at the BGP layer from what I'll call path-independent
prefixes to path-specific prefixes.   e.g. BGP could propagate
information of the form "route prefix X as if it were prefix Y". 
Routers wouldn't have to compute routes for prefix X, they could just
compute routes for Y and then use the same entry for X as for Y in the
fowarding table.  This lets the number of prefixes grow to some degree
without directly increasing the complexity of routing computations, as
long as the set of distinct destination networks as viewed from the core
did not get larger. In effect it would allow non-adjacent prefixes to be
aggregated for the purpose of route table computations. Which is not to
say that this comes for free, but it would let us to some degree move
toward a routing structure for the core that was independent of the IP
addresses used by hosts - in effect hosts and routing would use
different portions of the IP space, though some amount of overlap could
be tolerated.

- A mobileIP-like scheme for border routers, that could issue redirects
for prefixes as well as individual IP addresses.  So packets for a
particular destination prefix would initially go to "home network
agents" that could live anywhere on the network (including a database
distributed across multiple exchange points in diverse locations, all of
which advertise reachability via BGP) but which (in addition to
forwarding initial packets) would return redirects for entire prefixes
that caused subsequent packets to be sent to the "in care of prefixes".
These redirects would be intercepted and acted on by routers near the
source, not (or not only) by the sending host. Yes, it would still
require tunneling, or MPLS, or some other way of telling the network 
"route this traffic to here rather than to the destination  address in
the IP packet; that's for use after the packet exits our network".  But
there are lots of ways to do this, and perhaps they'll become more
widely available over time. 

And for those who think these ideas are naive, keep in mind that I did
say they're not near-term solutions, and that in the near term we're
stuck with less sophisticated mechanisms.  But we need to insist on
global addressing now so that we have a way to move to better routing
systems once we do solve the problems.

> reasons discussed above.  Do you?  And, if so, what are they?

I doubt we'll see a one-size-fits-all kind of solution any time soon. 
Some sites will be able to make do with multiple advertised prefixes,
perhaps with clever DNS tricks to try to minimize the connection
failures (yeech).  Other sites will be able to tolerate a single
provider.  Others will demand PI space and perhaps get it. Maybe they'll
have to buy an ISP, or masquerade as one, to accomplish this. I've
always thought the distinction between an ISP and a multi-homed,
multi-sited customer was fairly arbitrary.    I could imagine an
arrangement where limited-time leases for use of some amount of what was
effectively PI space (even if it came out of providers' allocations, it
could be routed to multiple providers)  was auctioned off to the highest
bidders, like radio spectrum. Or maybe the problems will create a demand
for more stable/clueful/expensive IP routing service.  

Or maybe the public Internet will just degrade to the point that it's
not useful for very much.  I'm not discounting that possibility, but
neither do I want to dwell on it.

> and well-documented history of being unpopular with users. 

Granted.  But there is no way that the reliability of internet
applications can improve unless the network can provide such feedback
to *somebody*.  Now maybe it shouldn't always be the user, but the
application, or the user's network administrator, or the application
author/vendor.  to some degree it depends on the application.  But
nobody can do anything about the problem without some indication that
the problem exists and some way to distinguish one kind of problem
from another.

> I'd rather focus on getting the network to work better and more often,
> while reporting  accurately on failures if there is no alternative but
> to fail.

No question there, but if the failure is due to an administrative
prohibition (which is where I thought this started), it's hard
to see what it means to have the network work better and more often -
unless it's to discourage use of packet filtering.  :)

> abstractions, for providing it.  If it is important, maybe we 

Has anyone made a list of important core problems that need to be
worked on?

Keith

---

From: Zefram <[email-masked]>
Date: Thu, 24 Apr 2003 11:24:27 +0100

>And you're conflating ambiguous addressing with scoping.

It seems that we have two different definitions of "scoping" in use.
One type of scope refers to the area in which an address is routeable;
this is about reachability and filtering.  The other type of scope is
the area in which an address can meaningfully be used to refer to the
addressed entity; this is about uniqueness and ambiguity.  Let's all,
please, be clear about which one we're arguing about at each point,
because a lot of the discussion here has been derailed by jumps between
them.

-zefram

---

From: Ignatios Souvatzis <[email-masked]>
Date: Thu, 24 Apr 2003 10:18:43 +0200

Hi,

> to discourage people from filtering it.

I don't understand why this is even a point of discussion. Next you hear
some people will like to globally filter TCP RST - will you rewrite TCP
to work without that?

Regards,
	-is

---

From: Terry Gray <[email-masked]>
Date: Wed, 23 Apr 2003 09:28:01 -0700 (Pacific Standard Time)

> network, so many firewalls also do NAT.

Simon,
I think there is more entanglement than you do, because sometimes
local addresses are used as part of a security strategy aimed at
avoiding the need for conventional middlebox firewalls.  (A google
search for "logic firewall" will point to one example of what I'm
talking about.)

I'm looking at this from the perspective of diagnosing alleged
network problems.

It seems to me that conventional middlebox firewalls utterly destroy
end-to-end transparency, and with it, any hope of preserving the
all-ports-are-equal "network utility" model that has served us so
well... whereas, local addresses merely "seriously undermine" that
model.  Do you prefer vinegar or castor oil?  (And can anyone offer me
some honey?!)

If I have to choose between random locally-controlled firewalls
sprinkled throughout my network infrastructure vs. having hosts with
local addresses, I would much prefer to live with the latter.  From an
end-to-end network management perspective, neither is a very happy
scenario, but my preference is based on having done both experiments.

At least with local addresses, some semblence of the network utility
model can be preserved: a technician with a globally-configured laptop
can run iperf tests from any outlet and not wonder whether some
intervening firewall is failing to preserve the window scaling bit in
the tcp header.  (And the NOC doesn't periodically lose visibility
to devices beyond the firewall because of accidental misconfiguration
by the firewall owner.)

Networking is all about connecting things; security is all about
isolating things.  As far as I can tell, a satisfactory compromise
still eludes us.  (Sometimes in the non-cyber world, too, as SARS
and 9/11 remind us.)

So, apart from the renumbering/provider-independence arguments for
local addresses, I do believe there is a security element too, which
in my mind adds fuel to the architectural debate over e2e
transparency.  There are a range of ways local addresses can play into
the security space; some involve NAT, some do not, but at our site we
already have compelling evidence that offering some defense-in-depth
security alternatives involving local-addressing can greatly diminish
the clammer for *conventional* perimeter firewalls, and thus, reduce
the pressure on us to abandon the network utility model.

Who do we call about the destruction of the network utility model that
has served us so well?  As an over-simplified generalization, I think
the OS vendors have to take the rap. By allowing the accretion of an
installed base of end systems that is by-and-large not "Internet
safe", they have unwittingly given credence to the widespread view
that "it was the networking guys who brought us all these security
problems, so it should be the networking guys who solve the security
problems."  This in turn inevitably leads to middlebox perimeter
defense "panaceas", and thence to the search for less
network-destructive alternatives.  My current hypothesis is that local
addresses can play a role in that (slightly) less-destructive solution
space.  But I continue to seek/wish-for better choices.  (Meanwhile,
I'll just slip into my asbestos suit, and debate with myself the
wisdom of sending this message :)

NB: I'm focused on singly-addressed hosts; I have no wisdom to offer
regarding the multiply-addressed host problem/controversy.

-teg

---

From: Eric Rosen <[email-masked]>
Date: Thu, 24 Apr 2003 11:00:17 -0400

While I  enjoy seeing the IPv6 guys  arguing with each other,  I don't think
that anyone is deliberately spreading incorrect information here. 

There seems to be general  agreement that there are multi-party applications
in which A needs to  tell B to talk to C.  Thus A needs  to have some way to
unique identify C to B. 

However,  because   of  communications  policy   restrictions,  neither  the
application  layer nor  the network  layer can  know whether  B  is actually
allowed to  talk to C.   So it seems  that these applications can  only work
when  deployed  within  a  policy  domain.  (Policy  domain  boundaries  are
generally marked  by such things  as firewall and security  gateways, things
which  are  hated  by  the  purists because  they  eliminate  communications
transparency.)  The fact that  A gives B an address of C  rather than a name
of  C  doesn't seem  relevant  at  all; after  all,  names  just resolve  to
addresses;  I think the  name vs.  address issue  is a  red herring  in this
context. 

The existence of policy domains seems to restrict the applicability of these
multi-party referring applications, especially as  the app itself has no way
of knowing whether it is crossing policy domain boundaries.  

So  what does  this  have to  do  with site-local  addresses?   I think  two
arguments have been made.

1. Because site-local  addresses are  ambiguous, if  A passes  a site-local
   address to B, B may not be able to use it to talk to C. 

   I  think the reply  that has  been made  to this  is that  the site-local
   addresses have to  be unambiguous within a particular  policy domain, and
   it is a  management function to ensure that this is  the case.  Since the
   apps in  questions are applicable only  within a policy  domain, the fact
   that the  addresses are ambiguous  outside that domain doesn't  makes the
   apps any less useful than they already are. 

2. A system  with a site-local address is likely to  have other addresses as
   well, and it is  a bad thing for a system to  have more than one address,
   because the apps have no way of knowing which address is the right one to
   distribute. 

   I think the reply to this is  that this horse escaped from the barn about
   20 years  ago, and  anyway, choice of  address is a  management function.
   That  is, the app  needs to  be told  through some  sort of  config which
   addresses to use when.

It's been claimed that if non-ambiguous addresses are used, at least the app
can tell when  communication is being prevented due  to policy restrictions,
as it  will receive ICMP  messages with appropriate  diagnostic information.
Unfortunately, this  presumes more from  the network layer than  the network
layer actually  provides.  ICMP messages  may be generated due  to transient
problems, they may  fail to be generated at all  (for "security reasons", or
due to limitations on the rate  of ICMP generation), they may be dropped in
the network,  etc.  When communication fails,  there is no  reliable way for
the endsystems to determine why it has failed. 

So I  don't really  think the  case against site-locals  has been  made here
(which is  not to say that  there isn't a  case against them based  on other
considerations). 

I think the  underlying problem is that our  comms architecture doesn't take
the policy restrictions  into account at all, and folks  tend to assume that
this needs  to be accounted for  at some other  layer than the one  they are
most interested in.  This generates  frustration, and creates a high heat to
light ratio.   Usually everyone blames  it on NAT,  so it's nice to  see the
same issue come up in an IPv6 non-NAT context.

---

From: [email-masked]
Date: Thu, 24 Apr 2003 12:28:38 -0400

> addresses;  I think the  name vs.  address issue  is a  red herring  in this

I'm not at ALL convinced it's a red herring in the least.

In fact, it may be relevant that it uses an address rather than the name of C,
because it's certainly conceivable that A gives B a name which *when resolved
by B* results in something that can get to C.

One example:  Akamai DNS...

(OK, all you 'The DNS must be consistent' fanatics can shoot me now ;)

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 14:07:34 -0400

> However,  because   of  communications  policy   restrictions, 
> neither  the application  layer nor  the network  layer can  know
> whether  B  is actually allowed to  talk to C.   So it seems  that
> these applications can  only work when  deployed  within  a  policy 
> domain.  

one question here is whether there is some burden on applications to
try to find a path between hosts B and C, say by address and/or
interface selection, or whether the burden is entirely on the network. 

one of the problems with our current notion of 'policy domains' is that
they are so inflexible as a security mechanism that people demand, out
of necessity, that some applications be able to work across them.  

so no, it's not reasonable to assume that apps that do referrals are
only expected to work within a single policy domain.

>  The fact that  A gives B an address of C  rather than
> a name of  C  doesn't seem  relevant  at  all; after  all,  names 
> just resolve  to addresses;  I think the  name vs.  address issue  is
> a  red herring  in this context. 

that's because you haven't had to deal with DNS unreliability,
imprecision, inconsistency, and performance issues.

>    well, and it is  a bad thing for a system to  have more than one
>    address, because the apps have no way of knowing which address is
>    the right one to distribute. 
> 
>    I think the reply to this is  that this horse escaped from the barn
>    about 20 years  ago

not in a general sense.  even today, the vast majority of IPv4 hosts
have a distinguished IP address that is usable from everywhere that's
supposed to be able to talk to the host.

> , and  anyway, choice of  address is a 
>    management function. That  is, the app  needs to  be told  through
>    some  sort of  config which addresses to use when.

which is a management nightmare.

> It's been claimed that if non-ambiguous addresses are used, at least
> the app can tell when  communication is being prevented due  to policy
> restrictions, as it  will receive ICMP  messages with appropriate 
> diagnostic information. Unfortunately, this  presumes more from  the
> network layer than  the network layer actually  provides.  ICMP
> messages  may be generated due  to transient problems, they may  fail
> to be generated at all  (for "security reasons", or due to limitations
> on the rate  of ICMP generation), they may be dropped in the network, 
> etc.  When communication fails,  there is no  reliable way for the
> endsystems to determine why it has failed. 

no, but when the connection times out right after the host has
received 3 or 4 "prohibited" ICMP messages in response to traffic sent
on that connection, it's a pretty good clue.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 12:55:25 -0700

Eric Rosen wrote:
> ... The fact that  A gives B an address of C  
> rather than a name of  C  doesn't seem  relevant  at  all; 
> after  all,  names  just resolve  to addresses;  I think the  
> name vs.  address issue  is a  red herring  in this context. 

If A gave the entire list of choices to B, you would be right. The
problem is that A will generally give B the one it chose, since it
believes that one works. 

> 
> The existence of policy domains seems to restrict the 
> applicability of these multi-party referring applications, 
> especially as  the app itself has no way of knowing whether 
> it is crossing policy domain boundaries.  

This is right in the general case. We have toyed with the idea of
preventing mixed  scope connections which would allow the app to clearly
know. 

>    apps any less useful than they already are. 

This is right on. 

>    That  is, the app  needs to  be told  through some  sort 

The intent of the sending rules is to provide the default version of
that config. There are arguments that those don't work for the mobile
node case, but I would argue that the mobile node has to know when it is
away from home to inform its HA, so we could add a rule that MNs don't
use local scope addresses when away from home. 

> 
> It's been claimed that if non-ambiguous addresses are used, 
> at least the app can tell when  communication is being 
> prevented due  to policy restrictions, as it  will receive 
> ICMP  messages with appropriate  diagnostic information. 
> Unfortunately, this  presumes more from  the network layer 
> than  the network layer actually  provides.  ICMP messages  
> may be generated due  to transient problems, they may  fail 
> to be generated at all  (for "security reasons", or due to 
> limitations on the rate  of ICMP generation), they may be 
> dropped in the network,  etc.  When communication fails,  
> there is no  reliable way for the endsystems to determine why 
> it has failed. 

In addition, it doesn't solve the issue that A will pass B the address
that it is using, rather than the possible set. B needs to derive its
own view of how to reach C even when globally unique addresses are used.

> 
> So I  don't really  think the  case against site-locals  has 
> been  made here (which is  not to say that  there isn't a  
> case against them based  on other considerations). 
> 
> I think the  underlying problem is that our  comms 
> architecture doesn't take the policy restrictions  into 
> account at all, and folks  tend to assume that this needs  to 
> be accounted for  at some other  layer than the one  they are 

I am not trying to place blame, but I would word it differently. While
the architecture has all along allowed for differentiating policy
restrictions, the app community chose to simplify their effort by
ignoring that there were policy differences in the lower layers. This
worked as long as the world was dominated by client/server oriented 2
party apps. In a world of multi-party apps, the policy differences of
the lower layers are exposed and we need to rethink how apps deal with
that reality. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 12:55:29 -0700

Shannon -jj Behrens wrote:
> Please forgive my rough tone (in fact, I have great respect 
> for you as an engineer), 

I try to avoid taking any IETF discussions personally, one way or the
other.

> but it would be much more 
> interesting if you wrote a document that provided solutions 
> for all of the problems that people have claimed site-locals 
> cause.  

I understand that is what some people want, but I think we need to first
agree on the problems that need solving. We have many opinions on why SL
creates problems, but a blatant lack of recognition of the problems that
need to be solved. 

> While I hear you saying that the wg should replace 
> all of the features that site-locals provide before removing 
> them from the architecture, I challenge you to instead take 
> the impetus of fully specifying site-locals.  

I believe the first step to doing that is to agree on the problems that
need solving, then see if there are alternative approaches. 

> I do believe, 
> based on other comments on the list, that such a challenge 
> has existed for five years and has yet to be answered.  
> Having fully specified site-locals, I do believe the wg would 
> be much more willing to accept them into the architecture.  

I thought we were going there with the scoped arch document, but lacking
agreement on the problems to be solved, it became easier to spread FUD
and give up on addressing the issues than to sit down and work them
through.

> Although I clearly am not capable of providing the full list 
> of questions that you must answer, perhaps the following 
> questions are helpful:
> 
> o In light of the fact that not every host has a DNS name, 
> how do you propose multi-party P2P applications should do 
> referrals? It would be helpful if you established the normal 
> mode of operation for such situations.

As I said in the note to JCK, I have been imprecise about 'name' so
whatever the app uses to get a handle from the local stack is what it
needs to pass around. Doing otherwise ignores the reality that the
network does not look the same from all points.

> 
> o Should site-locals be put in DNS?  Should multiple views of 
> DNS be used?  If 
> so, how do you address the apparent apprehension in the DNS 
> community toward multiple views (I don't know about this 
> first-hand--I've only read about it 
> from this list)?  Should zone information be kept in DNS?

Implementation details of a multi-faced DNS are best addressed by those
that already ship them. Any service that provides topology specific
information has to do that with an understanding of the topology being
described by that information. 

> 
> o Do you foresee all nodes being multi-site nodes?  

Certainly not all, my light switch should not be in any site except my
house. At the same time I may want it to be in multiple scopes, so I can
get to it and turn on the driveway light from the car as I approach.

> If I'm at 
> work and wish to 
> use both my work network *and* my home network via a VPN 
> connection, I expect I would want my laptop to be a 
> multi-site node.  If this is the case, do I 
> need to use %interface_name at the end of all IP's I give to 
> applications I 
> use?  How would DNS lookups work on a multi-site node if 
> site-locals are stored in DNS?

The name resolver would have to track which interface / site it got
answers from because any limited scope resolution is only applicable in
that interface / site context. 

> 
> o If, as you say, we should provide site-locals because, "we 
> need to meet the network manager at his comfort zone and 
> provide a familiar tool," how do we 
> convince the network manager not to use NAT since this is 
> also a familiar tool in most people's comfort zone.  I'm not 
> willing to argue that site-locals 
> necessarily lead to NAT, but many people are, so you should 
> probably have some answer. 

Leading people away from something comfortable requires providing
something that meets the same basic need and is easier/cheaper/more
comfortable. Many use NAT because they can't get STABLE addresses
otherwise, and NAT is simply the cost of getting that. Providing STABLE
local use prefixes simultaneously with global prefixes that may change
over time is a cheaper way to meet the need for STABLE addresses. 

* I emphasize STABLE because that is a invariant requirement by many
managers of large networks. 

> 
> o Do you envision support for Margaret's idea of multiple 
> concentric rings of security (possibly using site-locals)?  
> If a node in the outermost ring is not able to talk to a node 
> in the innermost ring using a site-local address because of 
> filtering, but is permitted to use a global address, how 
> shall applications react when the site-local "hint" is 
> actually misleading?

Personally I consider those security zones as different sites. This gets
into the poor definition of 'site', but we were intentionally vague
there. There is no difference between an FEC0 or 2001-w/Bellovin-Zill
flag prefix in how one would solve this problem. The fact that SL does
not provide multiple concentric security zones is not a failure of SL,
because that was not a design requirement (again we need to agree on the
problems to be solved). 

> 
> Again, I'm sure there are many more such questions, and I 
> think it would be 
> helpful (and in fact requisite) that you answer such 
> questions in an Internet Draft in order to achieve your goal 
> of restoring site-locals to the 
> architecture.  I thank you for your time and *patience* if 
> you have made it all the way through this message.

I agree that we need answers to all these issues, and that was the
intent of the scoped arch doc. Once people realize that they continue to
exist for any local use prefix, we will stop the nonsense about SL is
the evil that causes the problems and get back to developing the needed
documents.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 12:55:16 -0700

John C Klensin wrote:
> list, as David Conrad suggested.  

I was certainly not trying to pick on ARIN, because there is wide
perception that they are fairly liberal in their IPv4 policy. I agree
that allocation policy discussions belong elsewhere.

> But, for the record, I was 

Yes it is not widely deployed yet, but that does not mean lack of IPv4
space is not a sufficient reason. In several active deployment cases I
am aware of, going as fast as they can, it takes 3-5 years to get to the
point of delivering a stable commercial grade service. It should not be
surprising that we don't see wide scale deployment yet, since the
realization that we are effectively out of IPv4 space has only hit home
recently. 

> its meaning or semantics (with regard to the network or 

In general I agree, but the difference of perspective is that ignoring
the fact that the well constructed handle is actually derived from
topology information does not make the issue go away. The only way you
can get the handle you are looking for is to have something below you
sort out the topological reality. I agree the current name service is
not up to the task, and I believe that we need to get that fixed.
Unfortunately it looks like it will take some very crisp architectural
guidance to get the IESG to refocus the DNS related WGs to even discuss
the issues. The sad part is that many of the participants there already
ship or run variants that help address this problem, but they have
agreed not to work on standardizing it.

> application) can figure out it is bound to.

This points out that I have been imprecise by claiming that passing
names are sufficient, all the criteria you would use for local
communication with the stack are the 'name' in the context of my
previous mail. 

As long as the handle stays contained within the machine you are fine.
The problem arises when the app passes that handle to another node,
believing that the topology specific information is already there. If
the blob passed were the same as what the app used to acquire the local
handle, the other nodes would acquire appropriate local handles. 

> reliability, or any of several potential QoS or security issues.

I agree as long as the app keeps the handle for local use. It can't
assume that handle will have an equivalent meaning somewhere else in the
network. If it wants to pass a handle that it believes has sufficient
topology information for the receiver to directly access the same point,
it needs to understand the topology enough to know that the meaning will
be consistent. Otherwise it needs to pass the original parameters.

> public (global or otherwise) addresses as well.

I agree that SL simply exposed the issue. The problems arise from the
mismatched interpretation by the apps, that all 'handles' will be
treated equally by the network, and the reality that the network has
more than a single policy. As you noted earlier, this is not just about
scoping of address reachability, it also applies to QoS and any other
policy related variance in the topology. 

> somewhere that satisfies criteria it specified or that were 

I understand that is what the app wants to see. I am suggesting that in
the absence of a central policy entity that can sort out all possible
topology differences, multi-party apps will need to pass the original
parameter set, and maintain local mappings to the stack handle at each
participant node. Not pretty, but closer to a working solution than
continuing to ignore the reality that the topology is inconsistent.

> implies a new requirement.

We could debate 'new' forever, since as you noted earlier this
requirement existed before routers, but the point is that apps can't
ignore it any longer.

> solved problems.  

Yes. 

> From the viewpoint of many or most of the 

It is inconsistent to claim that SL would never have worked while
admitting that there are implementations that take advantage of it. But
that aside, SL is not the issue, the issue is that apps have come to
believe that the topology is flat so they can pass around handles
constructed of topology specific information. The reality all along has
been that some addresses were not reachable outside an administrative
scope of relevance. Writing those cases off in a client/server world was
mostly possible, but in the peer-to-peer world of IPv6 that is no longer
possible. 

> perspectives would be a really bad idea.

I agree, and even restricting the cross-area review to the IESG is a bad
idea because there aren't enough cycles in that small group. 

> whatever architectural principles we can agree upon.

I agree to a point. My button is pushed by those that claim a technology
'creates more problems than it solves', when they simultaneously admit
they don't have a clue what problems need solving. To that end I started
a draft on what problems need solving, so we can sort out the cases that
the current technology does solve, as well as begin to identify
alternatives. IF we get to a point were there are alternatives for all
the cases people care about, we should drop the unused technology. 

Tony

---

From: Shannon -jj Behrens <[email-masked]>
Date: Thu, 24 Apr 2003 09:28:08 -0700

> http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-00.txt

Dear Sir,

Please forgive my rough tone (in fact, I have great respect for you as an
engineer), but it would be much more interesting if you wrote a document that
provided solutions for all of the problems that people have claimed
site-locals cause.  While I hear you saying that the wg should replace all of
the features that site-locals provide before removing them from the
architecture, I challenge you to instead take the impetus of fully specifying
site-locals.  I do believe, based on other comments on the list, that such a
challenge has existed for five years and has yet to be answered.  Having fully
specified site-locals, I do believe the wg would be much more willing to accept
them into the architecture.  Although I clearly am not capable of providing the
full list of questions that you must answer, perhaps the following questions
are helpful:

o In light of the fact that not every host has a DNS name, how do you propose
multi-party P2P applications should do referrals? It would be helpful if you
established the normal mode of operation for such situations.

o Should site-locals be put in DNS?  Should multiple views of DNS be used?  If 
so, how do you address the apparent apprehension in the DNS community toward
multiple views (I don't know about this first-hand--I've only read about it 
from this list)?  Should zone information be kept in DNS?

o Do you foresee all nodes being multi-site nodes?  If I'm at work and wish to 
use both my work network *and* my home network via a VPN connection, I expect
I would want my laptop to be a multi-site node.  If this is the case, do I 
need to use %interface_name at the end of all IP's I give to applications I 
use?  How would DNS lookups work on a multi-site node if site-locals are stored
in DNS?

o If, as you say, we should provide site-locals because, "we need to meet the
network manager at his comfort zone and provide a familiar tool," how do we 
convince the network manager not to use NAT since this is also a familiar tool
in most people's comfort zone.  I'm not willing to argue that site-locals 
necessarily lead to NAT, but many people are, so you should probably have some
answer. 

o Do you envision support for Margaret's idea of multiple concentric rings of
security (possibly using site-locals)?  If a node in the outermost ring is not
able to talk to a node in the innermost ring using a site-local address because
of filtering, but is permitted to use a global address, how shall applications
react when the site-local "hint" is actually misleading?

Again, I'm sure there are many more such questions, and I think it would be 
helpful (and in fact requisite) that you answer such questions in an Internet
Draft in order to achieve your goal of restoring site-locals to the 
architecture.  I thank you for your time and *patience* if you have made it all
the way through this message.

Best Regards,
-jj

-- 
Hacker is to software engineer as 
Climbing Mt. Everest is to building a Denny's there.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 24 Apr 2003 16:45:54 -0400

>John C Klensin wrote:

[edited]

>agreed not to work on standardizing it.

Having a mechanism within each host which can sort out the topological 
issues seems like something we will have to explore. It is not clear to me 
that DNS is the solution, though it may be a part of the solution. More below.

>handle, the other nodes would acquire appropriate local handles.

Agree that these handles can't move off the host on which they are valid.

Recognizing applications DO want to be able to send identifying information 
in the course of transactions with other hosts, and that it is important to 
make such applications function, perhaps it's time to actually address this 
problem with some degree of standardization. Do we really want to continue 
having applications try (and often fail) to do this work? Perhaps we're 
discussing something that some become an integral component of the Internet 
Protocol suite.

It would make more sense for an application to make a call to an API that 
says "I want to hand off identifying information about host X to host Y. 
Please package me up information to sent to X so that it will be able to 
understand what I mean." The result of that API would be a blob which the 
application would send. The receiving application would pass that blob to 
an API on its end, effectively saying "I got this blob from host A, and it 
wants me to use it to set up communication. Please figure out what it 
meant, and give me a handle for talking to the proper destination."

The application would not see (or care) how this is actually implemented. 
Application writers should not need to know or care. Under the covers, 
those APIs could result in some sort of work done solely on the hosts in 
question, or could result in some sort of exchange amongst the hosts to 
figure out the best way to make that communication happen. Getting this 
decision out of the application space is the key point. This would simplify 
the implemenentation of applications which want to do these types of third 
party communications, and provide a standardized mechanism for 
implementation. With that standardized, a uniform firewall and NAT 
traversal mechanism could be considered. Note that there is a great deal of 
room for exploration of mechanisms and techniques to make this work. I'm 
not proposing a singular solution, but merely a framework for facilitating 
that solution.

A mention of proper layering was made earlier in this discussion thread. 
It's time we took a serious look at how to improve on the mechanisms used. 
Solving this layering issue could benefit both IPv4 and IPv6 
implementations. As noted, the problem is not new at all, though perhaps 
now is the time to shed light on the matter.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Apr 2003 13:58:00 -0700

Tony Hain wrote:
> But that aside, SL is not the issue, the issue is that apps have come to

As there are many entities that provide firewalling functionality, it is 
unreasonable to assume that it would be possible for each of these to be 
the address authority for either end of a connection.  Thus, an 
application must deal with multiple administrative domains today.  In 
some circumstances, administrative firewalls exist specifically to block 
particular applications.  And... network error messages may or may not 
be appropriate to a given circumstance.  It all depends on your threat 
model.

Along these same lines, there is no reason to assume that the end host 
will be trusted by the firewall sufficiently such that a POLICY exchange 
would be allowed.  It is one thing to say, "Permission denied", and 
quite something else to say when one will deny permission.  SLs and IPv6 
provide neither advance nor regression in this regard.

I take exception to this:

> they don't have a clue what problems need solving. 

Most of us -- MOST OF US -- have a clue.  That you refuse to recognize 
it and respect those opinions is unfortunate.

> To that end I started

And many of us have been saying that we have something that works today, 
RIR policies not withstanding.  It's IPv4.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Apr 2003 14:04:54 -0700

Tony Hain wrote:
> I am not trying to place blame, but I would word it differently. 

Not to contradict you, but...

> While the architecture has all along allowed for differentiating policy
> ignoring that there were policy differences in the lower layers. 

Nobody ignored anything.  To start with, the application community has 
had to work around these sorts of problems.  This is why there are SIP 
proxy gateways, STUN services, and MX gateways.  All of these exist due 
to connectivity limitations (either intentional or architectural).  All 
of these cases fall under the "Got Lemons?  make lemonade" approach.  So 
I believe you've mischaracterised the community.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 17:10:12 -0400

> problem is that A will generally give B the one it chose, since it

there are multiple problems.

one problem is when the network expects different hosts to choose
different addresses in order to reach the same destination.

another problem is that even if A passes a list of choices to B,
neither A nor B typically has any idea about which choices will
work for B, or for any third intermediary that B passes the list to.

(no, it's not the case that A will "generally" give be the address it chose,
because there's too much variation in behavior between distributed apps. 
often A has no need to choose from that set of addresses at all; it's just
trying to provide some referral service.)

another problem is that being able to pass a list of addresses is not the same
thing as being able to fail over from one address to another, and yet people
want to treat the existence of multiple addresses on a host as a substitute
for multihoming.

> > I think the  underlying problem is that our  comms architecture doesn't
> > take the policy restrictions  into account at all, and folks tend to
> > assume that this needs  to be accounted for  at some other layer than the
> > one  they are most interested in.  This generates  frustration, and
> > creates a high heat to light ratio.   Usually everyone blames it on NAT, 
> > so it's nice to see the same issue come up in an IPv6 non-NAT context. 
> 
> 

another false statement.  apps have been expected to deal with crude and
inflexible policy implementation in lower layers for many years, so apps
people are painfully aware that such differences exist.  what some of us are
saying is that the lack of flexibility in these mechanisms has increased
complexity in both apps and the network without providing much in the way of
useful policy control or security, and we need to reconsider some of the
cruder mechanisms like private addressing.  or in other words - don't create a
mess at layer 2 or 3 and expect layer 7 to sort it out.

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 17:25:29 -0400

> The only way you
> the issues. 

if the architecutral guidance were crisp it certainly wouldn't be asking the
DNS related WGs to discuss those issues.  DNS cannot solve this problem.

> handle, the other nodes would acquire appropriate local handles. 

this presupposes that the blob that is passed is precisely and reliably bound
to the specific host or process that the app wants to refer to, and also that
the lookup process that maps blobs to locators and/or identifiers is
sufficiently fast and robust.  often neither of these conditions holds.

> The problems arise from the
> treated equally by the network,

heaven forbid that apps would assume the same thing that the IP network
was designed to assume - that there is a uniform address space across the
entire network.  but you want to change this fundamental architectural design
point at layer 3 and then claim that the resulting problems are caused by
inappropriate assumptions at layer 7.  some would say this is layering
violation, but the sharing of identifiers between layer 7 and layer 3 is
another fundamental architectural design point.

> they don't have a clue what problems need solving.

I do have an idea about what problems need solving, but I don't claim to be
able to make a list that satisfies everyone at the drop of a hat. 

But it's not clear that SL was actually intended to solve any of these
problems.  Rather, it seems to me that somebody thought SL was a good idea,
and put it into the v6 architecture.  And then various people started saying
"hey, we can use SL for X", and nobody bothered to examine whether there were
conflicts between those various peoples' assumptions (whether specifically
about SL or not), or even whether SL was worth the cost, until recently.

The problem with trying to make a list of "SL-related problems" is that there
is also a set of problems that don't directly involve SL but also need to be
solved, and SL precludes solving those problems.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 17:56:53 -0400

> understand what I mean." 

been there, tried to do that, in the context of PVM.  by far the easiest way
to accomplish this is to have a uniform address space at the network level.
any other approach is just too complex.

background: PVM was originally designed to as a uniform API for distributed
memory parallel machines, and later as a way to provide a distributed memory
programming environment across a network of computers (some of which were
potentially distributed memory hosts).  in order to allow applications to send
messages to other "processing elements" or hosts, PVM assigned a task id to
each "processing element" in its virtual machine, and the mapping between task
ids to tasks was uniform across the virtual machine.  this task id consisted
of a host id to which a host-specific offset was added.  we tried making the
mapping non-uniform because it would have relieved us of the need to keep a
mapping table consistent across all hosts in the machine (especially after we
allowed new hosts to be added to the machine), but the most robust, and in
general the most efficient, way to implement the host-id mapping function was
to use consistent numbering for host-ids across the entire machine...that, and
expecting apps to invoke a translation function every time they
passed a task id to another task was just too cumbersome.

uniform addressing models are very compelling, even when you don't have
complete interconnection.

> now is the time to shed light on the matter.

proper layering is an art.  it involves understanding when to enforce layering
discipline, and when to escape it.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 15:01:02 -0700

> I believe you've mischaracterised the community.

Those are all examples of building complexity into the infrastructure so
that the app can maintain the fantasy that the world is flat. Personally
I would rather see the Lemons turned into a nice desert than squeezed
and watered down.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 15:01:05 -0700

> it and respect those opinions is unfortunate.

Where is the document that shows what requirements need to be solved? 

How would you correlate the stated need from the network manager for:
Stable addresses, both during ISP changes, and for intermittently
connected networks.

with:
Why is it that stable addresses are so necessary?  
Could it be because renumbering is painful?  
Could that be one source of our ills?

&

Fix the underlying problem.  Making renumbering easy.  
If we don't do that, IPv6 is no better than Ipv4.

???

While I agree that we need to get at the underlying problem, handwaving
that easy renumbering will solve it is not helpful. In many cases the
requirement for stable addresses is being handed to the enterprise
network manager by unreasonable Sr. VPs who want to lower their internal
development cost & don't care about anything more than getting their
product out the door. Claiming that easy renumbering will solve that
internal business issue is just an IETF fantasy.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 18:10:19 -0400

> > If A connects to B, and B wishes to pass the connection info 
> > to C, B only has the address with which A accessed B.  If A 
> > and B are in the same site and used site-local communication, 
> > and C is not in that site, B does not have enough information 
> > to refer C to A.  Hence, your suggestion does not solve this case.
> 
> I agree, but is it reasonable for B to tell C to talk to A, or is it
> more reasonable for B to tell A to connect to C by the 'name blob' it
> would have used to contact C? 

let me rephrase the question.  is it reasonable to expect that every 'blob'
that can be used to derive a set of locators for a host is tightly bound to
that host?   or is it more reasonable for the network infrastructure to
provide a token, independent of any application-specific blob, that can be
tightly bound to that host?

back in the mid 1990s I had a system for looking up URLs or URNs in a
distributed database which would return blobs that could be used to find
accurate replicas of those resources.  those blobs included IP addresses in
order to speed up access (requiring clients to do extra DNS lookups
drastically slowed the system down).  but those blobs weren't bound to hosts,
they were bound to resources, and the mapping between resources and hosts was
(by design) arbitrary.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 18:11:27 -0400

> that the app can maintain the fantasy that the world is flat. 

maybe instead it's your fantasy that it's reasonable to expect apps to cope
with routing.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Apr 2003 15:26:24 -0700

> Where is the document that shows what requirements need to be solved? 

How about starting with the IPng archives?!  They're actually more 
persistant than, say, an internet draft, anyway.

> Stable addresses, both during ISP changes, and for intermittently

I wouldn't.  I would decompose the network manager's stated need for 
stable addresses.  That's what responsible people do when they see a 
customer requirement with a bad solution.  But see below...

> internal business issue is just an IETF fantasy.

This strikes me like the old adage, "You're safe if you buy IBM" (no 
offense to IBMers).  You were until you weren't because the processes 
you used were outmoded, only you didn't think about it.  Frankly, the 
fantasy here (and I love your charged use of words) is that IPv6 
provides any -- ANY -- added benefit to the customer base.(*)  That same 
Sr. VP ought to be asking why he is spending what will for the forseable 
future be a huge amount of money to cut over to IPv6 when IPv4 will suit 
the vast percentage of enterprises and users just as well as IPv6, given 
their intended use of SLs, as stated by some of those very same network 
managers.

Eliot

(*) Indeed I question whether even the mobility features will be 
properly taken advantage of, given the stated network manager need for 
stable addresses reconciled with their need for Internet connectivity 
(i.e., NAT).  What do you then use for your MN address?  If that mobile 
node wants to have a stable identifier, then it's using site-locals. 
Nonsense?  But if they don't use site-locals then they have all the same 
problems those network managers are complaining about, and you don't 
have a stable address for applications.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 15:27:09 -0700

Keith Moore wrote:
> if the architecutral guidance were crisp it certainly 
> wouldn't be asking the DNS related WGs to discuss those 
> issues.  DNS cannot solve this problem.

I agree all infrastructure & components that pass around topology
information need work, but DNS is one of those, so it is a good place to
start.

> > the blob passed were the same as what the app used to acquire the 
> > local handle, the other nodes would acquire appropriate 
> local handles.
> 
> this presupposes that the blob that is passed is precisely 
> and reliably bound to the specific host or process that the 
> app wants to refer to, and also that the lookup process that 
> maps blobs to locators and/or identifiers is sufficiently 
> fast and robust.  often neither of these conditions holds.

If the first one doesn't hold, the origin node can't use it so the whole
app is broken. Speed is an implementation issue, not a spec issue. In
any case, it is much faster to pass a blob that can be mapped into
useful topology information, than it is  to pass around useless topology
information.

> heaven forbid that apps would assume the same thing that the 
> IP network was designed to assume - that there is a uniform 
> address space across the entire network.  but you want to 
> change this fundamental architectural design point at layer 3 
> and then claim that the resulting problems are caused by 
> inappropriate assumptions at layer 7.  some would say this is 
> layering violation, but the sharing of identifiers between 
> layer 7 and layer 3 is another fundamental architectural design point.

I am not saying that. From day one, a host that had one interface where
the address prefix was not passed widely in the routing system, and
another where the prefix was passed globally would have exactly the same
issues you are complaining about. This says nothing about firewalling,
qos, ambiguous addresses, etc. This is simply about a host having
multiple addresses, where different points in the network have different
perceptions about the viability of those. The fact that over the years a
simplification was done through the assumption that there was only a
single view is a failure. 

> 
> > I agree to a point. My button is pushed by those that claim a 
> > technology 'creates more problems than it solves', when they 
> > simultaneously admit they don't have a clue what problems need 
> > solving.
> 
> I do have an idea about what problems need solving, but I 
> don't claim to be able to make a list that satisfies everyone 
> at the drop of a hat. 

I don't have a list either, but we need to collectively create that
list. 

> 
> But it's not clear that SL was actually intended to solve any 
> of these problems.  Rather, it seems to me that somebody 
> thought SL was a good idea, and put it into the v6 
> architecture.  And then various people started saying "hey, 
> we can use SL for X", and nobody bothered to examine whether 
> there were conflicts between those various peoples' 
> assumptions (whether specifically about SL or not), or even 
> whether SL was worth the cost, until recently.

Fine, we need to create the list, figure out alternatives and as you
said in SF, push SL into the corner cases, if we still need it. Getting
rid of SL first does not solve the problems. 

> The problem with trying to make a list of "SL-related 
> problems" is that there is also a set of problems that don't 
> directly involve SL but also need to be solved, and SL 
> precludes solving those problems.

I agree there are several problems to be solved, but don't agree that
the existence of SL precludes solving anything. If we try to claim that
we don't need to work on solving problem X because SL solves it, then I
would agree, but so far I haven't heard anyone claim that we shouldn't
work on solving the problems. The only thing I have heard is that we
have found no use for SL (despite the shipping code that uses it),
without the list of basic requirements to judge which problems it does
solve.

Tony

---

From: Alain Durand <[email-masked]>
Date: Thu, 24 Apr 2003 14:59:57 -0700

I agree with Dave Crocker that the post from John Klensin is the
first one in thousand of emails that put the discussion in a new
(and very interesting) perspective.

In the goold old IPv4 word, locators & identificators are the same thing.
This is, as many people pointed out, the root cause for a lot of the
hard problems we see today, such as multi-homing & mobility.

We have made the problem even harder in IPv6 by adding more sementic
to specific addresses: we now have addresses that are non permanent
with privacy extensions (RFC3041), transition addresses (6to4, isatap,
IPv4 compatible,...), scoped addresses (Link locals and hoppefuly defunct
site locals), home address vs care-of address, crypto-generated addresses,
and the list grows every day.

Add to this that it is now more and more common for nodes to have multiple
interfaces to different types of networks with different physical 
caracteristics
(wired/wireless, high bandwidth, expensive access..)...

...and we made it even more complex now in the early days of coexistence
of IPv4 and IPv6, when an IPv6 address may have been registered in the DNS
but there is no actual IPv6 path to go there, or if there is
one, it is sometime so boggus that it leads to very bad performances.
(note: nothing to do with v6, just the sate of current deployment)

There is a proposal to create an API to enable the
application creating the socket to specify some of the
properties that it desires/requires. This is a step in the right
direction, but I'm not convinced this can go far enough.
So I fully support this idea of lifting the ban on TCPng
(or any transport layer for that matter) to de-couple
the abstraction needed by applications to the one required
by the network. This is in fact introducing some of the semantic
of a session layer between the application and the network.
Can this be done at the transport layer in the form of TCPng
or does this require and actual additional session layer?
I'm not sure at this point in time.

    - Alain.

---

From: Shannon -jj Behrens <[email-masked]>
Date: Thu, 24 Apr 2003 14:24:48 -0700

On Thu, Apr 24, 2003 at 12:55:29PM -0700, Tony Hain wrote:

(I'm going to clip much of this email to concentrate on those areas that need
further discussion.)

> needs to pass around. 

If A connects to B, and B wishes to pass the connection info to C, B only has
the address with which A accessed B.  If A and B are in the same site and used
site-local communication, and C is not in that site, B does not have enough
information to refer C to A.  Hence, your suggestion does not solve this case.

> Doing otherwise ignores the reality that the

I agree, and in fact, that's what I'm asking you how to work around.

> that interface / site context. 

That's true, and that sufficiently solves one side of the problem.  However, 
the other side of the problem is knowing which name resolver to go to in the
first place.  If I use my home resolver, I won't be able to get the address of
(e.g.) my printer, but if I use my work resolver, I won't be able to get the 
address of my toaster.  Do I need to always check both?  It seems that we're
encountering this situation because DNS implicitly assumes (at least in my
limited understanding) that choice of a DNS proxy should not affect the
results.

> because that was not a design requirement (again we need to agree on the

Well, that's a fair answer.

By the way, I do applaud your effort in making a site-locals requirements
document.  I think such a document will ultimately be useful if it presents
requirements in such a way that people who wish to replace the functionality
that site-locals provide know what needs replacing.

Thanks,
-jj

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Apr 2003 23:36:35 +0100

> persistant than, say, an internet draft, anyway.

No need to bother, just read any sample of 100 ipng emails in one day and
the same arguments come up again and again.  And again.

Is there a WG chair in the house?

Tim

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 18:43:10 -0400

> information need work, but DNS is one of those, so it is a good place to

disagree.  "starting" to work on this within DNS would be a distraction at
best.

> app is broken. 

false.  it happens all the time.   a function that converts a service name to
an address doesn't have to produce identical results each time to be useful. 
and yet, if two separate processes need to connect to the exact same process,
the service name alone may not be sufficient to allow them to do that. 

> Speed is an implementation issue, not a spec issue. 

false.  depending on how you architect a service there can be fundamental
and/or practical limits to speed. 

> In any case, it is much faster to pass a blob that can be mapped into

it's even faster if the network provides uniform addressing; then the
addresses are no longer useless.  why do you keep trying to force useless
addresses on us when we can have useful ones at less cost?

> issues you are complaining about. 

it's hardly relevant, since that's not the way things happened.

> This says nothing about firewalling,
> perceptions about the viability of those. 

yup.  and the realization that this is a lousy way to design a network

> The fact that over the years a

and in fact it's a very useful and compelling simplification.

> rid of SL first does not solve the problems. 

we've tried going on the assumption that SL will work, and we've not been able
to resolve the conflicts and problems that result from that assumption.  now
we need to try the assumption that we can do without SL, and see where that
leads.  perhaps we will find that we can do without SL, or perhaps we will
still need SL for a couple of corner cases.  we won't know for sure until we
try to work out the details, and we won't have completely decided for sure
until we actually approve a specification that incorporates those details. 
but that's the direction that the WG has decided to pursue, and I think it's
the right one.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 15:00:54 -0700

Please don't think I am picking on this instance, but the whole mode of
attack by finding a failure case, without thinking through alternatives
is a waste of everyone's time.

> I agree, and in fact, that's what I'm asking you how to work around.

See above about changing the message sequence.

> the other side of the problem is knowing which name resolver 
> to go to in the first place.  

Unless there is some hint in the name string, the only approach I know
of is to shotgun all the servers.

> If I use my home resolver, I 
> won't be able to get the address of
> address of my toaster.  Do I need to always check both?  It 
> seems that we're encountering this situation because DNS 
> implicitly assumes (at least in my limited understanding) 
> that choice of a DNS proxy should not affect the results.

Which is my argument to the IAB: the infrastructure components that pass
around topology information are completely out of step with the reality
of the deployed network topology. We need to fix this because it will
not get better on its own.

> ...
> > The fact that SL does not provide multiple concentric 
> security zones 
> > is not a failure of SL, because that was not a design requirement 
> > (again we need to agree on the problems to be solved).
> 
> By the way, I do applaud your effort in making a site-locals 
> requirements document.  I think such a document will 
> ultimately be useful if it presents requirements in such a 
> way that people who wish to replace the functionality that 
> site-locals provide know what needs replacing. 

I am not trying to claim I have all the answers, so if anyone has
content for it, please send them.

Tony

---

From: james woodyatt <[email-masked]>
Date: Fri, 25 Apr 2003 20:13:06 -0700

I've been following this thread with great interest for weeks, and only 
now do I think I have useful contribution to make to the discussion.  
It's long.  Sorry about that.  Cope.

> managers of large networks.

I don't know whether to laugh or cry.  Using a NAT doesn't give you 
address stability.  It's a total illusion.

Sure, your hosts all get RFC 1918 addresses that you assign yourself, 
but your NAT has to have at least one public realm address or the whole 
drill is pointless.  Without the NAT, you might as well set yourself up 
as your own private IANA-- you can be the King of Jellybeanland, if you 
like.

If you really want stable addresses, it seems to me (and correct me if 
I'm technically wrong about this) the only way you get that is to get 
yourself an AS number and a collection of prefixes and go into a BGP 
peering relationship.  Otherwise, you have to renumber every time your 
default route provider tells you it's your turn.

What the NAT really does for you is reduce the complexity of your 
renumbering events.  When the provider for your default route tells you 
it's your turn to renumber this week, you just renumber the NAT-- no 
manual editing of /etc/hosts with /usr/bin/vi is required on every 
Sun-3 on your network, isn't that nice?

Coping with the termination of application flows through the NAT when 
it gets renumbered is the main problem that has to be managed here.  
Note: site-local addresses and NAT do not solve this problem, and they 
were never intended for that purpose.  It's a problem that has to be 
managed in *any* renumbering, and the only way to avoid it is to avoid 
renumbering events entirely.  Good luck on that; write if you get 
funding.

If we're going to have a useful discussion about "the renumbering 
problem," we need to start by recognizing that it's more than simply 
reconfiguring routers and the bestiary of other middleboxen that seem 
to be inserting themselves into the network everywhere.

Applications have bad habits.

They cache network addresses when they should be caching names.  There 
is never a decent mechanism for keeping the cache coherent with the 
actual topology of the network.  Frequent renumbering exposes these bad 
habits.  Network administrators quickly learn that there is no pain 
more exquisite than explaining to the CFO that the reason the payroll 
isn't getting processed is that the ISP forced a renumbering and 
there's no good way to fix the application databases in the data center 
that have the wrong IP addresses stored in them.  Worse, you probably 
can't even sue the vendor for selling shoddy code because of the 
"as-is" "unwarranted" foo in the contract language.

And you might have written the code yourself.  Now *there's* pain.

So with IPv4, everyone uses a NAT, and they don't have this hassle.  
They have other huge hassles as a result, but at least they don't have 
*this* one.  And they love it.

Applications can continue to be written by code monkeys with no clear 
concept of how the network really works, they can cache network 
addresses in labels with permanent adhesive glue affixed to the rack 
where the equipment is mounted, they can treat network addresses like 
they map one-for-one with nodes (even nodes with multiple interfaces), 
they can even force lowly users to memorize them and transcribe them by 
hand, and the network administrators can still keep the business logic 
from crashing and staying down for a week when the public addresses of 
the site have to be renumbered.

Sometimes I think the biggest mistake we ever made was letting the 
application coders set their eyes on the bits in the network address.  
Giving them a human-readable representation was a mistake.  Even 
letting them know how many bits are in an address was ill-advised.  I 
know better of course, but then... *I'm* one of those poor souls with 
the dubious honor of having written an ALG for IPsec VPN applications.  
It's personal with me.

The really bad news-- I hate to break this-- is that IPv6 won't 
magickally make applications developers smarter.  When existing 
applications are extended to IPv6 and new applications are developed 
with IPv6 in mind, they will be developed by the same people with the 
same misconceptions about how the network works.  Our API's for using 
IPv6 look too much like the ones for IPv4 to break those misconceptions.

People will continue to cache network addresses on printed labels glued 
to the rack and they will continue to expect users to memorize and 
transcribe them by hand.  We can keep telling them not to do it, 
*but*... why should we expect them to start listening to us?  They 
never have done before, and we've been droning on about it for more 
years than I can count.

It would be just peachy if there was an architecture available that 
would preserve the E2E principle while still permitting organizations 
to shield their private applications from having to be just barely 
smart enough to respond well to their nodes experiencing the 
renumbering of their global unicast node addresses.  I don't think 
there is one.

I'm reminded of Oscar Wilde's reported last words.  Maybe we need to 
learn how to make the drapes match the rest of the decor.

If the problem with site-local addresses is that they cause more 
problems than they solve-- and I believe that to be true-- then, maybe 
solving the problems they cause is a good idea.  I have a radical 
proposal to that effect: deprecate the site-local prefix (on the 
grounds that it is overkill); disallow the propagation of routes for 
all V4MAPPED addresses; disallow the forwarding of packets with 
V4MAPPED addresses anywhere in the header; *except*, allow interior 
routing protocols, as a transition mechanism, to propagate routes for 
V4MAPPED addresses in prefixes that correspond to the RFC 1918 
addresses, and allow such packets to be forwarded on interior links.

This will permit impolite applications to move to IPv6 without having 
to learn better manners, while allowing network administrators a 
transition path for supporting their applications until they get 
versions that can handle renumbering events without bursting into 
flames.

And plusplusgood: it contains the disease within the quarantine wire of 
the IPv4 transition foo.  The addresses are all still about as 
memorizable as the ones we are all using now.  Even better, the 
function for getting the IPv6 address for a host from the IPv4 address 
that is printed on the label glued to the rack is to prepend the 
"::FFFF:" string to it and you're off to breakfast.  Still better: if 
you're clever, you can even forbid V4MAPPED addresses of every stripe 
from showing up in AAAA records by requiring applications that depend 
on this transition mechanism to work to convert IPv4 addresses into 
V4MAPPED addresses explicitly.

There.  I'm done.  Back to lurk mode.

-- 
j h woodyatt <[email-masked]>
that's my village calling... no doubt, they want their idiot back.

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Apr 2003 13:53:16 -0400

> They cache network addresses when they should be caching names.  

nice theory.  the fact is that names are imprecise; they're not always
bound to what we think they're bound to, there's no way to tell what
they're bound to, and the bindings are subject to change.  and DNS
in particular can be slow and unreliable.  

in short- you can lose by storing names in your application just as
easily as you can lose by storing IP addresses in your application.
anytime you do either one, you're making assumptions about the bindings
of those names or addresses with hosts that are subject to change,
often by factors outside your control.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Apr 2003 09:55:02 -0700

Stephen Sprunk wrote:

> When you are talking about tens of millions of customers, it's not feasible
> to give each a subnet even if you have the space to do it.  IMHO, most
> customers will be placed on a /64 that's shared across hundreds of
> customers, similar to IPv4 common practice.

Why?

Eliot

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 28 Apr 2003 11:23:25 -0500

Thus spake "Margaret Wasserman" <[email-masked]>
> Of course, this isn't why NAT is most often used...  NAT is most
> often used to extend a single address to cover multiple systems
> in a home or small office environment.  For that environment,
> an IPv6 /48 (without site-locals) would suffice to replace NAT.

There is nothing to indicate that ISPs are going to change their business
models simply because IPv6 address space is plentiful; they charge extra for
two hosts because it is assumed two hosts consume more bits than one, not
because a second IPv4 address is hard to come by.

S

---

From: Robert Elz <[email-masked]>
Date: Mon, 28 Apr 2003 22:37:20 +0700

Date:        Mon, 28 Apr 2003 05:53:20 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | In particular, you would still need to renumber your local network
  | (the global prefixes) when your provider-allocated global
  | addresses change.

Yes.

  | Having extra addresses available for internal
  | traffic (the site-locals) does not make renumbering the global
  | prefix any easier or less expensive.

No, that's simply wrong.   One of the biggest costs in renumbering
is the disruption it causes.   The actual cost of editing the files,
etc, is trivial by comparison.

If all of the internal operations of an organisation are going to
be disrupted, then the organisation is really going to resist any
renumbering.

But if everything just sails on through, operating as normal, then
adding a prefix, and later deleting an old one, is must less intrusive,
and less costly.

  | Although NAT causes various problems, it does offer a high degree
  | of provider-independence for internal nodes.  You won't get this
  | using provider-allocated global addresses in IPv6, no matter how
  | many other addresses you add to each node.

It would be nice if everyone would stop using "provider" in this context.

What matters here is the use of topology sensitive addresses.   If the
address reflects the topology of the network, then it has to change when
the topology changes.

It happens that in the current network environment, the topology is
controlled by the providers, so we have provider supplied addressing
to correctly reflect the topology.

Getting provider independent addressing is plausible - we just need
to make the network topology (somehow) stop being controlled by the
providers.

Getting addressing that is independent of the topology is a much more
interesting problem.  That one I don't believe we have any way to
accomplish yet, that works with routing.   Until we do, we need
addressing for local use.

  | Of course, this isn't why NAT is most often used...  NAT is most
  | often used to extend a single address to cover multiple systems
  | in a home or small office environment.

I think you're living in a sanitised enviornment.   NAT is used almost
everywhere (perhaps outside the US) - almost everywhere.

  | For that environment,
  | an IPv6 /48 (without site-locals) would suffice to replace NAT.

It might.   I'm not sure it will however.   I don't know that I want
even my home connectivity (connections between controllers and
appliances and such) to be disrupted when I change providers (or
when my provider alters the prefix temporarily allocated to me).

  | I am similarly disturbed that there are people who want to
  | specify site-local addressing because they think it will offer
  | the provider-independence currently offered by NAT.

I have no idea who those people are.   I am surprised that you (seem to)
believe that NAT offers provider independence.   It doesn't.   What it
does is allows the renumbering task to be simplified (quite a lot usually
in that case) - but that's all.   Site locals do the same, they allow the
renumbering task to be simplified, as there's one less thing that needs
to be worried about.

By no means do they solve the entire problem, they're just one nail.
But they (or something essentially equivalent) are required, something
needs to provide the kind of address stability that anyone can now have
in IPv4 using NAT.

We could recommend NAT for IPv6, that would certainly do it, but I hope
we don't, there has to be better ways than that.

If you think you have a better way than site locals, please describe it.

I don't want to know what you think the problems with site locals are,
I know they're not perfect.   I want to know what is the better solution.
Until there is one, site locals need to remain.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Apr 2003 05:53:20 -0400

Hi Robert,

>That is, whether it is SL, LL, or some random "global" prefix they calculated

Actually, it isn't true that an IPv6 global /48 prefix plus site
locals would provide all of the "benefits" of NAT.

In particular, you would still need to renumber your local network
(the global prefixes) when your provider-allocated global
addresses change.  Having extra addresses available for internal
traffic (the site-locals) does not make renumbering the global
prefix any easier or less expensive.

Although NAT causes various problems, it does offer a high degree
of provider-independence for internal nodes.  You won't get this
using provider-allocated global addresses in IPv6, no matter how
many other addresses you add to each node.

>of SL addressing by reference to NAT - that's simply too ludicrous (and sad)

I am similarly disturbed that there are people who want to
specify site-local addressing because they think it will offer
the provider-independence currently offered by NAT.

Margaret

---

From: S Woodside <[email-masked]>
Date: Mon, 28 Apr 2003 01:42:01 -0400

On Thursday, April 24, 2003, at 05:04  PM, Eliot Lear wrote:

> proxy gateways, STUN services, and MX gateways.  All of these exist 
> due to connectivity limitations (either intentional or architectural).

It strikes me that most of the symptoms of the problem have the word 
"gateway" in the name.

Talking about policy domains, it seems that there is an implicit 
assumption that they are necessary. And that makes sense from a 
security POV. But policy domains do not /require/ site locals or NAT. 
It's just as easy (with v6...) to get global addresses and not route 
them outside the domain.

Then if you conclude that policy domains are a Good Thing, or at least 
Necessary Evil, then why is there all this talk to design a network 
that can somehow route around them?

My point is that A sends B a third-party address C, and the policy of 
the domain is "you can't route that outside my domain" then it doesn't 
matter whether C is site local, global, uses DNS, or whatever. Policy 
says it still won't route!

simon

---

From: David Conrad <[email-masked]>
Date: Sun, 27 Apr 2003 19:38:37 -0700

Margaret,

On Sunday, April 27, 2003, at 05:21  PM, Margaret Wasserman wrote:
> As John Klensin pointed out on this same list several weeks ago
> (and I'm sure he said it better than I will), the decision to
> use ambiguous local addressing in IPv4 (i.e. RFC 1918 addresses)
> was partially motivated by the desire to conserve IPv4 address
> space.

Yes.  Of course, there were and are other reasons, the most significant 
of which is in conjunction with the use of NAT to provide some level of 
provider independence (both in terms of avoiding the necessity to 
renumber when changing providers as well as not having to "purchase" 
additional IP addresses from the service provider).

>  In IPv6, we don't have an address space shortage, so there
> is no reason to introduce architectural complexity to conserve
> address space.

While it is true that address conservation isn't that significant an 
issue, the whole issue of provider independence (or lack thereof) 
continues to exist.

Continuing to ignore this fundamental requirement on the part of 
enterprise network operators is getting us no where.  It certainly 
isn't getting us to IPv6 deployment.

Rgds,
-drc

---

From: Bill Manning <[email-masked]>
Date: Sun, 27 Apr 2003 22:24:52 -0700 (PDT)

% As John Klensin pointed out on this same list several weeks ago
% (and I'm sure he said it better than I will), the decision to
% use ambiguous local addressing in IPv4 (i.e. RFC 1918 addresses)
% was partially motivated by the desire to conserve IPv4 address
% space.  In IPv6, we don't have an address space shortage, so there
% is no reason to introduce architectural complexity to conserve
% address space.
% 
% Margaret

	"dont' have an address space shortage..." - Margaret 
	-YET-
	IPv4 didn't have one either, in its early days.

--bill

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Apr 2003 20:21:50 -0400

space.  In IPv6, we don't have an address space shortage, so there

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Apr 2003 20:17:55 -0400

Hi Dave,

>consideration of its difficulties.

I wrote such a document.  It can be found at:

http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt

This is a personal draft, not a work item of the IPv6 WG.

Margaret

---

From: james woodyatt <[email-masked]>
Date: Sat, 26 Apr 2003 20:11:52 -0700

On Saturday, Apr 26, 2003, at 10:53 US/Pacific, Keith Moore wrote:
> [I wrote:]

All true.  I think I've miscommunicated.

My observation was about applications that require address stability 
when they really should be using stable names in a naming authority 
they control and doing the extra lumping work of implementing a real 
directory service.  DNS is one way to store a mapping between names and 
network addresses.  There are others available, e.g. SLP, Rendezvous, 
etc.

> often by factors outside your control.

Applications lose.  No big surprise for me.  The problem for which I'm 
trying to help fish out a solution: how to get applications to move to 
IPv6 without giving people reason to think they need site-local 
addresses and IPv6 NAT boxen.

Let me be clear: if I find myself porting all my IPv4 ALG's to work in 
an IPv6 NAT, I will-- without any hesitatation-- go Stark Fleming Mad.  
I may take some of you with me with me.

-- 
j h woodyatt <[email-masked]>
markets are only free to the people who own them.

---

From: [email-masked]
Date: Mon, 28 Apr 2003 03:12:23 -0400

> app is broken. Speed is an implementation issue, not a spec issue. In

This is going to come as quite the shock to every website that includes
URLs of the form http://www.foo-bar.com/whatever  where foo-bar.com is
resolved with a round-robin DNS.  I'm also surprised that apps using SMTP
are so ready to hand around blobs of the form '<[email-masked]>' and *totally* not
caring which server it gets handed to - such broken behavior HAS to be
stamped out IMMEDIATELY. :)

Some quick back-of-envelop calculations indicate that quite likely over
half of all traffic on the Internet, and possibly 75%, are the result of
apps that are "broken" by your definition.

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Apr 2003 20:32:06 -0400

>carved in stone, and these particular omissions are easy to fix.

There is currently no RFC that defines the usage model for IPv6
site-local addressing.  The prefix is defined in the addressing
architecture RFC (currently at PS), but the usage model is defined
in the scoped addressing architecture (a WG I-D).

This I-D has been relatively stable for a couple of years, but has
not gone to the IESG, mostly due to IPv6 WG deadlock over the
architectural issues regarding site-local addressing.  During that
time, we have been slowly working through the various architectural
issues caused by site-local addressing, and building WG
consensus regarding what to do about it.

So, I think that this is actually a case of the WG process working
properly (if a bit too slowly).

Margaret

---

From: james woodyatt <[email-masked]>
Date: Sat, 26 Apr 2003 20:15:59 -0700

On Saturday, Apr 26, 2003, at 20:11 US/Pacific, james woodyatt wrote:
>
> [...] Let me be clear: if I find myself porting all my IPv4 ALG's to 
> work in an IPv6 NAT, I will-- without any hesitatation-- go Stark 
> Fleming Mad.  I may take some of you with me with me.

Apologies for the typographical errors.  And I should have written 
"Flaming" not "Fleming"-- that was an unintentional slip on my part.  
Please forgive me.

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 29 Apr 2003 10:20:29 -0500

> to give each a subnet even if you have the space to do it.

Why on earth not?  You give them one "thing" either way.  Same
overhead to issue, same overhead to route.

> because a second IPv4 address is hard to come by.

This is not the least bit believable.

---

From: John C Klensin <[email-masked]>
Date: Tue, 29 Apr 2003 12:31:54 -0400

--On Sunday, 27 April, 2003 22:24 -0700 Bill Manning 
<[email-masked]> wrote:

> % As John Klensin pointed out on this same list several weeks
> ago % (and I'm sure he said it better than I will), the
> decision to % use ambiguous local addressing in IPv4 (i.e. RFC
> 1918 addresses) % was partially motivated by the desire to
> conserve IPv4 address % space.  In IPv6, we don't have an
> address space shortage, so there % is no reason to introduce
> architectural complexity to conserve % address space.
> %
> % Margaret
>

Bill, regardless of what other features are there and what other 
justifications might exist, the primary problem and hence design 
goal that brought IPv6 into existence was "not enough address 
space".   If we can (even in our paranoid moments) reasonably 
anticipate running out of space, then it is time to send the 
IPv6 addressing architecture back to the drawing board and 
replace it with something that supports variable or 
extensible-length addresses.   I really can't imagine a rational 
enterprise voluntarily deciding to convert to IPv6 if they are 
told it only has a lifetime of NN years, where NN is less than 
at least a major fraction of a century.

For that purpose, I think "running out of space" can be defined 
as finding ourselves with a need to adopt allocation policies or 
strategies (now or later) that force people into non-unique 
addresses to conserve space.

It seems to me that if you, or anyone else, wants to make the 
case that the IPv6 address space isn't going to be large enough, 
you need to do so explicitly and immediately (five years ago 
would have been better, but maybe we know more now).   While I, 
personally, would have preferred extendable length addresses, it 
feels to me that saying "yet" at this stage in the game is just 
pointless sniping unless you are willing to argue for calling a 
halt at this stage and redesigning.

    regards,
        john

---

From: [email-masked]
Date: Tue, 29 Apr 2003 13:33:28 -0400

> This is not the least bit believable.

It's quite believable, in the context of an industry where some providers
don't want you to use a VPN from your home to your office unless you've bought
the "business class" service for $50/mo more, and others are doing various
bait-and-switch, advertising a fast connection and then capping the actual
throughput because they haven't provisioned sufficient backbone to support
the advertised rate...

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 29 Apr 2003 11:24:29 -0700

g'day,

Nothing like a good schism to get the juices flowing, no? As this
ongoing debate continues, I have one question on this whole NAT/Site
Local/"Monophysitism versus Nestorism" thing, then one observation:

First, the question.

I keep seeing offhand remarks about some foobar amount of traffic is
NATed, some mubblefink amount of NAT addressing is done because of
address scarcity, while another babblebrush amount of ISPs will be
allocating IPv6 addresses to individuals out of single /64s, so they
wont even get their own /48s, etc, etc. Can someone please point me to
the real, definitive studies and the concrete data that you're all using
as the basis for this debate? 

Right now, everyone seems to be engaged in a cyclic round of "No It Is!
Yes it Isn't" polemic that boils down to a schism within the IETF
priesthood - some believe in a single, divine Eutychian or Monophysitian
address space, others contemplate a dual, Nestorian system. I'd
personally feel better if I felt the alternative positions were based
upon alternative interpretation of some firm scientific data, but from
what's going by at least on the ietf general list, this comes across as
a clash of belief systems, not a clash of scientific principles.

I personally suspect that the Nestorians are on to something here, but
I'd be happy to study the data and reach an alternative conclusion if I
could have something beside this on-going "Jane, you ignorant slut"
level of debate.

So here are a few things we could ask:

    - So what percentage of machines really are being NATed right now?

    - What percentage of traffic is generated and consumed by NATed
hosts?

    - What's the deployment rate of IPv6 (ie. is it growing fast enough
      to matter to me in five years?)

and so on...

I would like to think some real data might help us a bit here to find
the path out of the woods. All I'm seeing on this list are affirmations
of faith. Please, how about sharing a little more of the hard science
behind your conclusions, folks?

And now, my observation:

Robert Elz wrote:
...
> addressing for local use.

As I read this my first reaction was "great observation, it's good to
see a new idea enter this debate". Then, a milliblip later my brain
fired a neuron that yelled out "Hey, aren't NATs just a means for users
to provide themselves with a topologically independent addresses to
divorce them from the topologically oriented address space imposed on
them by their ISPs?"

There are lots of good reasons to go for a Monophysitian address space,
so presumably there must be some compelling alternative reasons why
people keep ignoring this principle. It looks like we might want to add
"provides non-topologically structured address space" to the list of
advantages for NATs. Personally, I believe that 142 percent of the
people that install NATs do it for this reason alone!!  ;-)

				- peterd

PDF: Oh, and for those who missed my subtle hidden message, both
Nestorism and Monophysitism are now regarded as heresies by those who
ended up in charge of such things in that other priesthood down the
road...

-- 

---------------------------------------------------------------------
    Peter Deutsch                       [email-masked]
    Gydig Software

  "Next to Nestorianism, Monophysitism produced the greatest schism
   that the Eastern Church had suffered."

        http://www.ewtn.com/library/chistory/eveislam.htm
            http://www.newadvent.org/cathen/05633a.htm

---------------------------------------------------------------------

---

From: Dean Anderson <[email-masked]>
Date: Tue, 29 Apr 2003 15:28:33 -0400 (EDT)

We are still not out of IPv4 address space. I don't know the projections
for address space depletion, but I think the IPv6 problem won't be so much
address space depletion as route space depletion. I think it will be
unwieldy to have a million or 2 million or 10 million distinct routes.
Aggregation won't happen the way things are currently organized.

<soapbox> I think the RIRs (at least for IPv6) need to be organized
differently. In order for address space to be hierachical, for efficient
aggregation and routing, addresses have to be given out locally, like
phone numbers.  Unfortunately, that isn't how ISP's or the address
registries are organized. Fees are strongly biased towards big companies,
yet the small and medium sized companies generate most of the revenue.
It costs way too much money to get IPv6 space for every town to have their
own address space, so that even barn, cow, and coke machine can be
connected to the internet.  Something needs to give.  </soapbox>

		--Dean

---

From: John Stracke <[email-masked]>
Date: Tue, 29 Apr 2003 15:18:19 -0400

>    - What percentage of traffic is generated and consumed by NATed
And, if someone answers, the next question is, how do they know? NATs 
are essentially invisible from the outside.

-- 
/=================================================================\
|John Stracke      [email-masked]                          |
|Principal Engineer|http://www.centive.com                        |
|Centive           |My opinions are my own.                       |
|=================================================================|
|Vote for Ron, and nobody gets hurt! --actual campaign poster from|
|Chicago                                                          |
\=================================================================/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 29 Apr 2003 22:23:17 +0200

On dinsdag, apr 29, 2003, at 20:24 Europe/Amsterdam, Peter Deutsch 

>       to matter to me in five years?)

How is answering any of these questions going to help us? "Oh, NATed 
traffic is 7% and not 5%! You are right we should have site local 
addresses then!"

The current state of IPv6 deployment has very little bearing on future 
IPv6 deployment. Just look back 20 years in IPv4. I don't think any of 
the problems we have today could have been predicted by looking at the 
network then.

>> to make the network topology (somehow) stop being controlled by the

:-)  And I thought I'd seen it all in multi6.

> divorce them from the topologically oriented address space imposed on

No, of course not. That's like saying English is the official language 
of China because when you read about something said in China it is 
translated in English.

The problem with renumbering isn't the address the host thinks it has 
itself, but the address others think it has. We have well-established 
procedures for assigning addresses to hosts. Changing the address a DNS 
name points to is much, much more difficult, and changing references to 
addresses elsewhere, such as in filter configurations, is a nightmare.

> people that install NATs do it for this reason alone!!  ;-)

I wouldn't presume to know why people use NAT because I'm not one of 
them. (Beginning to feel like a minority.) But let me make some 
observations:

- If we don't give people any sort of private address space, many will 
just take something and at some point some of this will clash with 
something else.

- If we set aside a small range of addresses for private use, many 
people will use the same addresses so when networks merge there will be 
trouble. In IPv4, this is often solved with NAT. So in IPv6 the same 
will happen OR people will have spend a lot of time and money 
renumbering.

- If we allow people to register non-routable globally unique addresses 
for private use, eventually some of this address space will leak out 
into the global routing table. In IPv4, filtering private address 
ranges and long prefixes is well-established and if and when this 
fails, the consequences are negligible.

So it seems to me that we are trying to make up our mind between a rock 
and a hard place while in fact a third option is almost completely 
painless.

We may also want to contemplate the difficulty of attaching secure 
services to ambiguous address space.

---

From: John C Klensin <[email-masked]>
Date: Tue, 29 Apr 2003 16:26:22 -0400

Dean,

Since you have responded to a comment of mine, let me summarize 
my reasoning with regard to the "out of IPv4 address space" 
problem.  Your assumptions, views, definitions, religion, etc., 
may differ.

--On Tuesday, 29 April, 2003 15:28 -0400 Dean Anderson 
<[email-masked]> wrote:

> We are still not out of IPv4 address space.   I don't know the
> projections for address space depletion,

One view of "address space depletion" is that projections are 
useless in an environment in which (i) the RIRs believe that 
their job is to prevent us from running out of space and (ii) 
they are good at their work.  Those two statements imply that 
policies will adjust as they perceive we are getting closer to 
running out of space and, in turn, two seemingly-contradictory 
statements about the date on which we run out of IPv4 space:

	(1) We will _never_ run out of IPv4 space, but you
	really don't want to be the entity that asks for the
	next-to-last block (or any other block after your local
	RIR starts feeling significant end-game pressure).
	I.e., while we won't run out, getting space with get
	more and more expensive and/or aggravating, going up by
	step functions.
	
	(2) Given that model, it is more appropriate to look at
	the date at which it gets sufficiently difficult to get
	unique, globally-routable space (note that I did not say
	"PI") that people with a legitimate requirement for it
	perceive themselves as being unable to get it, or enough
	of it to meet their requirements.  Even 1918 recognizes
	that there are hosts that should have public addresses.
	To the extent that policies about IPv4 allocations are
	forcing such hosts behind NATs --or substitutes the
	judgment of RIRs or ISPs about what should, and should
	not, be public for that of local network
	managers/designers, or make it economically implausible
	to have public hosts-- then we have already passed that
	date.  And, to oversimplify things somewhat, it is
	accurate to say that we have already run out of space,
	because a rational criterion for "run out of space" is
	that it forces us into architecturally pathological
	behavior.

> but I think the IPv6
> problem won't be so much address space depletion as route
> space depletion. I think it will be unwieldy to have a million
> or 2 million or 10 million distinct routes.

Many of us agree with you, at least within the constraints of 
the current routing regime and models.  But the question, on one 
side, is how to organize IPv6 allocations so that we don't have 
that problem.  One theory is "almost no PI space except in very 
large aggregates, multiple (provider-dependent) addresses per 
host.  As far as I can tell, that is the path we are going down. 
But it involves a number of tradeoffs which have, perhaps, not 
been explored and articulated as well as is desirable.  One of 
them is that the strategy uses up addresses faster than the 
network grows (in host counts), even while it may conserve 
routing space.  If you can anticipate the possibility of an RIR 
eventually telling an ISP "you can't count networks in your 
request for a larger allocation if they already have addresses 
from another provider", then we are in danger of being "out of" 
IPv6 address space coming out of the gate -- and that is one 
example of the motivation behind my challenge to Bill... and 
perhaps even of his "yet" comment which led to my challenge.

> Aggregation won't
> happen the way things are currently organized.

Maybe.  See above.

> <soapbox> I think the RIRs (at least for IPv6) need to be
> organized differently. In order for address space to be
> hierachical, for efficient aggregation and routing, addresses
> have to be given out locally, like phone numbers.
> Unfortunately, that isn't how ISP's or the address registries
> are organized. Fees are strongly biased towards big companies,
> yet the small and medium sized companies generate most of the
> revenue. It costs way too much money to get IPv6 space for
> every town to have their own address space, so that even barn,
> cow, and coke machine can be connected to the internet.
> Something needs to give.  </soapbox>

Your conclusion may be right, but I don't think the reasoning in 
the paragraph above works.   Let me restate it to see if I can 
explain why.

The only way we know for address space to be efficiently 
aggregated and routed is to make it hierarchical, and for that 
hierarchy to reflect routing realities.  Unless we either change 
the business models of the industry, or create the type of 
regulatory regime that characterized the PSTN a few decades ago 
(which may be just one form of changing the business models), 
the hierarchy has to follow provider topologies and 
interconnection structures.

It makes sense for every town to have its own address space only 
if every town has a sufficient number of exchange/ 
interconnection points with other towns, or backbone providers 
of one sort or another to give the town global connectivity. 
But, in the general case, that is going to require a regulatory 
regime -- it isn't obviously in the interest of the ISPs, either 
technologically or economically, to make things work that way.

Of course, "address space per country" and, typically, address 
space per entity within country, is exactly the way address 
allocations work in the PSTN under the E.164 Recommendation/ 
System.  But, if that type of address structure is to be used 
for routing, it depends on a collection of bilateral agreements 
(and exchange points) between countries, plus local and national 
routing regimes that are traditionally highly regulated (today's 
"deregulated" environment depends on the previous regulatory 
structure in a number of important ways), involve specialized 
and sometimes subsidized exchange points, small numbers of 
interexchange carriers relative to the number of exchanges (or 
event "towns"), etc.

I don't think we want to go there, but your opinions may, again, 
differ.

     john

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 29 Apr 2003 15:30:18 -0500

> > > ... they charge extra for two hosts because it is
> > > assumed two hosts consume more bits than one, not because a
> > > second IPv4 address is hard to come by.
> > 
> It's quite believable, in the context of blah blah blah ...

Nothing you've said establishes any likelihood that the reason for
charging more is the expected consumption of more bits.

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 29 Apr 2003 14:09:00 -0700

> are essentially invisible from the outside.

Actually, there are ways Marketing folks determine such things. They
count the total number of NAT boxes sold, compare this to the total
number of other routers sold, they use (sometimes statistically valid)
sampling methods to survey customers on their deployment patterns, etc.
From this they can provide market segment data for the engineers to do
their planning. Oh, and while at Cisco I met marketing folks who appear
to do something with slaughtering chickens and looking at their
entrails, although I never did figure out how that worked... ;-)

			- peterd

-- 

  "It is inhumane, in my opinion, to force people who have a
   genuine medical need for coffee to wait in line behind people
   who apparently view it as some kind of recreational activity."

                                        -- Dave Barry

---

From: Joe Abley <[email-masked]>
Date: Tue, 29 Apr 2003 17:09:19 -0400

> are essentially invisible from the outside.

They're not quite that invisible. See, for example:

   http://www.research.att.com/~smb/papers/fnat.pdf

Joe

---

From: John Stracke <[email-masked]>
Date: Tue, 29 Apr 2003 17:15:04 -0400

Peter Deutsch wrote:

>Oh, and while at Cisco I met marketing folks who appear
You have to use a Bayesian chicken.

-- 
/=====================================================\
|John Stracke      [email-masked]              |
|Principal Engineer|http://www.centive.com            |
|Centive           |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/

---

From: John Kristoff <[email-masked]>
Date: Tue, 29 Apr 2003 16:45:44 -0500

On Tue, 29 Apr 2003 22:23:17 +0200
Iljitsch van Beijnum <[email-masked]> wrote:

> - If we allow people to register non-routable globally unique
> addresses for private use, eventually some of this address space will
> leak out into the global routing table. In IPv4, filtering private
> address ranges and long prefixes is well-established and if and when
> this fails, the consequences are negligible.

This seems OK to me and appears to put the burden in the right place. 
Shouldn't it be the responsibility of those who are allocated address
space to properly manage it?  Others can still filter on long and valid
prefixes that they expect to hear.

...and if its gonna leak anyway, it might as well be globally unique. 
Other networks will certainly be less likely to collide and try to
communicate with the leaked space.

John

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 29 Apr 2003 15:41:43 -0700

g'day,

> traffic is 7% and not 5%! You are right we should have site local

Well, I've a couple of responses to that.

One, of course is that if NAT traffic is really only 5%, and it happens
to be falling over time, then we should maybe stop spending so much time
arguing about it. :-)

(Note, if I really wanted to be excommunicated from this list, I could
have done a s/NAT/IPv6/ on the above paragraph ;-)

More to the point, folks are throwing around quite a few categoric
statements of fact and I assume they do this to help persuade others to
their point of view.

Here's a quick sampling of statements presented over the past few days
to support the two sides of the debate (Note, Please don't take offense
if you recognize your own words in this list - I'm not criticizing the
authors or disputing the facts, just assuming that the authors are
expecting folks to make decisions based upon these claims, and so was
thinking it could be useful if at least some of these claims could be
substantiated or disproved):

    - "there are more rfc1918 end hosts than there are non-rfc1918
       end hosts, and the uses being made of rfc1918 aren't limited
       to "couldn't get enough unique address space" situations."

     - "NAT is most often used to extend a single address to
        cover multiple systems in a home or small office 
        environment. For that environment, an IPv6 /48 
        (without site-locals) would suffice to replace NAT."

     - "NAT is used almost everywhere (perhaps outside the US)
        - almost everywhere."

     - "When you are talking about tens of millions of customers,
        it's not feasible to give each a subnet even if you have
        the space to do it.  IMHO, most customers will be placed
        on a /64 that's shared across hundreds of customers, similar
        to IPv4 common practice."

     - "While it is true that address conservation isn't that
        significant an issue, the whole issue of provider
        independence (or lack thereof) continues to exist."

     - "One of the biggest costs in renumbering is the 
        disruption it causes. The actual cost of editing
        the files, etc, is trivial by comparison."

     - "Even RFC1918 addresses get connected sometimes through
        corporate mergers. It would work better if organizations
        would choose a random set of subnets from 10/8, so the
        chance of overlap is minimized."

     - "They [ISPs] charge extra for two hosts because it 
        is assumed two hosts consume more bits than one, not
        because a second IPv4 address is hard to come by."

Now, it may be true that *all* of the above statements are true, but
they don't help me because I can't tell, from the statements alone,
which ones are actually *relevant* to the debate. So, just as in your
somewhat offhand use of "7% versus 5%" above, it all seems a little bit
like the statement that "46 percent of all statistics are made up". So,
which is it - seven percent, or over half?? For a bunch of architects,
folks around here don't seem as concerned about the foundations as I'd
have expected... ;-)

> the problems we have today could have been predicted by looking at the

Well, this is a good example where something may be true, but not
relevant. If, after all this "Sturm und Drang", IPv6 is not yet growing
faster than overall network traffic, those of us who remember X.500 may
conclude that it's not going to be relevant to me within an event
horizon that I need to care about, so I might conclude that I can ignore
it (and by extension, arguments predicated on its success). Now, this
may get me excommunicated from this list, but it may be the right thing
for me to do. How can I tell from this thread? I could be persuaded to
pay attention to such arguments by some numbers.

Another observation, there appears to be at least two major schools of
philosophy at work here (time for another random analogy for you Science
majors to go look up on Google... ;-)

One school appears to be focused on the problems of the locally Self
Sufficient Network User, with his own clsuter of simple machines behind
a NAT box (Sort of a Network Thoreau, in which we are each building our
own local "Walden Puddle". We learn to adapt to scarcity by making
frugality and reuse a virture, etc).  The big issues are whether certain
applications can work behind NATs, will I interfere with others, and so
on. 

The other school appears to be focused on the needs of large corporate
Networks. Here the focus is on renumbering issues, folks assume network
admins are in charge of and care about routing issues, etc. The Super
Administrator is assumed to have more intelligence and Power than the
average user here (Sort of Nietzsche's UberMensch, running his UberNet,
if I may be so bold);

Now, if "there are more rfc1918 end hosts than there are non-rfc1918 end
hosts" and "NAT is most often used to extend a single address to cover
multiple systems in a home or small office" then I might be inclined to
give more weight to arguments which make the network a better place for
the Thoreaus of the world (or is that "Bllom County"?), but if the most
important issues for our future are really going to be about supporting
large campus installations, it might drive the trade-offs in a different
direction. There Are No Free Lunches, so knowing what the target is
might help us all collectively take better aim....

...
> of China because when you read about something said in China it is

But then you state:
...
> them. (Beginning to feel like a minority.) 

Well, if anyone's going to argue against them, shouldn't they at least
understand why they're being deployed?? ;-)

But let me make some
> will happen OR people will have spend a lot of time and money

Again, just to illustrate my thesis, in the above response you seem to
assume:

	- network merging happens often enough that it is a significant
          problem that must be addressed at the architectural level
          (that is, here at the IETF);
	- it costs a lot of time and money to renumber.

If either of these assertions is not true, you have to go back to the
beginning and start again. Ergo, knowing whether such
assumptions/assertions/axioms are true would be useful for those of us
trying to follow along without a program...  QED

				- peterd

-- 

                                        -- Dave Barry

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 29 Apr 2003 18:09:04 -0500

Thus spake "S Woodside" <[email-masked]>
> that can somehow route around them?

There's reasonable arguments against private addresses, but unless
allocation policies are radically different than IPv4 practice, expecting a
public address for every host is a pipe dream.

Sidebar: a thread has recently popped up on nanog regarding the practice of
assigning public addresses to unconnected networks or hosts behind
firewalls.  It's not clear whether those for or against are in the majority,
but the mere presence of the debate is rather telling.

> says it still won't route!

The expected usage model was that all hosts would have a site-local address
as well as zero to many global addresses.  Since we don't yet know how to
handle multiple addresses per host cleanly, the removal of site-locals is
thought to reduce the problem's complexity since site-locals are for some
reason assumed to have different semantics than globals.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 29 Apr 2003 18:21:56 -0500

Thus spake "Iljitsch van Beijnum" <[email-masked]>
> traffic is 7% and not 5%! You are right we should have site local

But if the number were 50% or higher, I'd think that would have some bearing
on things.  If nothing else, it should convince the anti-NAT crowd to work
harder at finding other solutions.

> fails, the consequences are negligible.

Without an explicit directive from the IETF (a la RFC2050), the RIRs will
not do this.  In words attributed to an ARIN staffer, "We only register
addresses for the Internet, not private networks."

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 29 Apr 2003 18:32:11 -0500

Thus spake "John Kristoff" <[email-masked]>
> prefixes that they expect to hear.

Or, if these non-routed allocations were from a specific IANA-designated
block, providers could simply filter them all with one directive.

> communicate with the leaked space.

Certainly.  However, providers tend to advertise whatever customers pay them
to advertise, so these "non routable" blocks may end up permanently
reachable from non-trivial portions of the Internet.

There are many applications, such as pre-positioned content caching, where
it's desirable to only have connectivity to those topologically "close".
Overall, though, this makes it even more important that we find a workable
solution to the multiple-address problem.

S

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Apr 2003 16:44:59 -0700

Stephen,

I'm glad you sent this note.  One of us is under a serious 
misconception, and if it's you, I suspect there are a lot more like you.

> public address for every host is a pipe dream.

Tell me if http://www.arin.net/policy/ipv6_policy.html addresses your 
concern.  Particularly section 3.2.  The policy, as I read it, gives 
just about everyone a /48.  When counting subnets and interfaces on 
routers, consider that the equivalent of an IPv4 /16.  That's a lot of 
space.  According to the above document, there's no real experience of 
someone having hit that point yet.

Eliot

---

From: S Woodside <[email-masked]>
Date: Tue, 29 Apr 2003 19:48:23 -0400

On Tuesday, April 29, 2003, at 12:31  PM, John C Klensin wrote:

> It seems to me that if you, or anyone else, wants to make the case 
> that the IPv6 address space isn't going to be large enough, you need 
> to do so explicitly and immediately

John,

For purposes of geographic routing, it seems a little tight. Consider 
this proposal [1]

         | 4 |            44           |   16   |          64 bits       
    |
         
+---+-------------------------+--------+---------------------------+
         |FP |        Reference        |  SLA   |       Interface ID     
    |
         
+---+-------------------------+--------+---------------------------+

44 bits are provider independent and encode GPS coordinates. It's 
enough to have accuracy to roughly 10 meter squares. BUT ... that 
doesn't consider altitude. In addition, it's quite easy to see that 10 
meter squares may be a little bit too big for some purposes, even if 
you're just talking about individual homes. Also, it doesn't provide a 
mechanism to define an area rather than a point. I could go on.

So it's clear at least to me that under this scheme there is not enough 
space in IPv6 to do proper justice to georouting.

simon

[1] http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-04.txt

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 29 Apr 2003 18:45:35 -0500

There are some applications, such as pre-positioned content caching, where
it's desirable to only have connectivity to those topologically "close".
Overall, though, this makes it even more important that we find a workable
solution to the multiple-address problem.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 29 Apr 2003 19:11:11 -0500

Thus spake "John C Klensin" <[email-masked]>
> halt at this stage and redesigning.

I see no reason to believe that the address length is insufficient on its
own; however, allocation policies and the way those bits are used may cause
exhaustion and/or a different way of looking at those bits.

Based on the number of hosts connected to the Internet today compared to the
total number of unicast IPv4 addresses, we are nowhere near a shortage.
Even so, pre-CIDR allocation policies resulted in vast amounts of unused
space.  Rationing of the remaining space has made NAT a necessary evil just
to keep the beast functional for the masses.

Are we doing the same thing with IPv6?  Maybe.  At worst, we're not making
any mistakes we can't correct later when we learn more.  I'm particularly
suspicious of the decision to use a /64 for each subnet instead of the
original /80 plan, and the allocation of a /3 to the RIRs is mind-boggling.
But I do think we bought ourselves enough headroom to seriously screw up
several times and not need a whole new protocol.

S

---

From: [email-masked]
Date: Wed, 30 Apr 2003 10:48:11 +1000

> because a second IPv4 address is hard to come by.

	There is nothing to indicate that they won't change either.

	ISP will meet their customers expectations or they will go
	out of business.  Today you expect to get a single IP address.
	If you make the expectation be that you will get a prefix ISP
	that fail to do this will go the way of the dodo.

	The cable provider I'm using didn't allow home networks at
	one time (they also had a single flat fee).  They do now
	though they leave the implementation and support to you
	(multiple volume based plans).  Customers expect to be able
	to connect their home network and the expectation is now
	being met.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 29 Apr 2003 18:10:24 -0700

S Woodside wrote:
> ...
> 44 bits are provider independent and encode GPS coordinates. 
> It's enough to have accuracy to roughly 10 meter squares. 

The 04 version reduced that to 6.4 m, but your point about it being
somewhat course is valid. I stopped at 44 bits because the goal was
creating a /48. If that is expanded to a /52 you are looking at > .5 m
resolution. While this is possible to encode, the publicly available
gear is not capable of measuring that accurately.

> BUT ... that doesn't consider altitude.  

Depending on the intended use, that can be further encoded in the
remaining bits to create a unique /64 per cubic .5 m, 2 km deep. 

> In addition, it's quite easy to see that 10 

We have the option of using longer than /64 prefixes if necessary. I
would prefer not to go there, but given a unique need it could be done.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Apr 2003 10:01:11 +0200

On woensdag, apr 30, 2003, at 00:41 Europe/Amsterdam, Peter Deutsch 

> to be falling over time, then we should maybe stop spending so much 

Either we must support NAT or we don't. The actual usage of NAT at any 
given point of time really doesn't tell us which of those is the more 
reasonable position. It is not unheard of to support something that 
only 5% or less of the users need.

> have done a s/NAT/IPv6/ on the above paragraph ;-)

By this reasoning there is no point in inventing something new because 
at the time of invention deployment is by definition 0.

IPv4 address space is running out. So the IETF did the responsible 
thing and developed a new protocol that wouldn't have this problem. If 
people then fail to adopt this protocol, well, that's their problem.

> to support the two sides of the debate

>        end hosts,

Ok, this sounds like hyperbole to me.

>        and the uses being made of rfc1918 aren't limited

>      - "NAT is used almost everywhere (perhaps outside the US)

Now these are all very interesting but what does it prove? Yes, we know 
NAT _is_ being used in IPv4 and yes, we know you _can_ do without it 
given enough public address space.

>         to IPv4 common practice."

This is actually a good point, although this may not seem obvious to 
non-ops people. Today, dial-up concentrators usually have an address 
range that it used to assign addresses to people that dial in. That 
means at most a handful of routes per dial-up concentrator in the 
interior routing protocol. If everyone has their own /48, that means a 
route in the IGP for each customer that's online. There are no hard and 
fast rules about how many routes you can have in an IGP, but somewhere 
between 10k and 1M you run into trouble. I hate to offer opinions 
without facts to back them up, but I'm pretty sure there are dial-up 
ISPs with closer to 1M than 10k ports.

However, assigning each customer an IPv6 /64 the same way they now get 
an IPv4 /32 should be workable.

>         independence (or lack thereof) continues to exist."

What is your problem with this? Seems like a valid statement to me.

>         the files, etc, is trivial by comparison."

Some figures would be good here, but from my experience this doesn't 
sound too far off.

>         chance of overlap is minimized."

Ok, this is something I'd like to see. My gut says this is too simple, 
but maybe not...

>         because a second IPv4 address is hard to come by."

This one would also be interesting to put into numbers. If this is 
really true we can expect a /64 to be 2^64 times as expensive as a /32 
in IPv4...

> which ones are actually *relevant* to the debate.

I have to agree with you there.

> So, just as in your
> like the statement that "46 percent of all statistics are made up".

The 7% and 5% are definately made up.

> relevant.

The statement above may not be directly relevant to the discussion, but 
it should disprove your assumption that IPv6 deployment today is.

> If, after all this "Sturm und Drang", IPv6 is not yet growing
> it (and by extension, arguments predicated on its success).

At some point this argument is going to stick, but at this point it is 
too soon to tell whether current low levels of v6 deployment are 
because everyone is taking their time or because it's never going to 
amount to anything.

> Now, this

When I connected to the 6bone a year or two ago, all I could do over 
IPv6 was traceroute from a server. Today, I browse the web on a fully 
IPv6-enabled host with mostly IPv6-enabled software so I get to see 
some actual web content over IPv6. Also, I regularly use IPv6 for other 
applications. It's still not much compared to IPv4, but the progress 
has been remarkable.

> majors to go look up on Google... ;-)

Maybe you should pick the rationalists versus the empiricists for your 
next example...

> might help us all collectively take better aim....

If I buy ADSL or cable service I get a single IPv4 address unless I pay 
a lot extra. Since I have more than one computer, I am forced to use 
RFC 1918 space. I wouldn't want anyone to pervert my lack of choice 
into a position supporting NAT in IPv6.

> understand why they're being deployed?? ;-)

Obviously I can think of one or two reasons. But when I see NAT, I see 
problems. Some people seem to actually like NAT. If they can help me 
understand why, that could very well be valuable information.

> beginning and start again.

I know the latter is true from personal experience. I've also come 
close enough to the former to believe this is a real problem, but I 
have nothing hard there.

But if we're going to attach dollar values to one end of the argument, 
we need to do it everywhere. That's the only way to be able to 
determine how we can make standards that cost people the least amount 
of money. But nobody can predict the future, so I don't think this will 
work in practice.

---

From: John Kristoff <[email-masked]>
Date: Wed, 30 Apr 2003 08:22:08 -0500

On Tue, 29 Apr 2003 18:45:35 -0500
"Stephen Sprunk" <[email-masked]> wrote:

> > This seems OK to me and appears to put the burden in the right
> > place. Shouldn't it be the responsibility of those who are allocated
> > address space to properly manage it?  Others can still filter on
> > long and valid prefixes that they expect to hear.
> 
> Or, if these non-routed allocations were from a specific
> IANA-designated block, providers could simply filter them all with one
> directive.

Just to clear up a misconception on my part.  I misread the comment I
was responding to.  Quoting:

"If we allow people to register non-routable globally unique addresses 
for private use"

My brain for some reason initially interpretted that as "registering
globally unique addresses, but not having them be routable, due to local
policy", which is a bit different.  For one, it wouldn't accommodate
simple, well known non-routeable filters.

John

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Apr 2003 13:16:11 -0700 (PDT)

> > customers, similar to IPv4 common practice.

   Network puritanism: the haunting fear that someone,
   somewhere may be happy with their own subnet.

	     Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 11:30:37 -0400

> Today, dial-up concentrators usually have an address 
> between 10k and 1M you run into trouble. 

this is an interesting point, but I think it has more to do with whether
the prefixes are statically bound to customers than the length of those
prefixes.  why would  giving customers static /64s result in fewer routes in
your IGP than giving them static /48s?   in neither case is there a direct
correspondence between the customer's address and the concentrator.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 30 Apr 2003 11:20:14 -0500

> > interior routing protocol. If everyone has their own /48, that means
> > a route in the IGP for each customer that's online. There are no
> > hard and fast rules about how many routes you can have in an
> > IGP, but somewhere between 10k and 1M you run into trouble.
>
> prefixes.  why would  giving customers static /64s result in fewer
> routes in your IGP than giving them static /48s?   in neither case is
> there a direct correspondence between the customer's address and
> the concentrator.

IMHO, dialup is a bad example because static IPs per customer are rare;
let's switch to the cable/dsl market.

Standard practice is to connect all customers in a given area (or signed up
in a given period) to a single concentrator via some sort of virtual circuit
(PPPoE, ATM, FR, etc).  This concentrator then internally bridges all of
these virtual circuits into a single subnet with a single prefix, giving you
one route for N customers.  OTOH, if you assign a prefix to each customer,
you then have between N+1 and 2N routes for N customers.  The latter might
be justified if we're truly committed to eliminating NATs, but it costs a
lot more in routes, in administration, and in address waste (assigning a /48
to what is, in nearly all cases, 1-4 hosts).

S

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Apr 2003 09:45:06 -0700 (PDT)

> to what is, in nearly all cases, 1-4 hosts).

Huh? Why wouldn't these prefixes summarized at the
first hop router? And even the first hop router
needs to have routes to get to the last mile, so
whether you do it with an arp cache, SID binding,
or routing table seems like a rather minor
difference in kind.

	   Mike

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Apr 2003 18:52:45 +0200

On woensdag, apr 30, 2003, at 18:20 Europe/Amsterdam, Stephen Sprunk 
wrote:

>> prefixes.

Of course.

>> why would  giving customers static /64s result in fewer
>> routes in your IGP than giving them static /48s?

I was suggesting nothing of the sort; just assumed that _if_ you're 
going to give a customer something fixed it would be a /48 while a 
dynamic /48 doesn't make much sense the way things are now.

> one route for N customers.

Ok, I'm not all that familiar with cable/ADSL, but isn't this more 
often done by giving each customer a virtual point to point link? In 
the case of PPP over ethernet I don't see how it could work otherwise. 
Now of course you can then proxy ARP...

> OTOH, if you assign a prefix to each customer,
> you then have between N+1 and 2N routes for N customers.

Unless you aggregate, of course. For cable/ADSL that shouldn't be a 
problem as the customers conveniently stay in the same place.  :-)  Not 
so with dial.

> The latter might

So we should give them a /126???

I guess a /64 would be enough for most people. You are underestimating 
the number of hosts, though: don't forget about IP phones, IP radios 
and stuff like that. And I'm not even counting more obscure examples 
such as IP refrigirators.

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 12:53:22 -0400

> > this is an interesting point, but I think it has more to do with
> > whether the prefixes are statically bound to customers than the
> > length of those prefixes.  why would  giving customers static /64s
> > result in fewer routes in your IGP than giving them static /48s?  
> > in neither case is there a direct correspondence between the
> > customer's address and the concentrator.
> 
> IMHO, dialup is a bad example because static IPs per customer are
> rare; let's switch to the cable/dsl market.

well, they might not be so rare in the IPv6 market, but whatever...

> Standard practice is to connect all customers in a given area (or
> signed up in a given period) to a single concentrator via some sort of
> virtual circuit(PPPoE, ATM, FR, etc).  This concentrator then
> internally bridges all of these virtual circuits into a single subnet
> with a single prefix, giving you one route for N customers.  OTOH, if
> you assign a prefix to each customer, you then have between N+1 and 2N
> routes for N customers.  

well, for cable at least, seems like you'd want to assign a prefix to
each concentrator and give each customer a /48 subnet out of the
concentrator that serves that location.  as I understand dsl it affords
more flexibility than that, since each customer can get a VC to a
concentrator which can essentially be anywhere, but you'd still want
to assign an appropriate-sized prefix to the concentrator and dole /48
subnets out of that.  either way you get to do route aggregation at the
concentrator.

I suspect a lot of "standard practice" for IPv4 is designed to conserve
address space; it's not clear that such practices are either desirable
or optimal for IPv6.  more generally, IPv6 is going to be driven by 
different markets, different applications, and a different set of
customer demands than IPv4.  so anytime you find yourself thinking that 
"standard practice" (meaning v4 practice) axiomatically applies to IPv6,
it might be worth re-examining the assumptions behind that practice.

Keith

---

From: Daniel Senie <[email-masked]>
Date: Wed, 30 Apr 2003 13:07:01 -0400

>to what is, in nearly all cases, 1-4 hosts).

If standard practice is to give everyone a /48, then the routing decision 
at the access concentrator could be programmed to deal with this, ignore 
the low order bits, and send the packets on to the proper customer. Given 
the decision to "waste" the low order bits on MAC address or other locally 
defined values, there's no value in an access concentrator worrying about 
that part of the address. The residential gateway would worry about it. 
Sounds more than a bit like ISDN sub addresses, where the sub address is 
only of interest to the CPE. Seems like a small matter of programming, not 
a reason to load up routing tables.

---

From: [email-masked]
Date: Wed, 30 Apr 2003 17:37:33 -0400

> understand why they're being deployed?? ;-)

I can watch CNN broadcasting pictures of self-flaggelating religious types
and say "Wow, that's gotta hurt!" without understanding why they do it....

---

From: Peter Deutsch <[email-masked]>
Date: Wed, 30 Apr 2003 15:42:54 -0700

g'day,

> and say "Wow, that's gotta hurt!" without understanding why they do it....

Yeah, but if we want to continue with this religious analogy for a bit
longer, there's plenty of evidence throughout history that failure to
understand why other cultures do what they do can actually actually hurt
*you* in the long run....

			- peterd

-- 

                                        -- Dave Barry