Subject: Fw: Welcome to the InterNAT...

From: "Jim Fleming" <[email-masked]>
Date: Tue, 25 Mar 2003 14:53:08 -0600

----- Original Message ----- 
From: "J. Noel Chiappa" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 25, 2003 2:40 PM
Subject: Re: Welcome to the InterNAT...

> If you send one message a day, I might read it. Send 10, and we start asking
> for your posting privileges to be suspended. Very simple. Get it?
> 
> Noel
>

---

From: "Peter O'Neil" <[email-masked]>
Date: Tue, 25 Mar 2003 14:08:31 -0700

--On Tuesday, March 25, 2003 2:53 PM -0600 Jim Fleming 
<[email-masked]> wrote:

>> If you send one message a day, I might read it. Send 10, and we
>> start asking for your posting privileges to be suspended. Very
>> simple. Get it?

I'm with Noel on this.  Fleming refuses to learn.
Time to pull his posting privileges again.

Peter

---

From: "Jim Fleming" <[email-masked]>
Date: Tue, 25 Mar 2003 15:20:40 -0600

Since the list is censored, there is no point in commenting...

http://www1.ietf.org/mail-archive/ietf/Current/msg14158.html

Jim Fleming
http://IPv8.no-ip.com

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 25 Mar 2003 22:10:01 +0000 (GMT)

Fleming wrote:

> Welcome to the InterNAT...where the world is routing around the I*
> society...

[bunch of irrelevant urls]

and then everyone started whinging about it, at which point I started
seeing their whinges.

Speaking at the guy credited with inventing the term InterNAT [*]
I'd like to point out that ietf-censored is doing a fairly good job of
routing around Fleming already. (Oh, and that Fleming doesn't know
what 'InterNAT' means, either.)

Read this list through ietf-censored, and stop whinging.
Or put Fleming in your killfile, and stop whinging.

The key thing is for you to stop whinging.

L.

spaking of which, Noel, where's the obIPv6 whinge on how, now that
they've deprecated site-local addresses, IPv6 has no redeeming
features left?

[*] The InterNAT: Policy Implications of the Internet Architecture
Debate, by Hans Kruse, William Yurcik and Lawrence Lessig, Proceedings
of the Telecommunications Policy Research Conference (TPRC '00),
Virginia, September 2000. http://www.tprc.org/Agenda00.HTM

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

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 25 Mar 2003 17:16:38 -0800

Lloyd Wood wrote:
> spaking of which, Noel, where's the obIPv6 whinge on how, now 
> that they've deprecated site-local addresses, IPv6 has no 
> redeeming features left?

I don't know who 'they' is, but the WG has not deprecated site-local
addresses. As I understand it a completely confused discussion occurred
in SF which equated SL with NAT, but that does not equate to a WG
consensus to depricate something people are already using.

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Mar 2003 23:19:49 -0500

> consensus to depricate something people are already using.

your understanding is incorrect.  the question posed at the meeting was 
quite clear.  and yes, the plurality of opinions in the room was so 
overwhelmingly in favor of deprecating site local (even if it's 
something people are already using) that it is inconceivable that this 
is not indicative of WG consensus.

site local is broken.  it creates far more problems than it solves, and 
it cannot be fixed.  it's just taken people awhile to realize it.

of course, the SL prefix will not be re-allocated to other purposes, 
and nothing stops those who are already using SL from continuing to do 
so.  but the idea that hosts, apps, routers, DNS, etc. should 
special-case site-local addresses is dead.  and good riddance.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Mar 2003 12:23:21 -0800

> is not indicative of WG consensus.

This has not been discussed on the WG mail list, so despite your
apparent limited ability to conceive of valid objections, they do exist.

> it cannot be fixed.  it's just taken people awhile to realize it.

Trying to use SL for routing between sites is what is broken. The space
identified in RFC 1918 was set aside because people were taking whatever
addresses they could find in documentation. SL was set aside because
there are people that either want unrouted space, or don't want to
continuously pay a registry to use a disconnected network. It is far
cheaper to train an app developer (though there may be an exception or
two) to deal with it than it is to fix all the ad-hoc solutions that
people will come up with to replace SL.

> special-case site-local addresses is dead.  and good riddance.

Again, this is not a trival issue and there has been no discussion of it
on the WG mail list. The decision has NOT been made.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Mar 2003 12:58:45 -0800

Tony Hain wrote:
> Trying to use SL for routing between sites is what is broken.

But that's not all...

> The space
> addresses they could find in documentation.

Not as I recall.  Jon Postel received several requests for 
extraordinarily large chunks of address space, particularly from Europe. 
  I believe Daniel Karrenberg might have more information.  This forced 
his hand.  In addition, people such as Paul Vixie were trying to do the 
best they could to make random address space sork, which is admittedly a 
trick in a small name space.  Recall at the time that CIDR was a new 
thing.  You couldn't simply use a portion of network 10, for instance. 
The same cannot be said for IPv6.

> SL was set aside because
> continuously pay a registry to use a disconnected network.

Any address space can be unrouted address space.  Fix the underlying 
problem, Tony.  Making renumbering easy.  If we don't do that, IPv6 is 
no better than Ipv4 (with the possible exception of MIPv6).

> It is far

Fix the renumbering problem and this isn't an issue.

Eliot

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 26 Mar 2003 22:10:34 +0100

> apparent limited ability to conceive of valid objections, 

As you probably know, check http://playground.sun.com/ipng/
There are a couple of objections against deprecation/removal.
But most of these IMHO simply boil down to having a place where
it is possible to register globally unique address space which
is not to be connected to the internet. Because it is globally
unique it can be used to interconnect multiple sites though.
Note also that if this space is available and those networks
suddendly do want to connect to the internet one will see NAT
for IPv6 and thus RFC1918 is born for IPv6 but with registration.
If that happens I see little sense in actually giving those people
IPv6 as they are not out for e2e connectivity at all.
Most applications that work with IPv6 also work in IPv4...

> people will come up with to replace SL.

And thus *every* application should suddenly be aware of the fact
that some address space is not to be used in some certain currently
non specified cases?

Could this even be more fague?

Either there is an address on the link or there isn't.
Either it routes or it doesn't.
There are numberous reasons why an address can't connect to
another host. If an address on a link exists an application
should be able to use it as an outgoing address. Currently
we already have an exception here for fe80::/10 but that
case has already been handled for quite some time and is quite
logical as a link is a link and it's quite easy for the stack
to detect that a host is not on the same link.

Greets,
 Jeroen

---

From: Ted Hardie <[email-masked]>
Date: Wed, 26 Mar 2003 13:22:07 -0800

Tony writes:
The space
> addresses they could find in documentation.

There is a long and "interesting" history here, but it isn't directly  
relevant
to this discussion.  I think it would be valuable to focus the  
discussion on Site Local,
rather than on RFC 1918 space.

> people will come up with to replace SL.

I think you may underestimate how much trouble this might cause in  
applications.
As Dave Crocker noted in response to Margaret Wasserman's presentation
to the APPs Open Area meeting, applications have been designed so that  
they
do not know and don't need to know anything about network topology.     
If you
require applications to understand the consequences of different  
unicast address
scopes, you are changing a pretty fundamental assumption.  While it is  
theoretically
possible to change that assumption, it is a major piece of work, and I  
believe that
the "sense of the room" was that the advantages of Site Local were not  
worth that
amount of work.   As you note, this is subject to discussion and  
confirmation on
the mailing list and, ultimately, to the consensus of the IETF as a  
whole.

Margaret's presentation, for those not at the APPs open area, was  
derived from her
  draft, found at  
http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact- 
02.txt.
See especially section 3.7.

						regards,
								Ted Hardie

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 26 Mar 2003 22:14:56 +0100

> Tony Hain wrote:

<SNIP>

> problem, Tony.  Making renumbering easy.  If we don't do 
> that, IPv6 is no better than Ipv4 (with the possible exception of
MIPv6).

How does TCP/IP renumber your DNS, administration databases,
numberous applications, remote sites etc?

Seeing that route filtering only gets done automaticaly for
the last couple of years and the fact that that is only a
route + ASN mapping I don't see why all of a sudden there
will be some magical solution for renumbering complete networks.
Though current IPv6 with RA's does make it simpler it unfortunatly
isn't a complete solution :(

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Mar 2003 13:38:08 -0800

> rather than on RFC 1918 space.

The reason for bring 1918 into the discussion is that prior to NAT,
there was a market demand for private address space. That demand hasn't
gone away, and the non-NAT users of that space are completely
disenfranchised in this discussion because they have seen no need to
worry about it given there is a comparable space defined for IPv6. 

> As Dave Crocker noted in response to Margaret Wasserman's 
> presentation to the APPs Open Area meeting, applications have 
> been designed so that  
> they
> amount of work.   

I am not arguing that every app need to know about topology. If this is
such a big deal, we should simply fix the API so that by default it only
returns global scope addresses, then add a new function for those apps
that are interested in the limited scope. This doesn't sound like rocket
science, and the arguments against it are coming across like 'we don't
want to change because it is too much work'. Rather than argue that
nobody can ever use a new feature, the basic approach should be that you
don't have to unless you want to. 

> As you note, this is subject to discussion and  
> confirmation on

And it has yet to be formally raised by the chairs on the WG list, so if
it gets to IETF last call, it will be ripe for an appeal.

Tony

---

From: Michael Mealling <[email-masked]>
Date: 26 Mar 2003 17:12:42 -0500

> don't have to unless you want to. 

Its not that 'we don't want to change because its to much work'. Its
that the Internet architecture assured us that the hour glass model
applied, that the network topology would remain abstracted within what
to us is an opaque address space. One of the number one reasons its so
easy for new application layer technologies to be deployed is that a
developer doesn't need to know or care about any layer below TCP (or, in
rare cases, UDP). If the lower layers want to change that hour glass
model then we're talking about a serious breach of contract with the
layers above it and a dangerous blow to the hour glass model.

-MM

---

From: Fred Baker <[email-masked]>
Date: Wed, 26 Mar 2003 14:20:40 -0800

>will be some magical solution for renumbering complete networks.

Really? I started to design such a procedure, and it's not terrifically 
hard if you set your sights correctly. The key concepts are:

  - IPv6 makes it easy to have multiple prefixes and addresses per interface
  - anything you have advertised in DNS etc has a lifetime, which you need to
    honor
  - the existing so-called renumber scheme mostly says how to make a new 
address
    come into existence

So if you want to renumber from prefix A to prefix B, you have to:
  -1- start with all routers and hosts using prefix A
  -2- reconfigure all router interfaces to support both prefixes A and B,
      and preferring prefix A
  -3- as a side effect, you will also be starting to route for prefixes A 
and B.
  -4- as a side effect, hosts will develop addresses in both prefixes
  -5- Update DNS etc databases with prefix B addresses (presumably a
      side-effect of step 4)
  -6- at this point, there will be no new sessions opening using prefix A
      as destination addresses. Prefix A will be in use in source addresses.
  -7- reconfigure all router interfaces to support both prefixes A and B,
      and preferring prefix B
  -8- wait for all advertisements of prefix A addresses (DNS etc) to expire
  -9- at this point, there will be no new sessions opening using prefix A
      as destination addresses. Prefix A will be in use in source addresses
      in sessions that started before step 6. Continue waiting until they
      are no more (may be already complete, may take a month, YMMV)
  10- when said sessions have all expired, prefix A is routed and usable but
      is no longer in active use.
  10- reconfigure all routers to support only prefix B
  11- as a side effect, routing and host use of prefix A will cease

The hard parts are "reconfigure all routers..." and determining the 
duration of the delay in step 9. The rest actually works reasonably well 
today, I should think.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 26 Mar 2003 14:44:04 -0800

At 1:38 PM -0800 3/26/03, Tony Hain wrote:
>that are interested in the limited scope.

Those two sentences don't line up. Either things that use addresses 
need to know about network topology, or they don't.

And it's not just applications. Security services like IPsec are also 
equally affected by having to know that "ah, I'm actually doing 
something site local, so I need to prompt the operator for a prefix 
and then use that prefix in many places in my security logic".

It's not just an API question.

--Paul Hoffman, Director
--VPN Consortium

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Mar 2003 18:04:50 -0500

The WG chairs of the IPv6 WG did determine that there was consensus
of those in the room to deprecate site-local addressing in IPv6.
Like all consensus achieved at IETF meetings, this consensus will
be checked on the list.

BTW, I was at the meeting (Tony was not) and do not agree with his
characterization of the discussion.  The conversation did not focus
on NAT and, IMO, was no more confused than typical WG discussions :-).

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Mar 2003 15:13:16 -0800

Michael Mealling wrote:
> Its not that 'we don't want to change because its to much 
> work'. Its that the Internet architecture assured us that the 
> hour glass model applied, that the network topology would 
> remain abstracted within what to us is an opaque address 
> space. One of the number one reasons its so easy for new 
> application layer technologies to be deployed is that a 
> developer doesn't need to know or care about any layer below 
> TCP (or, in rare cases, UDP). If the lower layers want to 
> change that hour glass model then we're talking about a 
> serious breach of contract with the layers above it and a 
> dangerous blow to the hour glass model.

You really don't want to go there, since it is in fact the violation of
the layering by the apps that has created some of the mobility and
renumbering challenges. Apps know all too much about what is going on
below them, which is why the app developer sees any change as a lot of
work.

Tony

---

From: Ted Hardie <[email-masked]>
Date: Wed, 26 Mar 2003 15:35:03 -0800

> worry about it given there is a comparable space defined for IPv6.

I'm not sure I agree that there was ever a non-scarcity induced market
demand for private address space in the pre-RFC 1918 days, but I'll
concede it for the sake of argument.   I think we then to consider 
whether
  the current need is for:

"non-routed globally unique space"

or for something else.  If the answer is "non-routed globally unique 
space",
then the follow-on question is "Why not get globally unique space and 
simply
decide not to route it?".   If the market demand is for something else, 
then I'd
appreciate a concise statement of what it is.

> don't have to unless you want to.

I'm sorry that the arguments against it are coming across like "we don't
want to change because it is too much work".  That is certainly a part 
of
the reaction, but the underlying reason is actually that the model 
doesn't
fit the Internet architecture as the apps understand it.

As I tried to note in my first response, I agree that it is possible to 
*change* the
assumptions about the app's layer knowledge of topology, but the reasons
given for the need seem remarkably weak in the light of such a basic 
change.

To put it bluntly, this is not a new feature that requires a tweak to 
some
ur-API.   This change requires apps to understand address scope,
and to understand it in a totally new way.

Again, I urge folks following the discussion to read Margaret's draft.
				regards,
					Ted Hardie

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Mar 2003 15:43:19 -0800

Margaret Wasserman wrote:
> The WG chairs of the IPv6 WG did determine that there was 
> consensus of those in the room to deprecate site-local 
> addressing in IPv6. Like all consensus achieved at IETF 
> meetings, this consensus will be checked on the list.
> 
> BTW, I was at the meeting (Tony was not) and do not agree 
> with his characterization of the discussion.  The 
> conversation did not focus on NAT and, IMO, was no more 
> confused than typical WG discussions :-).

Unfortunately I could not be there, so I can only go on the reports I
have gotten, which show that at least some of the people in the room
felt this was an anti-NAT discussion. Some have even suggested that
there was no clear indication on what 'deprecating site-local' means. Is
it the address range, or the concept of scopes? 

All the arguments seem to be targeting getting rid of the address range
because a few app developers can't figure out how to deal with scopes.
The range doesn't create the scope, the application of filtering does
that. Since there will be filtering going on anyway, are we supposed to
get rid of all addresses? Let's get real here. All SL amounts to is a
well-known route filter.

History shows people will use private address space for a variety of
reasons. Getting rid of a published range for that purpose will only
mean they use whatever random numbers they can find. This has also been
shown to create operational problems, so we need to give them the tool
they want to use in a way we can contain the fallout. Site local is
defined to do that job, and we do not have WG concensus on depricating
it.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Mar 2003 15:57:28 -0800

> defined to do that job, and we do not have WG concensus on depricating

As I wrote previously, one must understand the history in order to 
understand its applicability to the future.  The reason there was a 
problem at all was that there was a not just a non-zero chance of an 
address clash but that this percentage rose based based on the class of 
address chosen.  If you took 80.1.4.6 you clashed with all of 80 because 
classless addressing had not made it into the base yet.  The chance of 
this sort of clash in IPv6 is miniscule.  Not that it's a good idea.

Even so, if you used upper range class B or C address space the chance 
of a clash at the time was low (still is).  And indeed in the case of a 
merger you were better off than using net 10 because the likelihood of 
clash with net 10 is high.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Mar 2003 19:07:12 -0500

--On Wednesday, 26 March, 2003 15:13 -0800 Tony Hain 
<[email-masked]> wrote:

> You really don't want to go there, since it is in fact the
> violation of the layering by the apps that has created some of
> the mobility and renumbering challenges. Apps know all too
> much about what is going on below them, which is why the app
> developer sees any change as a lot of work.

Tony,

I am probably missing something, but I don't see this. 
Partially to aid transition to v6, we've been telling apps 
developers for several years that they should rely on DNS names, 
paying at little attention as possible to the format or content 
of addresses, their topology implications, etc.  As an 
application-writer, I'm not supposed to know anything about 
prefixes, address-masks, or anything else about how addresses 
are put together.  Yes, if I start doing tricky things about 
firewall or NAT-traversal, I can get myself into a lot of 
trouble, but that is part of why we have always considered those 
sorts of things to be layer-violating if not worse.

Ignoring the format of addresses has worked well for 1918 
addresses (loathsome as they might be) because the assumption is 
that filtering (so that they don't leak onto the public network) 
is the responsibility of anything that connects a 1918 network 
to the public Internet.  And CIDR was deployable precisely 
because the applications themselves didn't know about classes.

Now, if I correctly understood Margaret's presentation last week 
(and some other things), if there is a possibility that a 
particular address might be site-local but that the target might 
also be associated with publicly-routable prefixes, the 
application has to figure that out, figure out whether the 
target is local, and then do the right thing.  That isn't a 
matter of filtering or masking external to the application: the 
application has to do the work, or the architecture that 
surrounds the applications has to change.  That is a fairly big 
deal and, I think, involves more layering problems than what we 
are doing today.

But, obviously, I'm not understanding something.  Could you 
explain?

    john

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Mar 2003 16:10:47 -0800

> this sort of clash in IPv6 is miniscule.  Not that it's a good idea.

Yes but most of the clashes were based on using Sun's or HP's addresses
because those were published in documents. The lack of robust route
filtering tools at the time made the likelyhood of real problems high.
If we remove the definition of FEC0::, people will gravitate toward
whatever shows up in documents, so the risk of collision at merger time
is still high.

> clash with net 10 is high.

So you are suggesting that people just randomly pick space from 3a00::
since they should be long retired by the time we find the conflict? ;)

Tony

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Mar 2003 16:36:10 -0800

Ultimately, as I wrote with others some nine years ago, some practices 
should not be codified.  With IPv4 at least there was a plausible 
argument for network 10.  I didn't like it, nor did I agree with it, but 
it was plausible.  The same cannot be said for v6.

Incidentally, Sun & HP's use of default network numbers didn't really 
cause any great consternation or motivation for RFC 1597, so far as I 
could tell.  Were that the case we wouldn't have needed either a /16 or 
a /8.

Eliot

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Mar 2003 17:08:42 -0800

John C Klensin wrote:
> ...

For most of the cut section, consider that while 'good practice' says to
use names, reality is that too many apps still grab the address for
random reasons.

> But, obviously, I'm not understanding something.  Could you 

There is a lot of noise about treating SL special, but as you note an
application can ignore that a 1918 address is somehow different from any
other address. If an application were to do the same and just use a SL
as any other address, it will work just fine until one of the
participants is on the outside of the filtering router (also true for
IPv4 w/1918). 

If one believes that a split-DNS is reasonable to build and deploy
(since many exist it seems self evident), then an application should
only see a SL in a DNS response if the query originates in the same
private address region. This again will work fine and the existing
sending rules might cause the stack to order that one first so that any
long-lived internal connections would survive an external renumbering
event. 

The place SL starts to have trouble is when a multi-party app does
referrals based on obtained addresses rather than names. Since the app
can't know which parties are on which side of the routing filter, it
can't pass the correct addresses around. (One could argue that if it
passed a name then the split-DNS would return the correct address to the
querier based on his location, but that frequently gets shouted down
based on unreliability of DNS) It is also possible that one of the
participants is only accessible via the private address space, so there
is a failure mode where some participants can see each other while
others can't. This will always be true, and has nothing to do with the
well-known prefix FEC0::.

The other place SL is criticized is for it's intentional ambiguity.
While this doesn't prevent random announcements into the global table,
it does provide a clear bogon for the route filters. Again this is not a
problem until two parties try to route between each other without
coordinating. Since there are 58 bits allocated for local
administration, one would hope that multiple organizations could find a
way to interconnect private networks without conflict. The argument
against this is that people won't do it so we have to force them to
register for some yet to be defined public space that is not routable.
Since we know that ISP's will do whatever the customer pays for, it is
only a matter of time until 'unroutable' prefixes start showing up in
the global table. The intentional ambiguity prevents that.

One reason that some people like private space is that they don't have
to expose to their competitors what internal networks they are deploying
and which office is coordinating that. If they are suddenly required to
register for public space for every internal use network, they are more
likely to pick random numbers than tip of the competition. What they
want is space that for all intents and purposes to apps looks like
global space, but they don't have to expose it, know it will be filtered
at the border, and backed up by a filter at the ISP. So for these
purposes there is no need to treat SL as a special case. 

Others are looking for a well-known filter than can be embedded in
appliances so they are easy to sell to Joe-sixpack and only accessable
from the home network. There may be apps that want to leverage the
well-known filter to simplfy the life of Joe-sixpack. Consider the case
of file sharing between nodes on an intermittently connected network. If
the mount dropped evertime there was a connect event, Joe-sixpack would
find another product. In this case there may be a reason for the app to
treat SL as a special case, but this is something the app developer
wants to do and is willing to do the extra work to make it happen. There
are complex proposals for RA options, but so far none of them work for
the node that needs to be seen both internally and externally. 

We need to get past the arguments that private space == nat, because use
of private space predates nat, and its only relationship is that it
facilitated nat as an address preservation tool. No matter what the WG
does, there will continue to be private space used in various parts of
the network. There will also be filtering in the network, so app
developers have to deal with scope no matter how badly they want to
avoid it. By clearly defining the address range for limited scope use,
applications have the opportunity to use or avoid it at will. If the app
passes names and the split-DNS infrastructure is operating correctly,
there is no need for the app to care about the filters.

If there really is some magic in FEC0::, I am willing to refocus my
drafts from a PI mechainsm to a globally unique address space with no
need to register. Since it results in a /64 per cubic meter 1km deep,
there is no real potential for conflict.

Tony

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Mar 2003 21:28:06 -0500

From the reading of the draft, it would appear that much of the pain 
for applications with SL is caused because the apps violated the contract.
Actually, its a wonder any of these would work in v6 at all given the 
description of the problem (address leaks).

-andy

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 00:30:17 -0500

> apparent limited ability to conceive of valid objections, they do 

actually it's the other way around.  there are far more valid 
objections to the use of SL than there are to deprecating SL.

> Trying to use SL for routing between sites is what is broken.

SL is broken whether or not you try to use it for routing between sites.

> It is far cheaper to train an app developer (though there may be an 
> exception or

no, you have it exactly opposite.  you can't train an app developer to 
fix the problems caused by SL because in order to fix the problems 
caused by SL you have to deploy extra infrastructure and create a new 
network on top of the dysfunctional one that uses SL.  and it's far 
cheaper and cleaner to solve those problems in other ways.
SL is the ad hoc solution that didn't get sufficient scrutiny before 
being approved.  Fortunately that mistake has finally been rectified.

> on the WG mail list. The decision has NOT been made.

a clear consensus of the WG has spoken.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 00:33:21 -0500

> there was a market demand for private address space.

sometimes the market is misled by vendors who want to sell planned 
obsolesence.  NAT is the perfect example.

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 00:42:18 -0500

>  since it is in fact the violation of
> renumbering challenges.

uh, no.  DNS is not a layer.  it is a naming service.  it's not the 
only way that an app can get an IP address, and never has been.

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 00:46:38 -0500

> Ignoring the format of addresses has worked well for 1918 addresses 
> (loathsome as they might be) because the assumption is that filtering 
> (so that they don't leak onto the public network) is the 
> responsibility of anything that connects a 1918 network to the public 
> Internet.

but this assumption proved to be a false one.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 00:54:54 -0500

> participants is on the outside of the filtering router (also true for

for multiparty apps, the probability that this will happen is within 
epsilon of 1.

> (since many exist it seems self evident)

no.  there are lots of unreasonable things in this world.  split DNS is 
a hack that works only in limited situations, and even then it doesn't 
work well.  it makes assumptions about application behavior that are 
not valid.

> , then an application should
> private address region.

DNS is irrelevant.  you can't fix SLs by fixing DNS, even if you could 
fix DNS, which you can't.  it's not reasonable for a DNS server to 
assume that the party making the query is the party that will use the 
address.  actually DNS caching depends on DNS producing consistent 
results no matter who is making the query, and DNS caching is not don't 
exclusively by DNS servers.

> This again will work fine

bzzzt.  wrong again.

> referrals based on obtained addresses rather than names.

which is a perfectly reasonable thing to do.  it's how the Internet was 
designed to work.

> and which office is coordinating that.

there are far better ways to solve that problem than by crippling apps.

> We need to get past the arguments that private space == nat,

no that's not the problem.  the problem is that scoped addresses are 
dysfunctional.  NAT has nothing to do with it.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Mar 2003 13:24:33 -0800

Eliot,

The only relationship SL has to renumbering is the ability to have
connections persist while a network is intermittently attached to the
public network. Renumbering is already solved in terms of the simplicity
of moving hosts from one address space to another. The complex issues to
work on are the places like firewall & router configurations that have
explicit addresses in them. What is not fixable is the fact that apps
will break if you change an address out from under them. This is a fact
the app developers complaining about the complexity of scoped addresses
continually overlook. The assertion is that all a network needs to do is
change the addresses in use when connecting. Never mind that every local
use app will break on every one of those events. That is not an
acceptable approach. 

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eliot Lear
> Sent: Wednesday, March 26, 2003 12:59 PM
> To: [email-masked]
> Cc: 'The IETF'
> > identified in RFC 1918 was set aside because people were taking 
> > whatever addresses they could find in documentation.
> 
> that, IPv6 is

---

From: "Louis A. Mamakos" <[email-masked]>
Date: Wed, 26 Mar 2003 17:56:21 -0500

> layers above it and a dangerous blow to the hour glass model.

This is a good sounding story, except that it's never really been 
true.  You could choose to ignore the topology of the network,
and ignorance works much of the time.

Way back in the dark ages, it was not uncommon to have multi-homed
HOSTS: one leg on the ARPANET, the other arm on some local LAN
segment.  The application and/or network stack on that machine was
left with a decision to choose which interface address it ought to
use when binding some local association endpoint address.  It's
"easy" when the other end is on the same network; e.g., directly
attached.

The Internet architecture never gave the end system some mechanism
to help it make this binding decision when trying to communicate
with non-local peers.  There are hacks in implementations; like the
local resolver having some sorting policy for the A records returned
when doing a DNS query, with the assumption that the application was
going to try them in turn.  But that was just a hack.  There was no
protocol to ask the network "which of address should I use to
talk to this remote end system?"

So here we are today, a couple of decades later, with the promise of a
different type of end-system multi-homing (having multiple addresses
on a single) interface due to IPv6 multi-provider multihoming with
provider specific addresses, and still no means to decide which of the
alternatives are preferable when deciding to launch some traffic into
the network.  Adding one more site-local address doesn't make this
problem any harder to solve, I think.

louie

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Mar 2003 08:31:27 -0800

Pekka Savola wrote:
> Who said the addresses are *completely* revokated when the network 
> connectivity is intermittent?
> 
> More likely than not, those address advertisements have a 
> lifetime longer than the duration of the downtime (both 
> preferred and valid in RFC2461
> terms!) -- and whoops, everything works like a charm still!

You continue to ignore the fact that when the connection to the public
network reestablishes with a different prefix, all existing internal
connections will be dropped. The fact that multiparty apps can't blindly
pass around addresses is not a valid justification for removing a
technology which prevents disrupting internal use applications.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Mar 2003 18:35:21 +0200 (EET)

On Thu, 27 Mar 2003, Tony Hain wrote:
> connections will be dropped.  [...]

Not so.  (If you build your system in an optimal fashion -- which really 
does need a bit fleshing out, though.)

Such prefixes would then reach valid lifetime=x, preferred lifetime=0, be
set "deprecated" and not be used for new connections anymore.  Nothing
requires connections be killed using such deprecated addresses.

-- 
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: "Tony Hain" <[email-masked]>
Date: Thu, 27 Mar 2003 09:27:01 -0800

> does need a bit fleshing out, though.)

So the intent is to dictate to everyone how they build their networks?

> 
> Such prefixes would then reach valid lifetime=x, preferred 
> lifetime=0, be set "deprecated" and not be used for new 
> connections anymore.  Nothing requires connections be killed 
> using such deprecated addresses.

Get real! If the prefix is not imediately invalidated, it will be
impossible to connect to nodes that now have a valid right to use that
prefix. If the router does not have a current prefix allocation, it must
set valid lifetime to 0. It is not reasonable to expect an automated
process to figure out when you want it to keep a prefix around and when
you want it to go away. Even if it could do that, one set of machines on
the local network may want the opposite state from another set of
machines. 

Tony

---

From: Richard Carlson <[email-masked]>
Date: Thu, 27 Mar 2003 11:32:26 -0600

I second Tony's key point.  SL's are just 1 form of IPv6 addresses with a 
limited scope.  As soon as operations folks put up firewall or router 
filters, global addresses have the same scope limitations.  I fail to see 
how eliminating SL's makes the scoping problem any easier for applications.

Rich

> > >consensus to depricate something people are already using.

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

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: [email-masked]
Date: Thu, 27 Mar 2003 12:45:42 -0500

> So the intent is to dictate to everyone how they build their networks?

We issue RFC's and BCP's don't we?

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 27 Mar 2003 18:27:55 +0000 (GMT)

> "easy" when the other end is on the same network; e.g., directly

So unlike the dialup modem/wireless card/10+100 Ethernet/USB/Bluetooth
network connections on today's multihomed-host laptops; multihoming is
increasingly the common case, and it is not handled well.

L.

> _______________________________________________
> 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: Pekka Savola <[email-masked]>
Date: Thu, 27 Mar 2003 18:22:55 +0200 (EET)

More likely than not, those address advertisements have a lifetime longer
than the duration of the downtime (both preferred and valid in RFC2461
terms!) -- and whoops, everything works like a charm still!

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 27 Mar 2003 14:44:23 -0500

[Folks who are not interested in the details of the IPv6 WGs discussion of
site-local addressing can just hit 'd' now.]

Hi Tony,

>participants is on the outside of the filtering router (also true for

This paragraph ignores the fact that site-local addresses in IPv6
were intended to be used quite differently from RFC 1918 addresses
in IPv4.  The two biggest differences are:

(1) In IPv4, RFC 1918 addresses are used for isolated networks and/or
networks behind NAT boxes.  So, it is uncommon for a single node to
have both RFC 1918 addresses and IPv4 global addresses, and there
is typically no need for applications to choose between them (either
for connection establishment, or when deciding what addresses to transmit
to peers, etc.).  However, in IPv6, it was expected that many nodes would
have both global and site-local addresses, and that site-local addresses
would be used on globally-connected networks.

During the IPV6 meeting in SF, we did discuss several options for
limiting the use of site-local addressing, but all of those options
had some sorts of problems associated with them.

(2) RFC 1918 addresses are most commonly used behind NATs. In this case,
there is a middle box that performs translation of those addresses into
global addresses at the site boundary, both in IP headers and at the
application layer (through ALGs).  In IPv6, we hope to avoid NAT.  Site-local
addresses were expected to be used on globally connected networks without any
translation.

Packets to/from site-locals (in the IP headers) would have been dropped, but
there was no explanation of how leaking of IPv6 site-local addresses at the
application level would have been prevented at site borders.  One solution
would have been to use some ALG-equivalents in site-border routers that either
translated or dropped the traffic, but that wasn't really 
acceptable.  Instead,
the assumption seemed to be that applications just wouldn't include site-local
addresses at the application layer in any packets that might go outside of the
site.  This required some sort of address selection logic in applications.

>(since many exist it seems self evident),

There is a difference between believing that split DNS is reasonable to
deploy and believing that it is a good architecture for the Internet.
While folks may be quite capable of deploying split DNS, it results in
a more brittle and complex Internet architecture, and I don't think
that we should build an IPv6 addressing architecture that requires it.

>can't pass the correct addresses around.

Exactly.  There are many of these applications defined within the IETF,
by other standards bodies, and/or developed by private enterprises.
In fact, the applications area folks assure me that there are more of
these types of applications deployed than there are simple client-
server applications (that was news to me).  IETF applications that fall
into this category include FTP, SIP and (in some uses) HTTP.

>(One could argue that if it
>based on unreliability of DNS)

Maybe...  There has been a great deal of reticence from application
developers to rely on DNS look-ups for this type of referral, and
it is not all based on DNS reliability. There are many, many nodes that
either do not have a DNS entry or do not know their own DNS name, and
many applications need to work on those nodes.

>It is also possible that one of the

True.  Any firewall can create this situation.  I do understand that folks
will use firewalls and create private address spaces in IPv6.  Hey, I even
think that folks may deploy IPv6<=>IPv6 NAT, because there is really nothing
we can do to stop them.

However, I don't think that we should design these sorts of borders into
the IPv6 addressing architecture.

As you know, I was in favor of setting aside a prefix (FECO::, in fact)
for use as private address space (either on disconnected networks, or
behind NATs), but the consensus of the folks in the IPv6 WG meeting
was to deprecate that prefix altogether.  There were several compelling
arguments from operators and others that we don't need a special prefix
for disconnected sites...  Disconnected sites will need to renumber when
the get globally connected, anyway, and ISPs already have the proper
filtering in place to prevent mistakes from affecting the global
routing tables, etc.

>purposes there is no need to treat SL as a special case.

For this purpose, there is no need to have site-locals at all...

The organization can just get a /48 from a provider, ask the provider
to route part, all or none of it, and use any private (non-routed) parts
however they like.  I doubt that there are many organizations (other
than the NSA, perhaps) that are afraid that their competition will know
how many subnets they have at the granularity of 2^16...  (Ooh, IBM just
asked for another /48 from their provider, what can we infer from that?)

>facilitated nat as an address preservation tool.

I don't think that anyone is making the argument that private space
== NAT.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Mar 2003 13:03:44 -0800

Margaret Wasserman wrote:
> [Folks who are not interested in the details of the IPv6 WGs 
> discussion of site-local addressing can just hit 'd' now.]

Still true. For the record, I agree that debate on this SL issue should
be on the WG list.

> >application can ignore that a 1918 address is somehow different from 
> >any other address. If an application were to do the same and 
> just use a 
> >SL as any other address, it will work just fine until one of the 
> This paragraph ignores the fact that site-local addresses in 
> IPv6 were intended to be used quite differently from RFC 1918 
> addresses in IPv4.  The two biggest differences are:
> 
> (1) In IPv4, RFC 1918 addresses are used for isolated 
> networks and/or networks behind NAT boxes.  So, it is 
> uncommon for a single node to have both RFC 1918 addresses 
> and IPv4 global addresses, and there is typically no need for 
> applications to choose between them (either for connection 
> establishment, or when deciding what addresses to transmit to 
> peers, etc.).  However, in IPv6, it was expected that many 
> nodes would have both global and site-local addresses, and 
> that site-local addresses would be used on globally-connected 
> networks.

You are mixing cause and effect. In IPv4 the vast majority of nodes are
limited to a single address at a time. Network managers that want some
of their nodes in private space find it simpler to also put the nodes
with public access in the same space rather than deploy multiple subnets
to each office and route between them. With SL, we fixed that so the
private and public nodes can share the same segment and talk to each
other without requiring a router. 

> 
> During the IPV6 meeting in SF, we did discuss several options 
> for limiting the use of site-local addressing, but all of 
> those options had some sorts of problems associated with them.

So rather than address any problems, the needs of the (mostly absent)
network managers were simply dismissed as irrelevant. Site-local is
nothing more than a well-known prefix for filtering. Filtering will
happen in any case, so even if you don't call it that, there will be
addresses with a scope of applicability that is limited to the network
managers perception of his site.

> 
> (2) RFC 1918 addresses are most commonly used behind NATs. In 
> this case, there is a middle box that performs translation of 
> those addresses into global addresses at the site boundary, 
> both in IP headers and at the application layer (through 
> ALGs).  In IPv6, we hope to avoid NAT.  Site-local addresses 
> were expected to be used on globally connected networks 
> without any translation.

Why do you continue to equate SL with NAT?

> 
> Packets to/from site-locals (in the IP headers) would have 
> been dropped, but there was no explanation of how leaking of 
> IPv6 site-local addresses at the application level would have 
> been prevented at site borders.  One solution would have been 
> to use some ALG-equivalents in site-border routers that 
> either translated or dropped the traffic, but that wasn't really 
> acceptable.  Instead,
> the assumption seemed to be that applications just wouldn't 
> include site-local addresses at the application layer in any 
> packets that might go outside of the site.  This required 
> some sort of address selection logic in applications.

It doesn't require address selection rules or ALG's. The only way an
application should receive a AAAA record with a SL is if it is in the
same address zone as the target. The continual FUD about leaking at the
borders will not be resolved by changing the prefix. Filtering will
exist, prefixes will have a limited zone of applicability, and
applications that insist on passing addresses will leak those in a way
that causes application failure. 

> There is a difference between believing that split DNS is 
> reasonable to deploy and believing that it is a good 
> architecture for the Internet. While folks may be quite 
> capable of deploying split DNS, it results in a more brittle 
> and complex Internet architecture, and I don't think that we 
> should build an IPv6 addressing architecture that requires it.

What we should not do is stick our heads in the sand and believe that
simply because we don't want to have limited scope addresses they will
magically disappear. Rather than force people to create a bunch of
ad-hoc solutions to the problem, we should in fact provide an
architected approach that creates a level of consistency (actually we
have, but some want to see it deprecated).

> Since the app 
> Exactly.  There are many of these applications defined within 
> the IETF, by other standards bodies, and/or developed by 
> private enterprises. In fact, the applications area folks 
> assure me that there are more of these types of applications 
> deployed than there are simple client- server applications 
> (that was news to me).  IETF applications that fall into this 
> category include FTP, SIP and (in some uses) HTTP.

And they will continue to fail when the network administrator puts in
routing filters, only nobody will be able to figure it out because we
removed the hint of a well-known prefix.

> >passed a name then the split-DNS would return the correct address to 
> >the querier based on his location, but that frequently gets shouted 
> >down based on unreliability of DNS)
> 
> Maybe...  There has been a great deal of reticence from 
> application developers to rely on DNS look-ups for this type 
> of referral, and it is not all based on DNS reliability. 
> There are many, many nodes that either do not have a DNS 
> entry or do not know their own DNS name, and many 
> applications need to work on those nodes.

Rather than fix the problem, shoot the feature that exposes it ...

> True.  Any firewall can create this situation.  I do 
> understand that folks will use firewalls and create private 
> address spaces in IPv6.  Hey, I even think that folks may 
> deploy IPv6<=>IPv6 NAT, because there is really nothing we 
> can do to stop them.
> 
> However, I don't think that we should design these sorts of 
> borders into the IPv6 addressing architecture.

The borders exist. Either we create a tool that allows people to easily
manage which nodes are on which side, or we invite chaos. Chaos existed
before private space in IPv4, and if we remove SL, it will return to
IPv6.

> 
> As you know, I was in favor of setting aside a prefix 
> (FECO::, in fact) for use as private address space (either on 
> disconnected networks, or behind NATs), but the consensus of 
> the folks in the IPv6 WG meeting was to deprecate that prefix 
> altogether.  There were several compelling arguments from 
> operators and others that we don't need a special prefix for 
> disconnected sites...  Disconnected sites will need to 
> renumber when the get globally connected, anyway, and ISPs 
> already have the proper filtering in place to prevent 
> mistakes from affecting the global routing tables, etc.

Sites would not need to renumber internal use nodes when connecting, so
that is a bogus argument. Also, if ISP's have such spectacular filtering
in place, why do we continue to periodically see 1918 space in the
global announcements? The fact that it is an identifiable space that
everyone knows to filter limits the damage, so how does one detect the
failure of filters for prefixes that aren't well-known?

> >to expose to their competitors what internal networks they are 
> >deploying and which office is coordinating that. If they are 
> suddenly 
> >required to register for public space for every internal use 
> network, 
> >they are more likely to pick random numbers than tip of the 
> >competition. What they want is space that for all intents 
> and purposes 
> >to apps looks like global space, but they don't have to 
> expose it, know 
> >it will be filtered at the border, and backed up by a filter at the 
> >ISP. So for these purposes there is no need to treat SL as a special 
> >case.
> 
> The organization can just get a /48 from a provider, 

In who's imaginary universe? Unless they are a customer this won't
happen.

> ask the 
> provider to route part, all or none of it, and use any 
> private (non-routed) parts however they like. 

Refer to previous question about detecting failures in route filters.

> I doubt that 
> there are many organizations (other than the NSA, perhaps) 
> that are afraid that their competition will know how many 
> subnets they have at the granularity of 2^16...  (Ooh, IBM 
> just asked for another /48 from their provider, what can we 
> infer from that?)

If that happens to be from a small sales office, one could infer that
they will be moving a major development effort there. If it happens to
be in a country they currently don't have developers in, one could infer
they are shifting people around. Just because it doesn't make sense to
you, doesn't mean it is an invalid concern by the managers of real
networks out there.

> 
> >We need to get past the arguments that private space == nat, because 
> >use of private space predates nat, and its only relationship 
> is that it 
> I don't think that anyone is making the argument that private 
> space == NAT.

You did in (2) above. Private space is about filtering, and filtering
will exist no matter what the IETF does. We can either put the private
space in an identifiable place, or pay the price of the resulting chaos.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 18:20:13 -0500

> the network. 

right you are.  multi-homing was avoided in IPv4 because it didn't work
well, and the problems have never been solved, not even in IPv6.

the best known way to solve this problem is by expecting all addresses
to have global scope and to be equally reachable from anywhere, modulo
link failures.  SLs prevent this from working.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 18:26:56 -0500

> I second Tony's key point.  SL's are just 1 form of IPv6 addresses
> with a limited scope.  As soon as operations folks put up firewall or
> router filters, global addresses have the same scope limitations. 

they don't have the same set of problems that SLs do.

SL addresses are ambiguous.  if you can't reach a host using its SL
address, you don't know whether the problem is that you're in a
different site or whether the host is down or whether there is a link
failure or this is prohibited by policy.  so a multiparty app ends up
needing to implement various hacks to deal with ambiguous addresses
(proxies, tunneling, etc), in order to function across site boundaries
(and apps *will* be expected to function across site boundaries).

with globals, if an app can't reach the host using a global address,
it's either a host failure, a network failure, or a policy decision.  to
a large degree this can be disambiguated using ICMP.  but in many cases
the app can treat these as 'out of its control' since there's no way to
work around them.

SLs thus break a clean separation of function between the apps and the
network.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 18:46:10 -0500

> You are mixing cause and effect. In IPv4 the vast majority of nodes
> are limited to a single address at a time. 

Well, I don't know about windows boxes, but real operating systems have
supported virtual hosting in IPv4 for many years.  Having multiple
addresses on a node, even a node with a single network interface, is
nothing new.

> Network managers that want some of their nodes in private space find
> it simpler to also put the nodes with public access in the same space
> rather than deploy multiple subnets to each office and route between
> them. 

There are easier ways to solve the problem than having multiple subnets,
that doesn't require use of SL.  Any bit in the address can be used for
filtering, it doesn't have to be in the subnet mask.

> network managers were simply dismissed as irrelevant.

Nope.  The problems couldn't be solved.  The group responsibly decided
to fix the architecture by deprecating site locals and to solve the
network managers' problems in other ways, because the solutions to the
network managers' problems without SLs are simpler than the solutions
to everyone's problems with SLs.  (especially because the latter do not
exist)

> Site-local is nothing more than a well-known prefix for filtering.

No, it's more than that.  SLs impose burdens on hosts and apps.
SLs break the separation of function between apps and the network that
is inherent in the end-to-end principle.

> Why do you continue to equate SL with NAT?

Why do you continue to accuse people of equating SL with NAT even when
they carefully explain just how they are similar and how they are
different?

> same address zone as the target.

Standardizing split DNS is both insufficient and unacceptable.  

> magically disappear. 

What we should not do is stick our heads in the sand and believe that
simply because some sites will have limited scope addresses that it's
okay to burden hosts, DNS, routing, and large numbers of applications
with having to deal with them. 

> Rather than force people to create a bunch of

Actually we are working toward an architecture that provides a level of
consistency.  But this requires that we deprecate SL.

> removed the hint of a well-known prefix.

No, it will be easy to figure out, because it will be clear that the
network administrator is to blame,  unlike the current situation with
where the app vendor is blamed for the problems caused by the NAT.
This moves the problem to a place where it's more easily fixed.
This is a huge improvement.

> Rather than fix the problem, shoot the feature that exposes it ...

Rather than fix the problem, force another broken layer on every app. 
It won't solve anything but it will provide another layer of delay,
complexity, and unreliability.  The network will be even less functional
than it is today, but at least we'll have something to blame it on.

> The borders exist. Either we create a tool that allows people to
> easily manage which nodes are on which side, or we invite chaos.

The tools will be created.  But the borders don't have to be, and
shouldn't be, wired into the address.  We need more flexible
mechanisms than that.  And there needs to be a clear limit to apps'
responsibilities to deal with those borders when they are imposed.

Keith

---

From: John Stracke <[email-masked]>
Date: Thu, 27 Mar 2003 15:31:23 -0500

Margaret Wasserman wrote:

> for disconnected sites...

Besides, we have three such prefixes, given RFC-1918 and 6to4: 
2002:A00::/24, 2002:AC10::/28, and 2002:C0A8::/32.

-- 
/============================================================\
|John Stracke      [email-masked]                     |
|Principal Engineer|http://www.centive.com                   |
|Centive           |My opinions are my own.                  |
|============================================================|
|"God does not play games with His loyal servants." "Whoo-ee,|
|where have you *been*?" --_Good Omens_                      |
\============================================================/

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 18:17:28 -0500

> What is not
> fixable is the fact that apps will break if you change an address out
> from under them. 

heck, TCP breaks if you change an address out from under it, so it's
hardly surprising that apps using TCP break under similar conditions.
the TCP/IP architecture simply was not designed to tolerate hosts
changing addresses.  and no, IPv6 doesn't fix this. actually it's very
difficult to fix at anything above layer 3.

> This is a fact the app developers complaining about
> the complexity of scoped addresses continually overlook. 

I don't know where you get that idea.  I've been arguing against both
scoped addresses and limited-duration addresses.  It's just that there
has been more attention paid to scoped addresses later.  But absent
drastic changes in the architecture, it's not sufficient that addresses
have global scope, they need to be reasonably stable also.

> The assertion is that all a network needs to do is change the
> addresses in use when connecting. Never mind that every local use app
> will break on every one of those events. That is not an acceptable
> approach. 

agreed.  But SL doesn't solve that problem, except in corner cases.
better to have a comprehensive solution, or simply to expect addresses
to be reasonably stable, than to impose SL.

---

From: John Kristoff <[email-masked]>
Date: Thu, 27 Mar 2003 18:29:22 -0600

> is inherent in the end-to-end principle.

Is it safe to assume that the arguments (on either side) would also
apply to such things as multicast addressing and SCTP path management?

> consistency.

Which is essentially what I'm rephrasing into a question above.  I
think I know the answer, but I want to make sure.

John

---

From: Richard Carlson <[email-masked]>
Date: Fri, 28 Mar 2003 09:05:18 -0600

Keith;

I disagree with your assessment.  I will continue this technical discussion 
on the WG list after the minutes are published.

Rich

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Mar 2003 11:59:35 -0500

On Thu, 27 Mar 2003 18:29:22 -0600
John Kristoff <[email-masked]> wrote:

> > SLs break the separation of function between apps and the network
> > that is inherent in the end-to-end principle.
> 

I don't think these arguments apply to multicast at all because apps
use multicast very differently than unicast, and the considerations
about address portability are different.  I suspect it does apply
to SCTP path management, but I don't know enough about SCTP to be
confident of that.

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Mar 2003 11:57:45 -0500

On Thu, 27 Mar 2003 15:31:23 -0500
John Stracke <[email-masked]> wrote:

> > As you know, I was in favor of setting aside a prefix (FECO::, in
> > fact) for use as private address space (either on disconnected
> > networks, or behind NATs), but the consensus of the folks in the
> > IPv6 WG meeting was to deprecate that prefix altogether.  There were
> > several compelling arguments from operators and others that we don't
> > need a special prefix for disconnected sites...
> 

the same problems exist for these as for SLs.  we should deprecate these
also when we revise 6to4.

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 28 Mar 2003 12:11:15 -0800 (PST)

To echo the favorable review of Steve's presentation: It's at
http://www.ietf.org/proceedings/01aug/slides/plenary-1/index.html,
and is well worth the few minutes it takes to read/re-read...

Spencer

--- Kurt Erik Lindqvist <[email-masked]> wrote:
> 
> Steve Deering made a wonderful presentation at the plenary in
> London. 
> More people should read it.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 28 Mar 2003 17:42:13 +0100

> layers above it and a dangerous blow to the hour glass model.

Looking at what is going on in the IETF, I think we are talking about 
first aid rather than trying to prevent the blow as such. That happened 
along time ago...:-(

But yes, we need to protect the architectural model or discuss a new 
one. I vote for the first, and in both cases we need to decide on that 
fist, before starting to decide on implementations. So leave 
site-locals for know.

Steve Deering made a wonderful presentation at the plenary in London. 
More people should read it.

- kurtis -

---

From: Simon Leinen <[email-masked]>
Date: Sat, 29 Mar 2003 20:40:57 +0100

> and is well worth the few minutes it takes to read/re-read...

If you have a bit more time (and bandwidth :-), try the video
recording from the multicast archive on
http://videolab.uoregon.edu/events/ietf/ietf51.html :

Plenary - Deering, IP Hourglass
  * MPEG-1 (158MB, 1000Kb/s)
  ftp://limestone.uoregon.edu/pub/videolab/video/ietf51/ch2/ietf51_plenary_8iab-deering_hourglass.mpg
  * RealAudio-G2 (41MB, 253Kb/s)
  ftp://limestone.uoregon.edu/pub/videolab/video/ietf51/ch2/ietf51_plenary_8iab-deering_hourglass.rm
-- 
Simon.

---

From: John Kristoff <[email-masked]>
Date: Thu, 27 Mar 2003 18:29:22 -0600

John

---

From: John Stracke <[email-masked]>
Date: Fri, 28 Mar 2003 12:45:09 -0500

Keith Moore wrote:

>the same problems exist for these as for SLs.
>
Right.

>we should deprecate these
Perhaps; but, given the prevalence of RFC-1918 addresses, it's unlikely 
that anybody's going to build their 6to4 implementation to block it from 
using them.

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 28 Mar 2003 15:10:48 +0000 (GMT)

> difficult to fix at anything above layer 3.

hosts could advertise static loopback addresses. Bind TCP to the
static loopback address.

L.

That identity/location overlap always gets you in the end.