Subject: Moving forward on Site-Local and Local Addressing

From: Bob Hinden <[email-masked]>
Date: Mon, 04 Aug 2003 11:06:55 -0700

[IPv6 working group chair hat on]

I think the working group has been making good progress on replacing 
site-local addresses and wanted to get feed back from the working group on 
how we should move forward.  This is not intended to directly relate to the 
ongoing appeal of the working groups decision to deprecate the usage 
site-local addresses, but to get feedback on how to proceed.  I think it is 
very important that we move forward on this issue and not rehash what has 
happened in the past.

We now have a combined local addressing requirements document 
<draft-hain-templin-ipv6-limitedrange-00.txt>, a specific alternative to 
site-local addresses draft <draft-hinden-ipv6-global-local-addr-02.txt> 
(accepted as a working group item at the Vienna IETF), and will soon have a 
draft describing why site-local addresses are being deprecated and doing 
the formal deprecation (authors identified and outline discussed at the 
Vienna IETF).  Note that all of these documents will proceed through the 
normal working group and IETF processes of last calls and review.

I think legitimate questions have been raised about how the working group 
should go about deprecating site-local addresses given their maturity in 
the current specifications and use in deployed products.  Specifically 
should they be deprecated independently from having an alternative solution 
available, at the same time an alternative is available, or sometime after 
an alternative is available.  A forth alternative is to not replace 
site-local addresses in any form, but I think the working group has made it 
clear that this is not a reasonable alternative.

I would like to hear from the working group on how we should proceed.  I 
think the choices are:

A) Deprecate Site-Local addresses independently from having an alternative 
solution available.  This would mean that the working group should treat 
the deprecation, and requirements and solution documents outlined above 
independently from each other.  If there was no consensus on an alternative 
a replacement would not happen.

B) Deprecate Site-Local addresses at the same time as a alternative 
solution is agreed to.  This would mean advancing both documents at the 
same time and making them include normative references to each other to 
insure that they were published at the same time.  This would result in the 
deprecation only happening if a consensus was reached on an alternative.

C) Deprecate Site-Local addresses after an alternative is defined, 
standardized, and in operational practice.  This would mean not advancing a 
deprecation document until there was operational evidence that the 
alternative was working and shown to be an improvement over Site-Local 
addresses.

Note:  In the above choices "Deprecate Site-Local addresses" means 
publishing an RFC that does the formal deprecation.

Please respond to the list with your preference, or if there is an 
alternative approach that is an improvement from the ones I outlined.  I 
hope that many of you will respond.

Thanks,
Bob

--------------------------------------------------------------------
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: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 4 Aug 2003 20:27:43 +0200

Hi Bob,

I think option B is a balanced alternative, unless someone can open my eyes about any cons on this one.

Regards,
Jordi

----- Original Message ----- 
From: "Bob Hinden" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 04, 2003 8:06 PM
Subject: Moving forward on Site-Local and Local Addressing

> hope that many of you will respond.

*****************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on-line at:
http://www.ipv6-es.com

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Aug 2003 11:41:30 -0700

Given the requirements from edge network managers I have talked to, I would
prefer C, but could live with B. 

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Monday, August 04, 2003 11:07 AM
> To: [email-masked]
> Cc: [email-masked]
> site-local addresses draft 
> <draft-hinden-ipv6-global-local-addr-02.txt>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 04 Aug 2003 14:53:47 -0400

My understanding of the WG discussion is that deprecation of site-local 
addresses was discussed and consensus was reached independent of the 
availability of any alternative solution.  Therefore, based on what I 
understand to be WG consensus, A is the appropriate way to proceed.

That's not to say the WG can't change its collective consensus at this 
point.  But I don't think the previous discussion of deprecation was in any 
way dependent on devising an alternative solution.

- Ralph

At 11:06 AM 8/4/2003 -0700, Bob Hinden wrote:

>independently from each other.  If there was no consensus on an 
>alternative a replacement would not happen.
>
>insure that they were published at the same time.  This would result in 
>the deprecation only happening if a consensus was reached on an alternative.
>
>standardized, and in operational practice.  This would mean not advancing 
>a deprecation document until there was operational evidence that the

---

From: Alain Durand <[email-masked]>
Date: Mon, 04 Aug 2003 14:12:21 -0700

Bob Hinden wrote:

> site-local addresses and wanted to get feed back from the working 
> group on how we should move forward.  This is not intended to directly 
> relate to the ongoing appeal of the working groups decision to 
> deprecate the usage site-local addresses, but to get feedback on how 
> to proceed.  I think it is very important that we move forward on this 
> issue and not rehash what has happened in the past.
>
> <draft-hain-templin-ipv6-limitedrange-00.txt>, a specific alternative 
> to site-local addresses draft 
> <draft-hinden-ipv6-global-local-addr-02.txt> (accepted as a working 
> group item at the Vienna IETF), and will soon have a draft describing 
> why site-local addresses are being deprecated and doing the formal 
> deprecation (authors identified and outline discussed at the Vienna 
> IETF).  Note that all of these documents will proceed through the 
> I think legitimate questions have been raised about how the working 
> group should go about deprecating site-local addresses given their 
> maturity in the current specifications and use in deployed products.  
> Specifically should they be deprecated independently from having an 
> alternative solution available, at the same time an alternative is 
> available, or sometime after an alternative is available.  A forth 
> alternative is to not replace site-local addresses in any form, but I 
> think the working group has made it clear that this is not a 
> reasonable alternative. 

I have a real problem here. As I commented in Vienna and is mentioned in 
the minutes,
the entire process this wg is going through is wrong as it is based on a 
flawed logic.

We had site local addresses. After lengthy debates, the wg realized that 
there were
a number of significant issues that outweighed the reported benefits, so 
there
is an attempt to deprecate them. Until now, fine.

Now, some people convinced the wg that SL addresses were having a role
that is not fulfilled by provider aggregated addresses. Fine again.

Then, we have a  'requirement' document that pretend to explain why we need
'local' addresses. If you read it carefully, and as acknowledged by one 
of its main
author in Vienna, almost all of those requirements (if not all) would be 
fulfilled
by provider independent addresses. Actually, there is nothing in it that
explain why we need 'local range' addresses. The essence of those
requirements is in the need for stable addresses that are
independent from ISPs.

So using this document (I checked the new combined one, it is the same 
issue)
to justify introducing "local" addresses and doing so without clearly
understanding the impact of those "ranged" addresses on the architecture
and the current implementation is a flawed process.
In particular, we need to understand the impact on address selection,
and the layer violation that would be created by coupling DNS views & 
routing.

IMHO, what need to happen is the following:

-1. Make an in-depth study of the consequences of introducing
      addresses with different ranges.

-2. Realize that if the issue at stake here has more to do with getting 
addresses
      than with their actual scope/range, something probably can be
      done working with the registries. It might be a cheaper path
      than changing the protocols. After all, IPv6 addresses are plentiful,
      we should have easy access to them!

What to do with Site Local addresses in the meantime is a non issue for me.

    - Alain.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 4 Aug 2003 14:38:32 -0700 (PDT)

FWIW, I wasn't there but I agree with Alain. I've
never seen any compelling evidence that scope qua
scope is what people actually need. And scope
brings any number of architectural questions to
the fore. I'd be much, much more comfortable
having an up/down pronouncement on whether PI
addressing is feasible before we march down this
road. There are very wide implications of both and
I think there's a tremendous amount of discomfort
with the possibility that scope will result in a
back door for NAT's to invade ipv6. I don't think
that anybody wants that. Before we head that
direction, I'd like to see PI addressing, in an
RFC preferrably, pronounced a dead end.

		 Mike

---

From: "Todd T. Fries" <[email-masked]>
Date: Mon, 4 Aug 2003 17:07:01 -0500

I'd like to third this motion.

Provider independent addressing is the number one gripe of a few people I know.

As things currently read, you're either an ISP, an infrastructure site, or
you do not get to multihome.  Tell that to Dow Jones.  They can rely on one
upstream isp, or get multiple allocations, which in effect relies on round
robin dns in the event one upstream is down.  Seriously.  I have done some
research today, and watched the entire April IETF mpg as pointed out a few
posts earlier.  I feel there is definately a feeling that people will need
their own unique provider independent address space, whether that be
ultimately defined as site local or provider independent.  I know this
makes some headaches for the routing table, but in my opinion, it is
far easier to deal with a large number of routes than a large number of
NAT's.

What requirement of site-local does provider independent addressing not
provide?

(Personally, I feel that if a company needs `private addresses' for research
 and such, they can do so in an un-allocated range knowing full and well they
 are operating in private and will re-number when going public and allocating
 their public addresses anyway.)

Thanks,
-- 
Todd Fries .. [email-masked]

Free Daemon Consulting, LLC                    Land: 405-748-4596
http://FreeDaemonConsulting.com              Mobile: 405-203-6124
"..in support of free software solutions."

Key fingerprint: 37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
            Key: http://todd.fries.net/pgp.txt

(last updated 2003/03/13 07:14:10)

Penned by Michael Thomas on Mon, Aug 04, 2003 at 02:38:32PM -0700, we have:
| 
| FWIW, I wasn't there but I agree with Alain. I've
| never seen any compelling evidence that scope qua
| scope is what people actually need. And scope
| brings any number of architectural questions to
| the fore. I'd be much, much more comfortable
| having an up/down pronouncement on whether PI
| addressing is feasible before we march down this
| road. There are very wide implications of both and
| I think there's a tremendous amount of discomfort
| with the possibility that scope will result in a
| back door for NAT's to invade ipv6. I don't think
| that anybody wants that. Before we head that
| direction, I'd like to see PI addressing, in an
| RFC preferrably, pronounced a dead end.
| 
| 		 Mike
| 
| Alain Durand writes:
|  > 
|  > 
|  > Bob Hinden wrote:
|  > 
|  > > [IPv6 working group chair hat on]
|  > >
|  > > I think the working group has been making good progress on replacing 
|  > > site-local addresses and wanted to get feed back from the working 
|  > > group on how we should move forward.  This is not intended to directly 
|  > > relate to the ongoing appeal of the working groups decision to 
|  > > deprecate the usage site-local addresses, but to get feedback on how 
|  > > to proceed.  I think it is very important that we move forward on this 
|  > > issue and not rehash what has happened in the past.
|  > >
|  > > We now have a combined local addressing requirements document 
|  > > <draft-hain-templin-ipv6-limitedrange-00.txt>, a specific alternative 
|  > > to site-local addresses draft 
|  > > <draft-hinden-ipv6-global-local-addr-02.txt> (accepted as a working 
|  > > group item at the Vienna IETF), and will soon have a draft describing 
|  > > why site-local addresses are being deprecated and doing the formal 
|  > > deprecation (authors identified and outline discussed at the Vienna 
|  > > IETF).  Note that all of these documents will proceed through the 
|  > > normal working group and IETF processes of last calls and review.
|  > >
|  > > I think legitimate questions have been raised about how the working 
|  > > group should go about deprecating site-local addresses given their 
|  > > maturity in the current specifications and use in deployed products.  
|  > > Specifically should they be deprecated independently from having an 
|  > > alternative solution available, at the same time an alternative is 
|  > > available, or sometime after an alternative is available.  A forth 
|  > > alternative is to not replace site-local addresses in any form, but I 
|  > > think the working group has made it clear that this is not a 
|  > > reasonable alternative. 
|  > 
|  > I have a real problem here. As I commented in Vienna and is mentioned in 
|  > the minutes,
|  > the entire process this wg is going through is wrong as it is based on a 
|  > flawed logic.
|  > 
|  > We had site local addresses. After lengthy debates, the wg realized that 
|  > there were
|  > a number of significant issues that outweighed the reported benefits, so 
|  > there
|  > is an attempt to deprecate them. Until now, fine.
|  > 
|  > Now, some people convinced the wg that SL addresses were having a role
|  > that is not fulfilled by provider aggregated addresses. Fine again.
|  > 
|  > Then, we have a  'requirement' document that pretend to explain why we need
|  > 'local' addresses. If you read it carefully, and as acknowledged by one 
|  > of its main
|  > author in Vienna, almost all of those requirements (if not all) would be 
|  > fulfilled
|  > by provider independent addresses. Actually, there is nothing in it that
|  > explain why we need 'local range' addresses. The essence of those
|  > requirements is in the need for stable addresses that are
|  > independent from ISPs.
|  > 
|  > So using this document (I checked the new combined one, it is the same 
|  > issue)
|  > to justify introducing "local" addresses and doing so without clearly
|  > understanding the impact of those "ranged" addresses on the architecture
|  > and the current implementation is a flawed process.
|  > In particular, we need to understand the impact on address selection,
|  > and the layer violation that would be created by coupling DNS views & 
|  > routing.
|  > 
|  > IMHO, what need to happen is the following:
|  > 
|  > -1. Make an in-depth study of the consequences of introducing
|  >       addresses with different ranges.
|  > 
|  > -2. Realize that if the issue at stake here has more to do with getting 
|  > addresses
|  >       than with their actual scope/range, something probably can be
|  >       done working with the registries. It might be a cheaper path
|  >       than changing the protocols. After all, IPv6 addresses are plentiful,
|  >       we should have easy access to them!
|  > 
|  > What to do with Site Local addresses in the meantime is a non issue for me.
|  > 
|  >     - Alain.
|  > 
|  > 
|  > --------------------------------------------------------------------
|  > IETF IPng Working Group Mailing List
|  > IPng Home Page:                      http://playground.sun.com/ipng
|  > FTP archive:                      ftp://playground.sun.com/pub/ipng
|  > Direct all administrative requests to [email-masked]
|  > --------------------------------------------------------------------
| --------------------------------------------------------------------
| IETF IPng Working Group Mailing List
| IPng Home Page:                      http://playground.sun.com/ipng
| FTP archive:                      ftp://playground.sun.com/pub/ipng
| Direct all administrative requests to [email-masked]
| --------------------------------------------------------------------
--------------------------------------------------------------------
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: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Tue, 5 Aug 2003 00:38:39 +0200

I think there is a small but important, difference here between what PI and limited-range can provide.

1) PI needs some kind of registration process.
2) Limited-range can be an automatic process.

It seems to me that 2) make sense in small networks, like unmanaged networks, where you will not ask the customers to go for 1.

Anyway, as it was pointed already in Vienna, there is, may be, a chance to have both 1 & 2, being a complementary solution.

Regards,
Jordi

---

From: Bob Hinden <[email-masked]>
Date: Mon, 04 Aug 2003 16:14:37 -0700

[no hats on]

>'local' addresses. If you read it carefully, and as acknowledged by one of 
>its main

If this means non-globally routable provider independent addresses (e.g., 
<draft-hinden-ipv6-global-local-addr-02.txt> ), then I am in agreement that 
a solution doesn't have to be limited in scope (or range) like site-local 
addresses are.

If this means globally routable provider independent addresses.  Then it 
is, of course, correct that this would solve many of the problems 
too.  Unfortunately, there is a big problem why this isn't a practical 
choice we can make now.   We don't have, IMHO, any idea how to make 
globally routable provider independent addresses work at scale in the 
Internet.  There are a number of problem area.

We don't know how to route them at the scale of the current Internet.  The 
current routing technology we have now would have to treat each provider 
independent prefix as a separate route.  That would be one route per 
organization.  That is way too many routes to be handled by anything close 
to current technology and products.  It would be turning off aggregation.

If we had new routing technology that could handle globally routable 
provider independent addresses, then it would have to be deployed in most 
routers in the Internet before it would be useful.  Probably all routers 
from the site boundary to the core of the Internet.  Given that I suspect 
any solution in this area would not be an incremental changes to a routers 
implementation (i.e., not another BGP extension), perhaps even changes to 
the routers route lookup engines (in hardware in many cases) this would 
likely take a long time to accomplish.  Also, a bit of a chicken and egg 
deployment problem that everyone working on IPv6 understands too well.

We don't have any structure in place to allocate and register these types 
of addresses.  The registries might be able to do it, but as they are 
currently structured they are mostly focused on ISPs, not individual 
sites.  This would require some major changes in their structure and 
perhaps funding models. Right now every site would have to be an LIR.

Assuming routing technology was available and all of the routers were 
modified  to support the new routing technology, then there would have to 
be some incentive for the ISP to want to carry these type of routes.  They 
are great for the customers, but it makes it easy for their customers to 
switch ISPs.  We have seen how well the phone providers have embraced 
provider independent phone numbers.  They only "agreed" to support them 
after governmental action.  I suspect ISP might not be widely enthusiastic 
to deploy them.

So overall if we had all of these problems solved it would be 
great.  Beside just the local address problems, it would deal with site 
multihoming, site mobility, change of ISP, and more.  It's a great problem 
to work on as the benefits are many.  But I don't think we will see 
solutions to these problem in the near or medium terms.  I think the 
routing problem is a significant research topic that people have been 
working on for a long time.

Until solutions two these problems are available, I don't see this as a 
viable alternate to the current approaches.

Bob

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Aug 2003 16:14:10 -0700

Alain Durand wrote:
> ...

This is not an introduction, they happened long ago ...

>       we should have easy access to them!

This is not just a registry issue, the effect of random PI addresses on the
global routing system also has to be factored in.

---

From: Fred Templin <[email-masked]>
Date: Mon, 04 Aug 2003 17:24:57 -0700

My primary concern is and always has been support for sites that
"bump into one another" from time to time, which can happen as result
of site mobility and/or temporal links between sites (e.g., VPNs, leased
lines, range-restricted wireless links, etc.) Also to support sites that are
intermittently connected to and/or frequently change provider points
of attachment. Site multi-homing is clearly another area of prime
concern expressed by others.

As can be seen from the IETF 56 meeting minutes, I stated a position
closest to Bob's option B) below and in fact abstained from the balloting
when the question was called on the list while stating my reasons for
doing so. But,  after significant further study, I can see no way in which
the current site-local specification satisfies any of the above requirements
and can in fact only see trouble down the road if site-locals emerge in wide
scale deployment. So, I am now of the opinion  that option A) below
provides the most workable alternative.

Fred
[email-masked]     

P.S. This is not to say we should stop working on solutions for such
"active" sites; only that the solutions should be worked independently
of site-local deprectaion.

Bob Hinden wrote:

> A) Deprecate Site-Local addresses independently from having an 
> alternative solution available.  This would mean that the working 
> group should treat the deprecation, and requirements and solution 
> documents outlined above independently from each other.  If there was 
> no consensus on an alternative a replacement would not happen.
>
> solution is agreed to.  This would mean advancing both documents at 
> the same time and making them include normative references to each 
> other to insure that they were published at the same time.  This would 
> result in the deprecation only happening if a consensus was reached on 
> an alternative.
>
> standardized, and in operational practice.  This would mean not 
> advancing a deprecation document until there was operational evidence 
> that the alternative was working and shown to be an improvement over 
> Site-Local addresses.
>
> alternative approach that is an improvement from the ones I outlined.  
> I hope that many of you will respond.
>
> Thanks,
> Bob
>

---

From: Alain Durand <[email-masked]>
Date: Mon, 04 Aug 2003 17:21:03 -0700

Bob Hinden wrote:

>> 'local' addresses. If you read it carefully, and as acknowledged by 
>> one of its main
>> author in Vienna, almost all of those requirements (if not all) would 
>> be fulfilled
> If this means non-globally routable provider independent addresses 
> (e.g., <draft-hinden-ipv6-global-local-addr-02.txt> ), then I am in 
> agreement that a solution doesn't have to be limited in scope (or 
> range) like site-local addresses are.
>
> If this means globally routable provider independent addresses. Then 
> it is, of course, correct that this would solve many of the problems 

What I mean is provider independant, registry allocated, public address 
space.
The fact that they are or not routable is an orthogonal issue
to be worked by contract between ISPs and their customers.
There is no way that the IETF or the registry can play a role there,
this is pure economy.

> We don't know how to route them at the scale of the current Internet.

And we do not have to. If I want a block for my house and do not plan
to use it for something else, I will get such a block and not ask my ISP
to route it.
If I want to set-up a VPN between two networks, I will go to my ISP
and ask for limited routing.
If I start a new company and am successful, I may want to
get back to my ISP and ask: "how much to globally route my own personal 
/48?"

This is somehow a self-regulating problem. If only a few players want their
pesonal /48 announced, this is no big deal and the cost will be low.
If more people wants this, the cost will increase, and it will then become
a trade-off, the value of having your personal prefix announced in the DFZ
versus the size of your bill at the end of the month.

> We don't have any structure in place to allocate and register these 
> types of addresses. The registries might be able to do it, but as they 
> are currently structured they are mostly focused on ISPs, not 
> individual sites. This would require some major changes in their 
> structure and perhaps funding models. Right now every site would have 
> to be an LIR. 

 From private discussions, I'm not sure this is that impossible to achieve.
I'll let them comment.

> modified to support the new routing technology, then there would have 
> to be some incentive for the ISP to want to carry these type of routes.

see above.

> They are great for the customers, but it makes it easy for their 
> customers to switch ISPs. We have seen how well the phone providers 
> have embraced provider independent phone numbers. They only "agreed" 
> to support them after governmental action. I suspect ISP might not be 
> widely enthusiastic to deploy them. 

Give that the regulators decided that phone carriers had to support 
telephone number
portability, how long do you think it will take before they decide that 
ISP have to
do the same?

- Alain.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 4 Aug 2003 17:53:14 -0700 (PDT)

> Internet.  There are a number of problem area.

Bob,

The issue I have is that there are a number of
problems that are all interrelated in various
ways: renumbering, multihoming, mobility, address
stability, etc which we as IETF'ers need to take
into consideration for building a net which will
be useful 10 years from now. I suspect that there
is no "right" answer aka silver bullet because of
all of the conflicting requirements, so the
ultimate answer is likely to be some form of
picking palatable poison (ppp for short).

You're certainly right that we have no good clues
as to how to scale PI up to Internet scaling. On
the other hand, we know that NAT's will step in
the second that they are expedient and solve a
problem -- inelegantly -- not feasible other ways.
And we all know what a horrible hack NAT's
are. Nor do I see how anybody can suggest with a
straight face that there will not be NAT's which
bridge local addressing domains with the global
addressing domain. It wouldn't even surprise me
that that even happens today; heck I probably know
the product manager responsible for it.

But I'm sorry, if NAT's become a de-facto
necessity for v6 native networks (putting aside
the need for v4/v6 NAT's), then I find the entire
premise of ipv6's utility deeply undermined. Quite
possibly fatally. So without trying to be too
preachy, I think that we really should have a
preponderance of evidence that we absolutely,
positively cannot make either PI and/or
renumbering based solutions work in a way that
people can deploy and use them.

I fully understand the compelling arguments of
Moore's law and disaggregated addresses in the
current internet. Obviously any PI solution could
not be naive. However, it doesn't seem to me that
there's been nearly enough work to develop a PI
friendly Internet. And even though Fred's
operational renumbering uncovered all kinds of
other intractibilities -- especially as you want
to scale it down to smaller networks, I still
think the jury is out. Also: we can be pretty
certain that any PI solution and/or renumbering
solution if it exists will highly likely have
serious warts. But this needs to be compared to
alternative: NAT's. NAT's being required to deploy
in real life basically says that the internet
stupid-network/global addressing design was
flawed. Are we really ready to make such a
pronouncement? Are we ready to say that global
transparency lost the argument? The market place
pretty much says that, but are we ready?

Maybe this train has long since left the station
and the IETF is impotent change that, but it sure
seems to me that if we cannot solve this in such a
way that NAT's aren't the inevitable result (eg,
the path of least resistance) then we should
immediately change tacks and embrace addressing
realms and ALG forwarders through those realms as
an architectural principal.

Thus, a lot is riding on this IMO, and my feeling
is that the vehemence of the uncomfort with
locally scoped addresses is that it tacitly
concedes our inability to keep with the
architectural principal of a dumb globally
addressed network. And I also get the feeling that
there is not anything approaching consensus to
admit defeat on that architectural principle, so
even these small sensible steps that you propose
nonetheless seem grave in their global
implications.

So if we can't deal with requirements of address
stability and/or renumbering, etc without
non-global addressing realms, let's document it,
reassess our architectural principles, and move
on. Until then, we're just pushing off the
inevitable confrontation: a confrontation which
IMO will decide the shape of the net for years to
come.  Quite frankly the marketplace will decide
for us with NAT's in the mean time, no matter how
much myself or anybody else whines about it. Let's
at least drive this to a conclusion one way or the
other from an engineering standpoint to see if
this is both technically and economically
hopeless. Until then, we're just gnashing.

		Mike

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 05 Aug 2003 10:09:02 +0900

>a replacement would not happen.

	my choice is (A).  as we have discussed at SF (and probably prior
	meetings) site-local address has a lot of issues with it, for instance,
	- ambiguous address
	- can't be used referrals across site zones, and there's no way to 
	  determine if a site-local address is from out-of-site or not
	  (because of ambiguity)
	- mandates hosts to know the topology, which we should not allow/mandate
	- site-border router issues, and (lack of) routing protocol
	  functionality to handle it
	therefore sooner deprecation is better.

itojun
PS: each of the items are summary of discussions we had before, to my ears,
don't try to comment on each items please.  the point of the email is
the very first sentence, and that's all.
--------------------------------------------------------------------
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: Ralph Droms <[email-masked]>
Date: Mon, 04 Aug 2003 23:01:15 -0400

I've reviewed the minutes from the ipv6 WG meeting in SF and those minutes
reflect my memory that the question about deprecating site-local addresses
was put to the WG independent of any consideration of a replacement
mechanism.  Clarifying e-mail to the ipng mailing list from Margaret
(3/28/2003) further reinforces that the WG was simply asked about
deprecating site-local addresses and not about any possible replacement:

>It became clear that there was significant support
>within the group for deprecating site-local addressing altogether,
>so we decided to call a different questions -- whether or not to
>deprecate site-local addressing.

Bob's e-mail to the ipng mailing list used to judge WG consensus on
deprecating site-local addresses asked:

>The question is:
>
>          Should we deprecate IPv6 site-local unicast addressing?
>
>Valid responses are:
>
>         "YES -- Deprecate site-local unicast addressing".
>         "NO -- Do not deprecate site-local unicast addressing".

which I read to be pretty clearly independent of consideration of any
replacement mechanism.  In response to Bob's question on the WG mailing
list, the YESes followed the format from Bob's e-mail - that is, those YESes
were unconditional "YES -- deprecate SL", not any form of "YES -- deprecate
SL after a suitable replacement has been defined".

So, given that history, on what basis are we now considering the question:

>available, or sometime after an alternative is available.

Furthermore, based on the record of the question from the minutes of the SF
meeting and the question put to the ipng mailing list, how was this
conclusion arrived at:

>A fourth alternative is to not replace site-local addresses in any form, 
>but I think the working group has made it clear that this is not a 
>reasonable alternative.

- Ralph

---

From: Bob Hinden <[email-masked]>
Date: Mon, 04 Aug 2003 20:17:10 -0700

Thanks to everyone who has responded with a preference so far.  Please keep 
them coming.

To make it a little easier to keep track of the results, please only use 
the above subject for direct responses.  Move discussions to other Subjects.

Thanks,
Bob

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 5 Aug 2003 05:40:50 +0200

> This is not an introduction, they happened long ago ...

...but what has happened _now_ is that people wake up and see that 
introduction was possibly wrong, so the decision must be revoked.

We better remove this while we don't have any large deployment of IPv6. 
The longer we wait, the more problematic the surgery will be.

Using "we already have this written down" is for me not an argument 
keeping it.

Just look at what happens with DNSSEC (RFC 2535) at the moment! It is 
NEVER too late to regret a decision.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 5 Aug 2003 05:47:20 +0200

From an Application (above TCP) perspective, A, definitely A. Itojun 
summarizes well the issues. Mandating a host to know topology is just a 
really bad thing. Really really bad.

    paf

On tisdag, aug 5, 2003, at 03:09 Europe/Stockholm, Jun-ichiro itojun 
Hagino wrote:

>> alternative

---

From: Bob Hinden <[email-masked]>
Date: Mon, 04 Aug 2003 21:15:21 -0700

Ralph,

>>but I think the working group has made it clear that this is not a 

It's from my reading of the discussion (on the mailing list and in the 
meetings) and the fact that the working group decided to accept 
<draft-hinden-ipv6-global-local-addr-02.txt> as a working group document in 
Vienna.

Bob

---

From: Rob Austein <[email-masked]>
Date: Tue, 05 Aug 2003 00:40:10 -0400

At Mon, 04 Aug 2003 11:06:55 -0700, Bob Hinden wrote:
> 
> Please respond to the list with your preference

Sigh.  A.

["But where are the clowns?  There ought to be clowns.
  Well, maybe next year."  -- Stephen Sondheim]
--------------------------------------------------------------------
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: "EricLKlein" <[email-masked]>
Date: Tue, 5 Aug 2003 08:08:47 +0300

I vote for C, you can't ask people who are up and running with something
today to just stop with out a plan on replacing it. Otherwise FEC0:: will
stay a de facto private range as we will have implementations using it and
ones that are not.

----- Original Message -----
From: "Bob Hinden" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 04, 2003 9:06 PM
Subject: Moving forward on Site-Local and Local Addressing

alternative
> insure that they were published at the same time.  This would result in
the
> standardized, and in operational practice.  This would mean not advancing
a

---

From: Eliot Lear <[email-masked]>
Date: Mon, 04 Aug 2003 22:44:15 -0700

Bob,

I am sorry, but while it is a good attempt to come up with a happy 
medium between SLs and global addresses, I disagree with the approach 
that draft-hinden-ipv6-global-local-addr-02.txt takes.  I would prefer 
an approach that makes the stability of the IP address less important 
rather than attempting to stablize it (a seemingly lost cause).

What this means to me is that first we need to promulgate something 
along the lines of draft-baker-ipv6-renumber-procedure-00.txt.  It needs 
some expanding to further automate the process.  The more we automate 
the less pain the network manager will feel during a renumbering event.

This changes the problem from one of a scoped address to one of a 
standard default and reduces any ambiguity that we might have.  It 
leaves open the question of how to find a name server, and how a name 
server finds you, but the former can be found with SLP, and the latter 
can then be handled with DDNS.

I'd like to put Fred on the spot (not having asked him) and propose that 
his draft be adopted as a WG doc.

Eliot

---

From: "Yibo Zhang" <[email-masked]>
Date: Tue, 5 Aug 2003 15:14:10 +0900

I vote for B from individual technical perspective.
C and A can only be agreed with politically.

----- Original Message -----
From: "Bob Hinden" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 05, 2003 3:06 AM
Subject: Moving forward on Site-Local and Local Addressing

alternative
the
a

---

From: Eliot Lear <[email-masked]>
Date: Mon, 04 Aug 2003 23:40:04 -0700

Based on Ralph's analysis I vote A to support the WG's prevous decision. 
  That having been said, as I wrote in my previous email, I'd like to 
proceed on multiple fronts to develop solutions to the underlying 
problems that site-local attempted to address.

By the way, would others please state WHY they are voting the way they 
are voting?  I think it's sufficient to indicate that you agree with 
someone else's reasoning, as I have.

Eliot

---

From: Leif Johansson <[email-masked]>
Date: Tue, 05 Aug 2003 08:48:15 +0200

Patrik Fältström wrote:

> summarizes well the issues. Mandating a host to know topology is just 
> a really bad thing. Really really bad.
>
>    paf

I am worried that continuing to beat the dead horse gets v6 nowhere. I 
know of several
non-ipv6 people (people with backgrounds in security and applications) 
who got involved
in the site-local debate because they were worried about the way the wg 
was heading. The
consensus in SF to deprecate site-local (and that is exactly what it 
was) was seen as
progress by many who are now probably not paying attention having moved 
on to other
pressing matters. It is probably good to keep that in mind when judging 
the current debate.

       Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 05 Aug 2003 08:50:04 +0200

> a really bad thing. Really really bad.
I concur with an added "really" tagged on.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 05 Aug 2003 16:59:31 +0900

>>>>> On Mon, 04 Aug 2003 11:06:55 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

I prefer this one:

> solution available.

I know my vote is not consistent with what I said in the previous vote
after the San Francisco meeting (attached below).  Though I still have
the same concern (in fact, we've already seen a "confusion"), I think
it is most productive to support option A and (at least try to) move
forward anyway.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: [email-masked]
Date: Tue, 08 Apr 2003 02:47:16 +0900

>>>>> On Tue, 01 Apr 2003 14:37:56 -0500, 
>>>>> Margaret Wasserman <[email-masked]> said:

- because I'm not convinced that there is a clear consensus on an
  alternative to site-local or that we do not need such a consensus.

I'm sad I must vote for NO...I've tried to convince myself by
the meeting minutes, presentation slides, discussion in this list, and
some private discussion, but I failed.

I've seen many candidate alternatives that at least include:
  - arbitrary (random) global prefix
  - fec0:: + random bits
  - free prefix allocation service

I've even seen a wording nit like:
  - leave site-local in the spec, but make a recommendation to avoid
    using it.
  (but can't this also be interpreted as a sort of 'not deprecate
  site-local'?)

I could not be sure if we'll be able to make a consensus on any of
them (or others) quickly, if we choose "deprecating" site-local.  If
not, the result will just be a confusion.  If we can, then I don't see
why we cannot first make a consensus quickly and then deprecate
site-local.

I (of course) don't know the final result of this vote at this
moment.  But regardless of the result, I'm willing to follow it
without making a further objection, and will try to make a productive
contribution based on the result.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Dean Strik <[email-masked]>
Date: Tue, 5 Aug 2003 10:45:53 +0200

> A) Deprecate Site-Local addresses independently from having an alternative 

A.

-- 
Dean C. Strik             Eindhoven University of Technology
[email-masked]  |  [email-masked]  |  http://www.ipnet6.org/
"This isn't right. This isn't even wrong." -- Wolfgang Pauli
--------------------------------------------------------------------
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: [email-masked]
Date: Tue, 05 Aug 2003 12:02:47 +0200 (CEST)

> A) Deprecate Site-Local addresses independently from having an

A. Stabilize the patient, then worry about how to make arms and legs work again.

---

From: "Chirayu Patel" <[email-masked]>
Date: Tue, 5 Aug 2003 16:39:07 +0530

My understanding is that the workgroup has voted to deprecate site-locals
unconditionally (having no dependency on the development and acceptance of
alternatives). Thus, I vote for A. 

Apart from the above reason, I feel that deprecating site-locals ASAP will
lead to a rapid development of alternate solutions, as the WG will have an
urgency to fill the holes left by site-locals.

CP

> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Bob Hinden
> Sent: Monday, August 04, 2003 11:37 PM

---

From: Hans Kruse <[email-masked]>
Date: Tue, 05 Aug 2003 10:52:07 -0400

B.  Captures the declared consensus and agreed work items.

<Short Reasoning>
Politically A. will deprecate site locals and strand their replacement in 
the WG forever -- the result will be prefix hijacking -- not good.

C. seems too ambitious given that a group of folks urgently feel that 
continued SL deployment will be harmful.

<Longer Reasoning>
The consensus reached by this WG is tenuous at best.  The essence of the 
discussions seems to pretty clearly combine the need to remove SLs and to 
introduce a "replacement".  A subset of the group just wants SLs gone. 
Another subset points out (correctly I think) that circumstances exist 
where a provider-based prefix won't work.

Folks, this is not rocket science.  IPv6 needs a known prefix that can be 
distinguished from provider-based addressing, and a mechanism to uniquely 
(or almost-uniquely) assign addresses out of this prefix.  I won't rehash 
all the reasons why -- check the list archives.  There really are only two 
down-sides -- someone could start routing these prefixes and someone could 
try to NAT them.  These need to be addressed in the appropriate documents 
(e.g., node requirements that prohibit address replacement in the header, 
etc.).  IMHO the dynamics that initially created IPv4 NAT are not present 
in IPv6, but that is another discussion.

There is real danger here;  I have already started to see mailing list 
discussion going something like:
Q. What address prefix do I use for this network before I get my provider 
prefix?
A1. Use FECO (Site Local).
A2. No, No, FECO has been outlawed by the IETF, just invent a prefix!

I have seen the 2002 mapping of RFC 1918 suggested.

"Private" space will appear -- I want a version that is thought out, that 
is well documented and understood, not a mish-mash of hijacked prefixes and 
IPv6'afied RFC1918 stuff.

> the deprecation only happening if a consensus was reached on an

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
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: Zefram <[email-masked]>
Date: Tue, 5 Aug 2003 16:07:54 +0100

The three options are really the same.  We already have alternatives
to site-local addresses: 6to4 addresses based on PI or RFC1918
IPv4 addresses.  We didn't have these alternatives a few
years ago.  These aren't perfect, which is why we must develop
draft-hinden-ipv6-global-local-addr, but they're enough that
fec0::/10 seems rather unnecessary in any current IPv6 deployment.
They particularly handle the requirements of those organisations that
want site-locals because that's what they had with IPv4 and they want
the same again.

So I support option A, deprecate site-locals independent of further
development of alternatives.  We have sufficiently good stopgap solutions.

I'm expecting, by the way, that the deprecation will leave fec0::/10
to be treated as global-scope unicast addresses, rather than making
fec0::/10 addresses cease to function altogether.

-zefram

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 05 Aug 2003 11:24:35 -0400

> a replacement would not happen.

"A".  

Site locals as presently defined are incomplete.  I believe that they
represent a "wrong turn" taken a while back.  We need to make a clear
statement that no energy should be wasted in implementing/supporting
them in application and other upper-layer protocols.

						- Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Aug 2003 17:25:48 +0200

I'll go for B, or perhaps A.9 (i.e. a version of B in which
we avoid recursive normative references between the two documents).

I don't think we help anyone by delaying the deprecation until a
new solution is "in operational practice." Deprecation doesn't mean
switching off; it just means a strong statement about future
switching off. So there is no reason to wait as in C.

Personally I would happily accept A, but it isn't worth a fight.

   Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Aug 2003 17:29:37 +0200

Eliot,

That seems to me to be orthogonal. I agree that it would be good to see
renumbering support (maybe it's a v6ops item??). But that doesn't destroy
the value of Bob's proposal.

   Brian

---

From: Ralph Droms <[email-masked]>
Date: Tue, 05 Aug 2003 11:36:47 -0400

Bob,

Thanks for the clarification.  I think I misunderstood "not replace
site-local addresses in any form".  If I have it right, the phrase implies
"explicitly do not consider any alternatives", to which I agree that
accepting <draft-hinden-ipv6-global-local-addr-02.txt> indicates that the WG
is interested in considering alternatives.

- Ralph

At 09:15 PM 8/4/2003 -0700, Bob Hinden wrote:
><draft-hinden-ipv6-global-local-addr-02.txt> as a working group document 
>in Vienna.
>
>Bob
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 05 Aug 2003 08:54:10 -0700

Ralph,

>is interested in considering alternatives.

That is correct.   Also, any specific alternative will have to go through 
the normal w.g. and IETF processes so it's not done until the RFC is published.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Aug 2003 18:07:29 +0200

Zefram wrote:
...
> fec0::/10 addresses cease to function altogether.

That's an interesting expectation. As co-author of the planned
deprecation draft, I'd been assuming a more classical deprecation
action, in which we would simply state the previous semantics of
FEC0::/10, state that the prefix SHOULD NOT be used, but leave it
permanently assigned by IANA.

This would break nothing that runs today.

What do people think?

---

From: Zefram <[email-masked]>
Date: Tue, 5 Aug 2003 17:18:53 +0100

>This would break nothing that runs today.

Would a new implementation then be permitted to not implement the
site-local semantics?  The above sounds like full implementation would
remain mandatory, which makes deprecation less of a win than it could be.
Perhaps the question is: are we deprecating the use or the implementation
of site-locals?  Perhaps we are deprecating both to different degrees?

-zefram

---

From: Hans Kruse <[email-masked]>
Date: Tue, 05 Aug 2003 12:13:23 -0400

This may be a nit -- but wouldn't it make more sense then to call you 
preferred course of action "B", and publish 2002:RFC1918 as the (temporary) 
replacement?

I guess I am suggesting that the WG pursue its work in such a way that we 
do not create a vacuum; I feel strongly that the set of IPv6  standards 
documents should clearly define the address space to use for the cases that 
folks have suggested are currently covered by site-local.

---

From: Fred Templin <[email-masked]>
Date: Tue, 05 Aug 2003 10:00:53 -0700

Hans Kruse wrote:

> Q. What address prefix do I use for this network before I get my 
> provider prefix?
> "Private" space will appear -- I want a version that is thought out, 
> that is well documented and understood, not a mish-mash of hijacked 
> prefixes and IPv6'afied RFC1918 stuff. 

Perhaps you havn't seen 'draft-hinden-ipv6-global-local-addr-02.txt'?

Fred
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Aug 2003 10:05:05 -0700

> permanently assigned by IANA.

The term "permanent" is a bit long.  It should not be used for some 
period of time, and since there's a lot of address space out there, 
perhaps that period of time should be considerable ;-)

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Aug 2003 10:13:53 -0700 (PDT)

> This would break nothing that runs today.

If you truly want to deprecate FECO::/10, I'd say
that it shouldn't be reserved to IANA, but given
to registries with explicit mandate to allocate 
it immediately. 

:-)/2

		Mike

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Aug 2003 10:27:48 -0700

> the value of Bob's proposal.

I guess my concern is that ISPs end up routing the address space in 
Bob's proposal and that we'll have another PI problem.  So while there's 
nothing wrong with Bob's proposal in theory (indeed I prefer it vastly 
to the other SL approaches), if customers believe they have stable 
addresses we could end up right back where we were in the early '90s.  I 
don't see this happening for DSL customers but it could happenfor medium 
to large size businesses who have the power of the purse.

Eliot

---

From: Michael Mielke <[email-masked]>
Date: Tue, 5 Aug 2003 13:51:02 -0400 (EDT)

> perhaps that period of time should be considerable ;-)

Wouldn't it make practical sense if the local addressing primarily stuck 
with the suffix :1 ?

-- 
Michael Mielke <[email-masked]>
http://www.mielke.cc/~michael/

---

From: Fred Templin <[email-masked]>
Date: Tue, 05 Aug 2003 11:09:22 -0700

>This would break nothing that runs today.

Maybe just list it as "IANA - Reserverd" for now? There are a number of
prefixes in the current IPv4 address space listed in exactly this manner.
See:

   http://www.iana.org/assignments/ipv4-address-space

Fred
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Aug 2003 11:07:53 -0700 (PDT)

> his draft be adopted as a WG doc.

I'd like to second that. Fred's document if
nothing else shows how close we aren't to meeting
the operational goal of renumbering without
significant blood-letting. Also: Fred's document
is aimed at a solution for somebody with enough
leverage to join the providers BGP cabal. While
that's a start, it doesn't explore this problem
nearly enough, IMO, especially for BGP have-nots.

	       Mike

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 5 Aug 2003 19:10:07 +0100

> [IPv6 working group chair hat on]

Well on the assumption that the "deprecation" actually happens...

> alternative was working and shown to be an improvement over Site-Local 

I'd prefer B.  Then C.  This because A would seem to result in the chance
that no replacement would be developed.

DF

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Aug 2003 11:29:40 -0700 (PDT)

> the value of Bob's proposal.

I disagree. What we seem to be dancing around with
here is an aversion to dealing with the actual
requirements of people who deploy networks. Even
though Bob's proposal polishes the site local
turd, it's still a dangerous stopgap and doesn't
address _why_ this requirement for stability in
the here and now is so strong, and the fact that
we don't have a credible answer.

       Mike

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 14:50:08 -0400

I can't believe I'm reading this.

Site locals were a design error.  They have no redeeming qualities, and
they never did. They should never have been in the PS version of the
specification in the first place.  It's taken us several years to
start to fix this tragic error, and now we're talking about delaying the
fix.

This is absolutely unacceptable, and I hereby formally ask the ADs to
forbid this WG from doing any further work to prolong them.

The talk about an alternative solution is misleading.  

SITE-LOCALS MUST DIE.  NOW.

Keith

> I would like to hear from the working group on how we should proceed. 
> I think the choices are:
> 
a

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 14:52:32 -0400

> Maybe just list it as "IANA - Reserverd" for now? 

No.  That would admit the possibility of reusing that prefix for some
other purpose.  What we really need is for all hosts and routers to
filter FEC0://10 packets unless explicitly configured to do otherwise.
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 14:54:11 -0400

> perhaps that period of time should be considerable ;-)

I don't think we're so short of address space that we'll miss it.
Mark that address block as deprecated, and make it take an IETF
Consensus process to reallocate it for some other purpose.
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 14:57:55 -0400

> Folks, this is not rocket science.  IPv6 needs a known prefix that can
> be distinguished from provider-based addressing, and a mechanism to
> uniquely (or almost-uniquely) assign addresses out of this prefix. 

No it does not.  We must not repeat the mistake of RFC 1918.

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 14:56:36 -0400

>  We already have alternatives
> IPv4 addresses. 

6to4 addresses based on RFC 1918 addresses should be forbidden.
IMHO, this is an oversight in the 6to4 RFC.
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 15:02:11 -0400

> along the lines of draft-baker-ipv6-renumber-procedure-00.txt.  It
> needs some expanding to further automate the process.  The more we
> automate the less pain the network manager will feel during a
> renumbering event.

I concur.  A real story for renumbering is probably the biggest "missing
piece" of the IPv6 puzzle, and we need to be devoting our energies to
solving this important problem rather than to propagating past errors.
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 15:29:24 -0400

> requirements of people who deploy networks. 

What we seem to be dancing around with here is an aversion to dealing
with the actual requirements of people who write applications.

It is not acceptable for the network to break address stability.

It is not acceptable for the network to expect apps to do routing.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Aug 2003 23:02:52 +0300 (EEST)

> IMHO, this is an oversight in the 6to4 RFC.

They are already forbidden (but perhaps you're saying the forbidding
should be even stronger than it's today).

You certainly can't use 2002:RFC1918 addresses inside generic sites -- 
when a router happens to switch on the 6to4 pseudo-interface, all the 
packets sent to 2002:RFC1918 will get blackholed.

In theory, you could deploy sites with 2002:RFC1918 addresses but being
careful not to deploy anything enabling 6to4, but why would you bother
when you could just hijack any prefix you'd want instead?

-- 
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: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 16:05:52 -0400

> should be even stronger than it's today).

yes, I'm saying that we should make it entirely clear that use of
RFC 1918 addresses within 6to4 addresses are a violation of the
standard, and that hosts should block them.

let's stamp out scoped addresses in our lifetime.

---

From: Hans Kruse <[email-masked]>
Date: Tue, 05 Aug 2003 16:15:15 -0400

Sorry; yes I have read that draft and plan to comment on it.  My remarks 
had to do with the "Choice A" approach of removing SLs without advancing 
that draft (or something else) _at the same time_.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 5 Aug 2003 17:30:07 -0700

August 05, 2003 12:02 PM  Keith Moore wrote:
> I concur.  A real story for renumbering is probably the 
> biggest "missing piece" of the IPv6 puzzle, and we need to be 
> devoting our energies to solving this important problem 
> rather than to propagating past errors.

> It is not acceptable for the network to break address stability.

You know it would help if your arguments were self consistent.

Tony

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 06 Aug 2003 02:42:22 +0200

> I would like to hear from the working group on how we should proceed.

My choice is A. Please, just let SL die, as an application programmer, I
find SL to be a mistake as currently designed. Lets move forward.

Love

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 20:42:16 -0400

> You know it would help if your arguments were self consistent.

there's nothing inconsistent between those two statements.  yes, we 
need to be able to renumber, but not without adequate notice and 
overlap, and not in a way that invalidates the identifiers that apps 
use to refer to their peers.

(and no, DNS names are not sufficient)

---

From: "Chirayu Patel" <[email-masked]>
Date: Wed, 6 Aug 2003 09:51:10 +0530

> This would break nothing that runs today.

I assume that "permanently assigned to IANA" has the same semantics as
"unassigned" (http://www.iana.org/assignments/ipv6-address-space). If not,
what is the difference?

CP

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 6 Aug 2003 08:05:39 +0300

> to registries with explicit mandate to allocate

This could cause problems with hardware that already is installed, and is
configured to treat FEC0:: /10 as local, thus (if properly configured) not
forwarding the packets.

This could be real bad. .;)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2003 09:54:23 +0200

> standard, and that hosts should block them.

RFC 3056 says:

   Suppose that a subscriber site has at least one valid, globally
   unique 32-bit IPv4 address, referred to in this document as V4ADDR.
   This address MUST be duly allocated to the site by an address
   registry (possibly via a service provider) and it MUST NOT be a
   private address [RFC 1918].

Now, which word in "MUST NOT" is hard to understand?

   Brian

---

From: Aidan Williams <[email-masked]>
Date: Wed, 06 Aug 2003 18:30:20 +1000

>      addresses with different ranges. 

How would this different from the material that has been presented 
already in the SL debate?  The whole anti-site-local argument is based 
around the consequences of a scoped addressing architecture that people 
don't like.

> -2. Realize that if the issue at stake here has more to do with 
> getting addresses
>      done working with the registries.

I don't think that is true.  The local-ness of these addresses avoids 
the issue of having to scalably route the PI space.  I can't see 
significant differences in process between globally unique local address 
allocation and a globally unique PI address allocation.

- aidan

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2003 10:56:40 +0200

> preferred course of action "B", and publish 2002:RFC1918 as the (temporary)

I can't see a single argument in favour of importing the RFC1918 mess
into IPv6. Such addresses would be worse than FEC0::/10, because they
would appear to be globally routeable, but wouldn't be. 

> folks have suggested are currently covered by site-local.

That is exactly the purpose of the trio of documents we are working on.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2003 11:12:30 +0200

Michael Thomas wrote:
> t***, it's still a dangerous stopgap and doesn't

"Why" is addressed in draft-hain-templin-ipv6-limitedrange-00.txt
That document may need more work, but it certainly attempts to
answer the question, convincingly to my mind.

   Brian
 
P.S. I fully concur that the renumbering document is needed too.
See author list of RFC 1900.

---

From: Aidan Williams <[email-masked]>
Date: Wed, 06 Aug 2003 19:19:38 +1000

I'm in favour of B.
I use SL addressing today to achieve address stability in a 6to4 
environment.
The current drafts look like progress to me and remove the biggest wart 
of SL: ambiguity.

- aidan

---

From: Geoff Huston <[email-masked]>
Date: Wed, 06 Aug 2003 20:35:07 +1000

At 06:30 PM 6/08/2003 +1000, Aidan Williams wrote:
 > I can't see significant differences in process between globally unique 
local address allocation and a globally >unique PI address allocation.

I'd offer the view that there's a lot of difference.

draft-hinden-ipv6-global-local-addr-02.txt is a good starting point in 
terms of describing the differences
in characteristics.

http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-doc-huston-local-use-addrs.doc
attempts to to refine this draft into some considerations from a registry 
perspective. (If there's interest
I'll put this out as an Internet Draft)

   Geoff Huston

---

From: "Yibo Zhang" <[email-masked]>
Date: Wed, 6 Aug 2003 19:38:54 +0900

>      addresses with different ranges.

That's definitely a good idea because that way we might be able to
replace all current local addresses with a single type of local addresses
with a Range or Scope field like the multicast addresses.
It would looks more consistent, more flexible, more scalable, and could
even help the WG move the current situation forward more smoothly and
smartly.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 05 Aug 2003 08:01:51 -0400

Hi Ralph,

>SL after a suitable replacement has been defined".

If you look at the results of this poll, though, you will see that
there was some significant resistance to deprecating site-local
addressing, without regard to a replacement (about 1/4 of the people
who responded to the poll indicated "NO").

Fortunately (if you favor finding consensus), many of the people
who expressed an opinion against the idea of deprecating site-local
addresses with no replacement did indicate (in their poll response,
or in other e-mail to the list) that they thought that site-local
addressing had serious problems, but that we should only deprecate
unicast site-local if we could provide an alternative for local
addressing.

In reading through the e-mail to the list (in response to the poll,
and other discussion), Bob and I determined that there was a
consensus to deprecate site-local addressing AND provide a
replacement.  And, that is what our consensus call said.

Our consensus call indicated that work to deprecate site-locals
and replace them would be undertaken "in parallel". Some people
have since asked, quite reasonably I think, whether "in parallel"
implies that these things would happen at the same time, or if
one could/should complete before the other (i.e. do we deprecate
then replace, replace and then deprecate, or do both at once).

It hasn't been clear (to me and Bob, anyway) from the discussion
what the consensus of the WG is regarding this question, which is
why Bob has posed a question to the list to try to clarify things.

If we don't reach any consensus on the order/dependency, then I
guess we will continue with all of the work items "in parallel"
and determine when/if we get WG consensus to advance each document
to the IESG. It would be easier to plan WG milestones and focus our
work, however, if we understand what order/dependencies the WG
would like to place on these work items.

>>but I think the working group has made it clear that this is not a 

I don't think that you could draw this conclusion from the
discussion at the SF meeting, but it has been pretty clear on
the mailing list that we do not have consensus to deprecate
site-local addressing unless we also develop a replacement.

In Vienna, the working group did accepted a replacement proposal
as a WG work item, which also seems to indicate that the
WG has consensus to replace site-locals with an alternative local
addressing mechanism.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 05 Aug 2003 07:32:01 -0400

I prefer option (B), but I would find option (A) acceptable.

Margaret

---

From: Lars Erik Gullerud <[email-masked]>
Date: 06 Aug 2003 15:02:41 +0200

> I would like to hear from the working group on how we should proceed.  I 

I'd like to see A happen. Going for B, and even worse C, will just
prolong the current state of uncertainty where a lot of people have
heard that site-locals might be deprecated, but are uncertain as to
whether they need to concern themselves with support for them or not in
ongoing development etc.

Let's just get rid of the darn things and move on - please.

/leg

---

From: "Nir Arad" <[email-masked]>
Date: Wed, 6 Aug 2003 17:47:41 +0200

Hi,

I was thinking to bring this suggestion myself, and I'm glad Yibo did.
Having a Scope field in unicast addresses seems (to me) to solve all-so-many problems.
I would go further to allow nodes to only send, receive and forward packets from- and to- the same scope.

Being still on the IPv6 learning curve I might well be wrong, but it seems to me the silver bullet for:
- Killing NAT ("site local" interfaces, whether globally unique or not, may never communicate with global unicast
interfaces)
- Simplifying address selection
- Cleaning the routing tables
- Simplifying router design and setup

Coming from a router design point-of-view, the current address architecture, and more important, the forseeable and
unforseeable changes within it, make it difficult to desgin a mechanism that identifies the source/destination address
scopes.

OK - now I'm ready to take the flames...

Regards,

-- Nir Arad

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Aug 2003 11:02:10 -0400

> then replace, replace and then deprecate, or do both at once).

Tthe problem with making deprecation dependent on having a replacement
is that this allows the SL proponents to delay the replacement, and thus
the deprecation, for an arbitrarily long time - long enough to ensure
that SLs are widely deployed.  In order to justify the delay, they can
cite arbitrary and unsubstantiated "requirements" that make the bar for
a replacement arbitrarily high - while ignoring the requirements that
are driving deprecation of SL.  This is unacceptable.
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Wed, 6 Aug 2003 11:05:09 -0400

> Now, which word in "MUST NOT" is hard to understand?

well, we don't say that hosts should block them.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 06 Aug 2003 11:08:51 -0400

>we avoid recursive normative references between the two documents).

If your version A.9 existed, I would have chosen it...

I don't much care for the idea of gratuitous normative references,
but I do believe that it makes sense to deprecate SLs and publish
their alternative at about the same time.

I think that is, more or less, where we have been headed,
anyway.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 06 Aug 2003 11:12:47 -0400

>This would break nothing that runs today.

The meaning of "deprecated" was discussed both in the meeting and
on the mailing list as indicating that the prefix would NOT be
reallocated.  So, I think that the prefix should be set-aside as
deprecated and reserved...

Otherwise, we could have some enterprises receive global allocations
in space that some implementations treat as site-local addressing.
Not good.

Margaret

---

From: Alain Durand <[email-masked]>
Date: Wed, 06 Aug 2003 08:46:37 -0700

On Wednesday, August 6, 2003, at 01:30  AM, Aidan Williams wrote:

> around the consequences of a scoped addressing architecture that 
> people don't like.

Many arguments in the SL discussion were about their ambiguity. This is 
now well understood, at least I dare to hope ;-)
Here the issue is range/scope. Some of the SL characteristics remain, 
not all, and this need to be understood better,
in particular, in the case where "local" and "global" addresses are 
intertwined:
- impact on node/application and address selection rules
- impact on routing protocols (because those addresses are not 
ambiguous, it might be simpler than SL,
   but this remain to be proven)
- impact on DNS, where you now have a strong coupling between this 
"local" routing and your views of the DNS.

> significant differences in process between globally unique local 
> address allocation and a globally unique PI address allocation.

See Geoff's answer.

	- Alain.

---

From: Hans Kruse <[email-masked]>
Date: Wed, 06 Aug 2003 11:32:35 -0400

I would like to inject a suggestion into the current SL replacement debate. 
(Note  that this is not my original idea, just something that I know the 
group started to  discuss and then dropped -- it might be good to pick up 
again now).

We have a trio of drafts that I fully believe can be polished into a 
combination  "deprecate SLs" and "here is how to handle special cases that 
require local  addressing".  We have also restarted a spirited debate best 
titled "SLs die.die.die".

In looking for clues (or clue), I found:

Love Hörnquist Åstrand:
> Please, just let SL die, as an application programmer, I
> find SL to be a mistake as currently designed.

Keith Moore had a similar comment; I have lost the extact quote.

Andrew White:
>Unless we allow only one address per node an application writer MUST 
assume that any
>arbitrary source-destination pair may fail while another may succeed.

>      addresses with different ranges.

and in draft-hain-templin-ipv6-limitedrange-00.txt
   In the simple case, hosts that are allowed external access have a
   policy that allows them to configure both global and limited range
   prefixes, while those that are not allowed global access have a
   policy that only allows limited range. ***Address selection rules will
   prefer the smallest range***, so internal communications are forced to
   stay internal by the hard filter at the border.

   (Emphasis added by me).

draft-hain-templin-ipv6-limitedrange-00 does a good job outlining scenarios 
that may  require the use of local addressing, but I think it errs in the 
statement above.  The  local addressing requirement is real enough, but 
these are still corner cases.  Aside  from ambiguity, enforcing the concept 
of scope or range _in every application_ seems  to be one that folks really 
want to get rid of.

Hence, lets revisit the question of _default_ address selection.  What if:

"Unless an application explicitly requests otherwise, an IPv6 node must use 
its  unique, globally routable address if one is configured.  If no such 
address is  configured, the node shall use its limited range local address, 
if configured."

Along with:

"An IPv6 node must allow an application to explicitly request the use of 
the limited  range local address, if such an address has been configured, 
even if a unique globally  routable address is available."

What I am trying to get to is:

- Application designers who want to work in the "end-to-end clean" Internet 
and who do  not care to support the corner cases should be able to do so.

- The default address selection rules should favor solutions based on 
global  addressing, I think we all agree that if such a solution is 
reasonably possible, it  should be used.  With the defaults above, the 
"path of least resistance" is not to use  limited range, which is good.

- Finally, if a solution requires local addressing, and application writers 
want to  support it, there needs to be a standardized way to do this (which 
is why local  addresses must be defined and recognizable).

In draft-hain-templin-ipv6-limitedrange-00, scenarios where all machines 
either have  only local addresses, or where all of them (albeit 
intermittently) acquire global  addresses along with the local ones, will 
work with the default behaviour suggested  above.

Cases where networks contain a mixture of nodes (some local only, some 
local and  global), and very long-lived connections in intermittently 
connected networks, need  special handling.  In both cases it seems 
reasonable that applications will be written  or at least configured to be 
aware of the local/global address issue.

Along with safeguards against address translation in the nodes requirement, 
and  routing restrictions in the address format document, this should work.

I know I left out plenty of detail, but I hope the general idea is clear 
enough.   Comment/Flame away.....

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2003 18:04:28 +0200

> I'll put this out as an Internet Draft)

Geoff,

Three comments on your draft:

1. I don't think the RIRs as institutions have any special standing 
to comment on the locally-assigned variant in draft-hinden. It's a 
technical choice for the WG and the IETF. If you're arguing personally
that you don't like the birthday paradox risk, let's discuss it.

2. Most of your arguments appear to be hinting at a re-run of the ICANN
wars for the centrally assigned variant. Well, that's why there is an
analogy with .org in the draft. You may be right that the pricing level
should be set competitively, but I really don't see this being a gold
rush. There's not much marketing value in a random number. In any case,
you're correct that the IETF can't decide this, but we need to give IANA
the clearest instructions possible.

Incidentally, since these are not routeable addresses, and have no 
geography, it doesn't follow that the RIRs have a role in this part
of the address space. In fact, the RIRs might be quite uncomfortable
with the idea of competing in the sale of random numbers.

3. I feel strongly that this absolutely needs to be a one-time fee.
The idea of constructing an artificial service industry to maintain
an annual registration system for random numbers is plain wasteful.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Aug 2003 12:11:25 -0400

> I look forward to reading an ID describing a set of necessary (not 
> sufficient!) requirements fulfilled by scoped unicast addressing -
> i.e. the problems which cannot be solved by *any other* mechanism.

personally I'm not interested in having this group spend any time trying
to justify a "feature" which we already know is unworkable.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Aug 2003 09:27:43 -0700 (PDT)

> their alternative at about the same time.

This assumes that the consensus will be found
quickly for their replacement. I find that
*highly* dubious. The net result, IMO, will be
effectively ignoring the consensus in SF to
deprecate. Years passing before we publish the
deprecation document will effectively make it a
dead letter.

Oh, sigh me up for "A".

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Aug 2003 09:32:16 -0700 (PDT)

The few self-described apps people I've seen take
a stand have to my recollection been strongly
against dealing with locally scoped addresses .

Have I missed anybody? It seems to me that people
with strong app and/or host kernel background
ought to be given a disproportionate voice in the
consensus here as this is really their ox who's
being gored. 

	Mike

---

From: Naiming Shen <[email-masked]>
Date: Wed, 06 Aug 2003 10:15:09 -0700

A) for me, even though B) would be fine too.

thanks.
- Naiming

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Aug 2003 13:27:04 -0400

> - Application designers who want to work in the "end-to-end clean"
> Internet and who do  not care to support the corner cases should be
> able to do so.
> 
> - Finally, if a solution requires local addressing, and application
> writers want to  support it, there needs to be a standardized way to
> do this (which is why local  addresses must be defined and
> recognizable).

IMHO, the need for local addressing has not been established, and we
should not burden either hosts, apps, or networks with it in the absence
of strong justification.
--------------------------------------------------------------------
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: Michael Thomas <[email-masked]>
Date: Wed, 6 Aug 2003 10:46:10 -0700 (PDT)

> answer the question, convincingly to my mind.

The problem is that this draft proceedes from the
premise that the answer is consing up limited
range addresses. That's incorrect and not
helpful. We need to start by determining what the
*requirements* are, and only then outline what the
range of solutions are, and what their problems
and possible consequences are. Until we can get an
consensus on what we need to do, and what the
engineering tradeoffs are, we will never come to
closure.

That in a nutshell is why I have a problem with
the religiosity on both sides of this argument.

		Mike

---

From: Leif Johansson <[email-masked]>
Date: Wed, 06 Aug 2003 19:46:40 +0200

>to justify a "feature" which we already know is unworkable.
Individual submissions are free :-) I personally hold little interest 
aswell but that
is beside the point.

          MVH leifj

---

From: Leif Johansson <[email-masked]>
Date: Wed, 06 Aug 2003 19:48:31 +0200

>Have I missed anybody? It seems to me that people
That depends on whom you caught :-) I suspect lots of apps-folk
have tuned out in disgust by now :-( so you may indeed have missed
a few.

>consensus here as this is really their ox who's
Indeed.

       Cheers Leif

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 11:44:00 -0700

Hans Kruse wrote:
> reasonably possible, it  should be used.  

No, we do not all agree. See below.

> With the defaults above, the 

While I appreciate your goal of compromise here, the insistance of avoiding
the local prefix is short-sighted. In particular it overlooks the point that
during an ISP prefix change local application stability is only possible
using the local prefix. If the default is to avoid the local prefix, every
local app will break on a prefix change, which is directly contradictory to
the goal of a smooth transition between ISPs. 

I think we should explicitly disallow a mismatch between local & global. In
addition, to achieve the use of globally routed in the non-local cases the
name resolution system needs to provide contextually appropriate answers.

> is why local  addresses must be defined and recognizable).

I agree there should be a way for apps to specify a preference for one or
the other. 

> work with the default behaviour suggested  above.

No, if applications in an intermittently connected network selected the
non-local prefix, and it went away or changed, they would need to drop and
reestablish the connection. Yes they could keep using the prefix as long as
it was still valid, but from a diagnostics and management perspective you
don't want a bunch of deprecated-but-still-valid prefixes running around for
communications that should always stay internal to this network. Also, in
some cases the application will want to run for longer than the valid time,
so even if that approach is taken local apps will break for no good reason.

> aware of the local/global address issue.

Why? Are you suggesting that a ship can't run a stock database
implementation? Yes specialty applications should be aware, but there is no
reason to preclude use of off-the-shelf configurations.

> enough.   Comment/Flame away.....

Not a flame, but one other issue; there is a security argument to be made
for defaulting to limited range addresses. If the default stance is limited
range, people would not be automatically exposing their system just by
installing an app. Of course the counter argument to security is
configuration simplicity, and making Joe-sixpack explicitly select the
exposure range is not particularly viable either. Getting back to your point
about api selection, should the default api be don't-care, or limited-only?
Using the current address selection rules for the don't-care case, the
behavior would be more stable for local apps but still exposed for global
reachability. If the default were local-only, the app, or sys-admin would
have to explicitly select when exposure happens. 

This is really a question about how much we really want to see hosts and
applications protect themselves ...

Tony

> Adjunct Associate Professor of Electrical Engineering and 
> Computer Science Ohio University, Athens, OH, 45701

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 11:51:31 -0700

Brian E Carpenter wrote:
> 3. I feel strongly that this absolutely needs to be a 
> one-time fee. The idea of constructing an artificial service 
> industry to maintain an annual registration system for random 
> numbers is plain wasteful.

Well a database with stale information is of no value either. There is a
recurring cost to running a useful database, we need to accept that and move
on. Bob's draft has a place for those that are willing to pay, and one for
those that are not. It may need more discussion about conflict resolution in
the random space pointing to the registry, or noting that one or both sites
could rerun the algorithm to move when necessary, but it currently solves
both problem sets.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 11:58:16 -0700

> consensus here as this is really their ox who's

They do have a disproportionate voice, primarily because the operator of the
edge network (where these addresses would be used) is disenfranchised from
the IETF. Yes the ox of the app developer is being gored here, but the
alternative to a few in the middle is goring the masses at the edge. There
is nothing more here than simple cost/benefit analysis being done by one
side, rather than from the perspective of the system as a whole. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 12:15:51 -0700

Michael Thomas wrote:
> range addresses. 

It is not intended to. It is trying to point out the requirements that
network managers have. It uses examples where they have found limited range
addresses meet the need to explain it for those who don't believe their
requirements are real. 

> That's incorrect and not
> *requirements* are, 

That is the point of the draft. Unfortunately some on this list want to
argue that some requirements are not real, rather than accept that different
situations create different requirements. Given that not everyone has
expierenced every situation, the draft needs to provide enough context
around a requirement so that others can see the issue.

> and only then outline what the

Yes and no. There is no way to achieve a single optimal solution for the
diverse set of requirements, so we know the outcome will be a compromise.
Bob's draft (as did the others to randomize SL) meets the requirements in
the current draft.  

> the religiosity on both sides of this argument.

My religion is that the deploying network manger is right, no matter what
the IETF decides. If the IETF decides to provide tools to make deployment
easy, that will be the path of least resistance. If not, the network manager
will demand ad-hoc tools to get the job done.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Aug 2003 22:28:22 +0300 (EEST)

> well, we don't say that hosts should block them.

IMHO that would the wrong thing to do.  The hosts should not care whether 
the prefix they're autoconfiguring from is from 2002::/16 or some other 
block.  They don't implement 6to4, so making them care would seem like a 
layer violation.

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Aug 2003 15:39:52 -0400

> > >    unique 32-bit IPv4 address, referred to in this document as
> > >    V4ADDR. This address MUST be duly allocated to the site by an
> > >    address registry (possibly via a service provider) and it MUST
> > >    NOT be a private address [RFC 1918].
> > > 
> IMHO that would the wrong thing to do.  The hosts should not care
> whether the prefix they're autoconfiguring from is from 2002::/16 or
> some other block.  They don't implement 6to4, so making them care
> would seem like a layer violation.

things that make no sense should be filtered, just like packets sourced
from a broadcast address.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Aug 2003 12:46:55 -0700 (PDT)

> addresses meet the need to explain it for those who don't believe their

Tony, quit patronizing me and everybody else. I've
not seen one person here who is insensitive to the
actual needs of network managers. What I've seen
is differing opinions of how to weigh the
conflicts and most especially what the long term
implications are of any particular approach. Your
trying to frame these conversations as a one-man
crusade against the IETF ivory-tower is lame and
insulting.

Your draft is not helpful because it starts out
with a conclusion and works back from there, much
like yellowcake and WMD. The bias is in the title
of the draft, for gawd sake. What we really need
is something that lays out all of the requirements
-- and local scope is not a requirement, it's a
solution -- and tries to analyze the problem space
without bias to a particular solution; laying out
the good, bad and the ugly for each possible
approach.

 > That is the point of the draft.

It fails. See above.

 >  Unfortunately some on this list want to

And now your patronizing the group again. Stop it.
 
 > Bob's draft (as did the others to randomize SL) meets the requirements in

You mean the requirements of "do no harm wrt NAT
and DFZ route pollution?" Oh, golly, I guess I
didn't find those in the draft. Both of these
requirement are downsides of limited scope
addresses approach, btw.

 > will demand ad-hoc tools to get the job done.

Aside from the preposterous notion that you're the
torch bearer of the poor under represented network
manager (::snort::), this isn't helpful because
what we need here is to balance out the
conflicting requirements both in whose work load
is affected, as well as the general architecture
of the net. The network manager is *one* voice
that needs to be considered, not the *only* voice.

	   Mike

---

From: Leif Johansson <[email-masked]>
Date: Wed, 06 Aug 2003 22:15:15 +0200

>side, rather than from the perspective of the system as a whole. 

Yet another old argument. I remember several opposing voices from the SL 
debate.
I am running a large edge network. I have both PI and PA v4 and yet I 
don't see
the need for site-locals. I think it is time to drop the "silent 
majority" argument.

What edge-network do you run?

      Cheers Leif

---

From: Hans Kruse <[email-masked]>
Date: Wed, 06 Aug 2003 16:24:07 -0400

draft-hain-templin-ipv6-limitedrange-00.txt still needs work, and some 
requirements in the draft may need to be examined further, but there is 
enough there I think that creating the "hooks" does no harm, if an 
application does not have to implement the special handling by default.

---

From: Alain Durand <[email-masked]>
Date: Wed, 06 Aug 2003 13:34:50 -0700

>name resolution system needs to provide contextually appropriate answers.
You're asking the DNS views to be in sync with the routing views.
Possible to achieve at a cost if there is one local and one global view,
as it is current practise with two-fade DNS, but much harder
when you have n enterprise networks joining to create an extranet.
In any case, this is a layer violation.

- Alain.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 13:59:38 -0700

> Yet another old argument. I remember several opposing voices 

Appearing to be primarily from service providers. By my count most of the no
voters were from edge focused people. 

> the need for site-locals. 

So is all of your space is globally routed without any filtering or
exclusion from routing protocols? Not everyone is in such a lucky position
to have all of their network globally exposed.

> I think it is time to drop the "silent 
> majority" argument.
> 

Currently an insignificant one, but in past lives I have been involved in
both large scale edge and core network management. The point is not what you
or I think about the need for local addressing, it is about what the manager
who can't get PI space is going to do. Insufficient resources to justify PI
space does not invalidate their need for internal network stability. 

In the absence of NAT, allowing the ISPs to renumber customer networks at a
whim will ensure 'address-portability' becomes a hot button. We can help
mitigate what would become random PI by providing local stability. We can go
further by providing a 'less-than-perfect' PI. PI will solve most of the
requirements for local space, but by definition can't deal with the
requirement to avoid accidentally becoming part of a routed aggregate.

Tony

---

From: Geoff Huston <[email-masked]>
Date: Thu, 07 Aug 2003 07:00:44 +1000

>Three comments on your draft:

Thank you for reviewing the document

>that you don't like the birthday paradox risk, let's discuss it.

It is an individual document, as stated by listing only myself as the author.
It is not an RIR document, and it does not represent any RIR position.
As an individual IETF participant I have as much standing to comment
on the locally assigned random choice proposal as any other
individual, obviously.

The probability of a collision using random choice is not a paradox. Its
a simple calculation, using the formula as given in the document.

The observation is that even though the /8 space contains
1.1 trillion entries, there is a greater than 0.5 probability that there will
be a clash after some 1.2 million draws. Normally this would not matter in the
slightest, BUT the proposal also notes a potential to use these addresses
in the context of end point identifiers, and in such a case there is
a strict requirement for uniqueness, and my observation is that self-driven
random choice is inadequate. Its not a paradox risk. Its just the underlying
mathematics of random draw probabilities.

>the clearest instructions possible.

I honestly can't make any sense of these sentences. Could you please
rephrase it?

>with the idea of competing in the sale of random numbers.

It may be. It may not. But attempting to second guess anyone, as
you appear to be doing in your comment, without at least
allowing them the courtesy of consideration of the issues is not normally
considered a very wise course of action. So this document is
considering the issues and looking at the pros and cons of various
forms of distribution, and looking at an RIR perspective in
considering the implications of a central registry function of
such local use allocations. You'd prefer that this analysis was
done behind closed doors? I'd be tempted to guess that your
answer would be a 'no', but I'll avoid the temptation to second
guess you and leave it for you to answer.

>an annual registration system for random numbers is plain wasteful.

And the document considers this approach as well as others. Interestingly
enough there are other perspectives here to the one you've stated, and
there are pros and cons to each of them, and the document explores
some aspects of these considerations. You appear to offer the hint
here that its in some manner heretical behaviour to explore alternatives.
Again I'm tempted to guess that you do not mean it to sound  that way,
but once more I'll refrain :-)

Regards,

    Geoff

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 14:04:05 -0700

Alain Durand wrote:
> You're asking the DNS views to be in sync with the routing 
> views. Possible to achieve at a cost if there is one local 
> and one global view, as it is current practise with two-fade 
> DNS, but much harder when you have n enterprise networks 
> joining to create an extranet. In any case, this is a layer violation.

Yes, a layer violation which is in wide deployment and use today. Yes there
are technical issues which could be dealt with to make it work better, but
those won't happen as long as the IETF DNS community refuses to step up to
them.

Tony

---

From: Leif Johansson <[email-masked]>
Date: Wed, 06 Aug 2003 23:25:43 +0200

>to have all of their network globally exposed.
Of course we filter - but we don't NAT! And luck has nothing to do with 
it. Would
I like to be able to renumber and/or switch providers at the press of 
the button?
Maybe. Do I wan't to pay the price of not beeing able to run (say) sip 
to the end-
point? No way!

       Cheers Leif

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 14:49:14 -0700

Leif Johansson wrote:
> Of course we filter - 

What is your requirement to do that? I am serious, because those are the
things the current draft is trying to document. If it is not covered by the
current text, please send details.

> but we don't NAT! 

I never said NAT was a good thing, in fact I keep pointing out we will have
NAT if we don't give people stable local space to work with. Local stability
is more important than breaking a few applications people aren't using yet.

> And luck has nothing 
> to do with 
> the button?  Maybe. 

Some are more insistent about that ability.

> Do I wan't to pay the price of not beeing able to run 
> (say) sip 
> to the end-
> point? No way!

Good, we agree on something as a starting point. 

The limited range document is about identifying the requirements network
managers have which prevent flat global routing of every prefix. There is
nothing in there about requiring NAT. There is a suggestion that a parallel
effort be started to create a globally routed PI space, on the assumption
that some will try to pay to have the limited range addresses routed as a
proxy for the non-existent IPv6 PI. I personally think the IPv6 PI work
belongs in the IPv6 WG, but in the current political climate I can't see it
happening.

Tony

---

From: [email-masked]
Date: Thu, 07 Aug 2003 00:19:43 +0200 (CEST)

Citerat från Tony Hain <[email-masked]>:

> > views. 

> those won't happen as long as the IETF DNS community refuses to step up

Good solution. Lets move the problem somewhere else...

I think you are fighting a loosing battle. Even if there was something wrong 
with the way site locals were deprecated from IPv6 in terms of itty bitty 
details of procedure, do you honestly believe that bringing them "back" would 
prevent us (the site locals depreceators) from getting rid of them once again, 
by the book?

I think all that will be lost is precious time to work on a better solution 
because there is enough strong voices against site locals. Certainly enough for 
my interpretation of "rough consensus". Arguments for and against is repeating 
itself and that makes the likelihood of someone changing opinion smaller by the 
day. People are locked into their positions and in essence the consensus will 
remain IMHO. The only thing to change that is new evidence. None is appearing.

We can always bring site locals BACK into the standard at some later point if 
we realize that it actually was a good thing. But the apps people, the routing 
people, the ISP people, the edge people and a bunch of other people seems to 
think it is a very bad thing compared to living without it. 

It is much more difficult to change things once 100,000 people or a million 
people are using it compared to when 1000 people are using it. Are there 1000 
site local uses of IPv6 in the world today? 

I say, lets see if it really is a bad thing by trying to find a better solution 
and work with that for a while. If it turns out there are better solutions, 
everybody wins. If there aren't any, you were right and we bring site locals 
back into the picture and everybody wins.

IANA can sit on the necessary ranges until the end of time if required. It is 
always easier to ADD features in the future than to remove them. So lets get on 
with it.

---

From: Andrew White <[email-masked]>
Date: Thu, 07 Aug 2003 11:31:17 +1000

Unless I'm missing something, the 'apps' problem can be neatly divided into
two issues:

(1) If there are multiple addresses per node, then the application needs to
somehow iterate through the various src/dest combos until it finds one that
works.  If multiple ones would work, how does it choose the best combo?

(2) If there are filters in place, then addresses that work from one node
attached at one point may not work from a different node or a different
location.

If we agree to remove filters and have one address per node, then we can
continue to write simplistic apps.  If not, then applications need to use
techniques that allow them to cope with these issues.

Notice that if an application only creates connections using a single pair
of endpoints then (assuming no mobility) it only has to deal with issue #1. 
Issue #2 only comes into play when applications forward IP address to other
applications and expect them to keep working.  Sending DNS addresses instead
may be a solution for some applications.  Manual configuration is the other
option.

This discussion is only relevant to 'local' addresses in as much as local
addresses are one class of filtered address.  As soon as you introduce
filters you MUST consider #2, regardless of your address 'scope'.

Christian's point about apps not wanting to deal with scope ids to resolve
overlapping mutually ambiguous scopes is taken, but I think most of us agree
with that aspect.

Network ambiguity is largely irrelevant - the connection succeeds or it
doesn't (remember that most nodes have a unique interface id).  Rather,
ambiguity is a big bugbear for network merging.

-- 
Andrew White

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Aug 2003 22:22:00 -0400

> (1) If there are multiple addresses per node, then the application
> needs to somehow iterate through the various src/dest combos until it
> finds one that works.  If multiple ones would work, how does it choose
> the best combo?

iteration is often too slow, especially if there are lots of address
pairs and the default rules don't work well.

> (2) If there are filters in place, then addresses that work from one
> node attached at one point may not work from a different node or a
> different location.
> 
> If we agree to remove filters and have one address per node, then we
> can continue to write simplistic apps.  If not, then applications need
> to use techniques that allow them to cope with these issues.
> 
> Notice that if an application only creates connections using a single
> pair of endpoints then (assuming no mobility) it only has to deal with
> issue #1. Issue #2 only comes into play when applications forward IP
> address to other applications and expect them to keep working. 
> Sending DNS addresses instead may be a solution for some applications.

whether this works depends on both DNS configuration and the app.
it would be far better if the apps had a way of doing referrals that
didn't suffer the unreliability and delays of DNS and which wasn't
so sensitive to DNS (mis-) configuration.

> This discussion is only relevant to 'local' addresses in as much as
> local addresses are one class of filtered address.  As soon as you
> introduce filters you MUST consider #2, regardless of your address
> 'scope'.

local addresses are also ambiguous, which further complicates things.

> Network ambiguity is largely irrelevant - the connection succeeds or
> it doesn't (remember that most nodes have a unique interface id). 

timeouts take a long time, and the probability that an ambiguous address
is invalid is high.

Keith

---

From: Alain Durand <[email-masked]>
Date: Wed, 06 Aug 2003 22:14:09 -0700

There is one point you're missing.
When an apps cycle through the list of potential src/dst addresses,
it does not fail over from one to the other immediately, especially
when the destination is remote and ICMP unreachable message may or may 
not
be received. TCP time out kicks in and RFC1123 says that an app MUST 
wait
at least 3 minutes in SYN state before timing out
(of course not all TCP implementation implement this MUST)

Anyway, my point is that if this trial/error process of walking through
the list of possible destination before finding a correct one can be
extremely time consuming. So, if the "routing view" of the world
is not in sync with the "DNS view" of the world, unacceptable delays
may/will occur.

	- Alain.

On Wednesday, August 6, 2003, at 06:31  PM, Andrew White wrote:

> needs to
> node
> can
> pair
> local

---

From: Andrew White <[email-masked]>
Date: Thu, 07 Aug 2003 15:49:00 +1000

> is not in sync with the "DNS view" of the world, unacceptable delays

A fair comment.

Some workarounds (of varying levels of reasonableness):

(1) Make sure the DNS view (as seen by the application) is accurate.

(2) Try several 'likely' candidates in parallel.

(3) Have a good metric for picking 'likely' candidates.

This discussion of 'likeliness' moves us into the local vs global question.

Let's first assume that the application doesn't have special needs (like
address forwarding) and just wants a connection.  If special needs exist
then the app may need to cull the list of potential addresses to suit.

If we already have a working connection between two endpoints, that's a good
candidate.  Of course, this may require looking external to the application.

Ignoring this, what should we try first?  Well, matching prefixes is good,
since they are most likely to work.  The only other advice would be that
when connecting to and address we know is filtered to try to use another
equally filtered address (as they are both 'probably' in the same space). 
Failing that, if connecting to an address beyond what we know about, try to
use a similar address.  Which looks surprising like local-local, then
global-global (or try both at the same time).

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Aug 2003 09:01:32 +0200

>Some workarounds (of varying levels of reasonableness):
<snip>

Great. Come back with an ID and running code. This increasingly 
hypothetical
thread is fast approaching amateur night in layer 7.

       Cheers Leif

---

From: Aidan Williams <[email-masked]>
Date: Thu, 07 Aug 2003 17:09:11 +1000

Geoff Huston wrote:
 > > I can't see significant differences in process between globally
 > > unique local address allocation and a globally unique PI address
 > > allocation.
 >

OK, I can see how registries could have problems implementing
centrally assigned random allocation as described in the draft.
Is non-aggregable to registries and random selection inside those
blocks a feasible alternative?

A further comment: your document speaks positively of a rental service
model for local addresses with non-payment causing the block to return
to a pool.  With a local address block, can that be made to stick?
Having received an address allocation, where is the incentive to keep
paying?  Why not just default and keep using your "allocated"
address..  Given the random selection process, reuse is unlikely and
given that the address is local, noticable breakage is unlikely too.

- aidan

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Aug 2003 10:29:00 +0200

>current text, please send details.
There are obvious reasons for filtering as Bob Austin pointed out last 
night/this
morning (time-differentiated threads when you are wrapped-around is a 
nightmare :-) )

Our reasons are the typical ones - mostly protecting from various 
features in M$
software. An important point is that there are few hosts which are 
*only* local.
In my experience a local-only host (eg a database-server part of a 
N-tier application)
are comparatively rare. Using locally scoped addresses for those is just 
more work
than putting the damned thing behind a firewall and filtering everything.

Currently the largest set of locally scoped hosts in my network are 
phones. This is
in itself a major pain since I am unable to deploy sip-to-the edge to 
these phones
and consequently I am in the process of getting globally scoped 
addresses for these
hosts.

Right now I cannot find a single application where locally scoped 
addresses give
me anything worth the effort. Those are my 5 cents - since you asked for 
details :-)

    Cheers Leif

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Aug 2003 10:54:48 +0100

On Mon, Aug 04, 2003 at 05:53:14PM -0700, Michael Thomas wrote:
> possibly fatally. 

IPv6 NAT will be a reality.   NAT is one method of implementing policy 
that many organisations are using and will continue to use, whether for 
IPv4 or IPv6.   

However, currently many organisations, home networks, etc have no choice 
but to use NAT.   IPv6 gives choice, and that's what we should build on, 
so people choose IPv6 for its advantages, and use it in a way that allows 
those advantages to be realised (not crippled).   If some would rather use 
IPv6 with NAT, fine, but it's their loss (indeed they may as well stick 
with IPv4 and NAT :).

I don't feel it's productive (apart from filling mailboxes :) to have this 
WG getting into heavy religion about something we can't stop.   There are
significant challenges in providing the alternative to address the PI,
multihoming, etc requirements that Mike mentions, but let's not be under 
illusions that we can stop IPv6 NAT (whatever our beliefs about it) by 
any IETF decree.

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Aug 2003 11:03:42 +0100

My preference is A, then B, then C.

I also think we should keep the former site-local prefix IANA-reserved.

BTW Patrik - does this mean you're not a fan of the source/destination
address selection mechanism for IPv6?

Tim

On Tue, Aug 05, 2003 at 05:47:20AM +0200, Patrik Fältström wrote:
> >> I

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Aug 2003 12:03:46 +0200

I'll file this in the place where I put things that might need fixing
in RFC 3056 one of these years. Let's move on for now; we can argue about
the exact words when the time comes.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Aug 2003 11:10:43 +0100

> the value of Bob's proposal.

Best practice and standards consideration to make IPv6 renumbering less
painful than IPv4 would seem an ideal v6ops WG item.

It doesn't remove the need for PI, but it could help in the meantime.

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Aug 2003 11:13:53 +0100

Thirded, and agreed.   IPv6 or V6Ops though?

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Aug 2003 11:22:25 +0100

> filter FEC0://10 packets unless explicitly configured to do otherwise.

Actually while I agree with "A" I still want fec0::/10 available for me
to use in a community wireless network, until a better alternative comes
along - but of course I would have to "explicitly configure" that anyway.

My concern for Bob's draft for a large private network is that I
might prefer fec0::/10 than the "complexity" of registering 100+ non
aggregated GUSL-style prefixes.    

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Aug 2003 13:58:22 +0200

Well, here's my attempt at becoming flame bait :-)

I'm close to concluding that address scope is simply a bogus concept.

1. We've been arguing about it for years and have reached no sort of
consensus. That suggests to me that there is in fact no consensus to be
reached.

2. Apart from link-local, scope boundaries are ill-defined.
(What's a site? Is the whole of a corporate network a site? Is the DMZ
inside or outside the site? etc.)

3. We aren't clear whether we want scope because it maps security boundaries,
reachability boundaries, routing boundaries, QOS boundaries, administrative 
boundaries, funding boundaries, some other kinds of boundaries, or a 
combination.

4. There are some well known and important scope-breaking phenomena, such
as intermittently connected networks, mobile nodes, mobile networks, 
inter-domain VPNs, hosted networks, network merges and splits, etc.
Specifically, this means that scope *cannot* be mapped into concentric
circles such as a naive link/local/global model. Scopes overlap and
extend into one another. The scope relationship between two hosts may
even be different for different protocols.

5. In practice, scope is not explicit; it's implicit in firewall rules,
VPN setup, static routes, DNS entries, application level trickery, 
configuration files, and brains.

6. Middleware (a.k.a. Apps) has no idea how to handle scope anyway. 
In fact, given the above, I don't see how a useful API to express scope 
concepts could be defined. If we can't define such an API, we can forget
about expecting middleware to do anything sensible about scope.

So I don't believe that a scope field as part of the address format
is a meaningful idea, because I don't think scope is a single-
valued function in the first place.

I think we'd be better off to simply forget about address scope.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Aug 2003 14:52:55 +0200

> on the locally assigned random choice proposal as any other

Of course. But some of the phrasing suggested to me, perhaps falsely,
that you were thinking of processing this draft via the RIRs. There may 
certainly be RIR issues later on, but for now the IETF seems the right forum.
(so, in answer to your earlier question, this could become an I-D, or we
can enrol you as an experimental SIR and call it a SIR review.)

> a simple calculation, using the formula as given in the document.

Well, the birthday paradox isn't really a paradox either.
> mathematics of random draw probabilities.

The question is whether we think that risk is acceptable to an individual site.
The odds are much worse than would be acceptable in a cryptographic context,
but I don't think that is the right criterion. After all, whatever pseudo-random
value I use, you can copy and spoof anyway - that's a much greater risk than
random collision, even with millions of values in use.

> I honestly can't make any sense of these sentences. Could you please

Not sure. Let me try.

You argue that granting a monopoly over the assignment of unique
pseudo-random numbers against a small fee won't be found acceptable. 
I'm arguing that this is analagous to the thinking that led to the 
Green Paper, ICANN, and eventually to alternative TLD registries.
But I'm also arguing that random numbers won't generate the
kind of South Sea Bubble madness we saw around domain names, so
it should be easier to get to a non-profit solution for the public
good. And I'm agreeing with you that the IETF's role in this is limited
to setting technical boundary conditions, leaving IANA to solve
the non-technical issues.

> you appear to be doing in your comment, 

No. Your draft seemed to me to imply that the RIRs automatically have a 
role in this type of address space. I just want to say that isn't at
all obvious to me, and it isn't obvious to me that they'd even want
such a role.

> without at least
> considered a very wise course of action. 

I'd be amazed if the RIRs didn't consider them.

> So this document is
> done behind closed doors? 

No. I think it's actually a bit premature, since the IETF hasn't
decided if it wants to go this way, but it's much better discussed
in public (as the RIRs have done with many other issues).

> I'd be tempted to guess that your

What we're dealing with here is intrinsically a much simpler problem than
the RIRs had to solve for aggregatable address space when CIDR
arrived. There are very good reasons why routeable address space
allocation requires policies, justifications, and annual fees. I will take
a lot of convincing that we can't fund a one-time pseudo-random allocation
with a one-time fee. After all, if after a few years nobody applies for
numbers any more, the escrowed numbers can be saved on a CD and the
registry can close down, and there's no need for continued fees.

I'm really after a KISS solution here. Of course it isn't heretical
to discuss alternatives, but let's look for the simplest way that works.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 7 Aug 2003 09:20:25 -0400

binding scope to an address works about as well as binding QoS to an
address.  sure you can do it as a hack, and it's fairly easy for the
network to implement, but it's a royal pain for hosts and apps.

Keith

---

From: Zefram <[email-masked]>
Date: Thu, 7 Aug 2003 14:42:37 +0100

>I'm close to concluding that address scope is simply a bogus concept.

I find it not entirely bogus, but if it's to be part of the addressing
architecture then it needs to be handled *everywhere* that the addresses
are handled.  Apps that expect to represent an IPv6 address in 128 bits
fail when they are presented with an address where the 128 bits isn't
really the entire address.  Really, we can only have scope where we're
prepared to require every application to know about it.

Link-local scope works just fine in IPv6, because these addresses are
used only by very specialised programs (such as routing code within IPv6
stacks) that need to know about different links anyway and have no problem
attaching a link ID to each address.  The scope aspects of IPv6 multicast
similarly seem less troublesome, at least to me: it's so inherent in
the multicast addressing architecture that it really can't be ignored,
but the need to handle it is localised to programs that do multicast.

Where we really can't do scoping is in ordinary unicast addressing.
This needs to be kept as simple as possible for the application layer,
because it's going to be handled in simple ways whether we like it or not.
Few enough IPv4 applications cope with multiple addresses properly,
we'll be lucky if we have *that* done properly by IPv6 apps.

>configuration files, and brains.

Now here's one of the big problems.  IPv6 nodes don't have any way to talk
to each other about scopes.  Site-local addresses suffer from looking a
lot like global addresses in the way they are used.  I can imagine some
neat things that could be done if scoping (or, more generally, context
sensitivity in the interpretation of addresses) were a pervasive and
inherent part of unicast addressing -- but they require nodes to tell
each other about relationships between scopes, do address translations,
and so on.  IPv6 scopes just sit there: they don't *do* anything.
(Yes, I'm getting rather abstract here.)

>concepts could be defined.

I think the right language to express useful scope concepts doesn't
exist yet.

>I think we'd be better off to simply forget about address scope.

For this generation of network protocols, certainly.  I think proper
use of scoping requires an additional level of complexity that we're not
prepared for (and, institutionally, the IETF can't really comprehend).
The ways of using scope that I imagine require that scoping is used
solely as an implementation technique, and that the network layer
provide to higher layers (both apps and humans) the illusion of stable
global identifiers.  For now I think the right approach is to provide
globally-scoped identifiers and work on the stability problem from
several angles.

-zefram

---

From: "Nir Arad" <[email-masked]>
Date: Thu, 7 Aug 2003 17:15:53 +0200

My comments inline.

-- Nir Arad

> consensus. That suggests to me that there is in fact no consensus to be

<narad>
I disagree. I think that there are several consensus that were reached:

1. Site-local addresses, as currently defined, are bad.
Hence the WG concensus to deprecate.

2. Many people think that scoped addresses are required.
I conclude this from the fact that draft-hinden was accepted as a WG item.
Indeed, some people think they are not, but even they can't claim that no-one thinks it is required.
As Voltaire said, "I may disagree with what you have to say, but I shall defend, to the death, your right to say it."
</narad>

> inside or outside the site? etc.)

<narad>
At this point I completely agree with you.
However, I still beleive that we can reach a better definition.
My personal opinion is to have link-local, global, and keep all other scopes as administrative.

If you return to my suggestion, that the source and destination addresses MUST belong to the same scope,
it is clear that a DMZ must have a global address to communicate with the rest of the world.
</narad>

> boundaries, funding boundaries, some other kinds of boundaries, or a

<narad>
This is a very good point.
I think that for each definition of scope you will give, there will be 5 or more people in this WG to embrace it, and 20
against.
My personal stand is that we should not take a stand.
Let administrators define this as they wish.
</narad>

> even be different for different protocols.

<narad>
Again, only my 2 cents:
Those overlaps and extensions are The source of all evil.

Per my suggestion, when two sites merge, instead of routing from one scope to another, I would like to see all hosts in
the merged network get a second address, in a new, shared scope. The old scopes of both networks can be kept for a long
time, or even forever, so existing applications/session are not broken.
I think we (the WG) should work to make sure that the allocation of additional addresses is made simple, and not shout
right away that this is an administrative nightmare and thus is not acceptable.
</narad>

> configuration files, and brains.

<narad>
This is correct in IPv4.
IPv6 can still be a whole new world. Scopes should become explicit.
As one of my co-workers always say: "Keep it simple!"
</narad>

> about expecting middleware to do anything sensible about scope.

<narad>
Trying to fully respond to that here would be hasty of me, so I'll avoid that.

Nevertheless, it seems that there is some level of concensus that applications should permit a minimal level of
selection between global addresses and "other" addresses (whatever those end up to be).
I think this would be enough to come up with a solution according to my suggestion.
But this is work to be done, and not a reason to dismiss an idea.
</narad>

> I think we'd be better off to simply forget about address scope.

<narad>
Thanks for the detailed response - no flames from my side...
</narad>

---

From: "Nir Arad" <[email-masked]>
Date: Thu, 7 Aug 2003 17:41:32 +0200

As things stand today, you are right - "Scope" becomes only another factor in the routing decision of a packet.

However, if we make it more explicit, and allow communication only among addresses at the same scope, I don't see it as
such a pain to hosts and apps. Address selection is not to complex (not as simple as "everyone have a global address",
but far simpler than what we have now).

Could you be more specific?

-- Nir Arad

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 7 Aug 2003 16:48:32 +0200

> address selection mechanism for IPv6?

To be honest, I have concentrated on looking at the problem which Brian 
touched on. Say you have some application which is to send an email to 
[email-masked]. Today, one look up MX for ecs.soton.ac.uk and sort 
them. Then A RR is looked up, and for each result set you try the IP 
addresses in order.

Now when having IPv6 as well, one have to look for A and AAAA RR. This 
makes things even more complicated, and the same problem exists for 
every protocol which have such indirection (NS, MX, SRV,... record 
types) which will over time be _all_ protocols. Simply because we need 
the indirection.

Now, if we on top of this have scoped addresses of any kind in IPv6, 
which forces the _application_ (on top of transport layer) to select 
"the best address"... That I definitely do NOT like.

What is acceptable for me is some algorithm which still make it 
possible for an application to do:

    data = gethostbyname(hostname,service);
    socket = bind(data);
    fd = open(socket);

Well, in principle, and the calls doesn't have to be named exactly 
that. BUT, my point is that I don't care what the gethostbyname or bind 
or open call do. That should be invisible for the application. What I 
have heard IPv6 people asking me as an application developer is to 
suddenly change this pretty simple algorithm to do something more 
complicated. And, when I talk with people like Itojun which implements 
these black boxes (I only write the gethostbyname equivalent above) he 
strongly as you all saw argues as well for [A] because doing scoped 
addresses of any kind in what I call "black boxes" is not possible.

That is evidence enough for me.

Don't know if I answer your question though ;-)

      paf

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Aug 2003 20:09:21 +0300

> random collision, even with millions of values in use.

I've been working on implementing IPv6 for multi-access capable cell
phones. The number game gets rather different if you start with the
assumption of maybe 1 billion multi-access terminals deployed world-wide
within the next few years. This quickly leads to the conclusion that
anything not guaranteed to be unique must be treated as ambiguous.
Unless uniqueness can be guaranteed, I don't see a way around the
requirement of having a fully scoped IPv6 implementation in these
terminals. Any host operating system that tries to enable users to take
full advantage of wireless connectivity will be faced with the same
dilemma. Ditto application developers.

	MikaL

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Aug 2003 10:26:57 -0700

Leif Johansson wrote:
> Tony Hain wrote:
> 
> >Leif Johansson wrote:
> >  
> >
> >>Of course we filter -
> >>    
> >>
> >
> >What is your requirement to do that? I am serious, because those are 
> >the things the current draft is trying to document. If it is not 
> >covered by the current text, please send details.
> >  
> >
> software. 

Not that all are well implemented, but in general those features are there
to make it usable for the technically challenged consumer. 

> An important point is that there are few hosts which are 
> *only* local.

For you as a technically astute network admin, I would agree. For
Joe-sixpack who just wants to keep the neighbor kid from messing with his
light switches, or to keep the junk-fax marketing company from finding his
printer, it is a different story. 

> and consequently I am in the process of getting globally scoped 

Let's be crisp with the terms here. Since you say SIP doesn't work, I take
it to mean those are ambiguous addresses. Even if you assigned globally
unique addresses to them, would you be filtering that address range at the
border?

> me anything worth the effort. Those are my 5 cents - since 

Wait, you started off by saying that you really need to filter and keep some
addresses local use, but then turn around and say you don't have any
application for that. Which is it? We agree there is no need for you to have
ambiguous addresses, but you appear to have a requirement for range limited
addresses because you intentionally filter. Getting back to the question, is
not trusting the hosts the requirement?

Tony

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 08 Aug 2003 03:42:53 +0900

>>>>> On Thu, 07 Aug 2003 13:58:22 +0200, 
>>>>> Brian E Carpenter <[email-masked]> said:

> valued function in the first place.

(I'm just wondering) What exactly are you proposing, if you are
anything?  Are you saying we should deprecate the "scop" filed of IPv6
multicast addresses?

					JINMEI, Tatuya

---

From: Hans Kruse <[email-masked]>
Date: Thu, 07 Aug 2003 15:25:23 -0400

Mika,

that application seems to scream for "real", i.e. provider-assigned 
globally unique addresses -- I don't think this is where limited range 
("local") addresses should be used?

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 07 Aug 2003 15:37:05 -0400

>not trusting the hosts the requirement?

"Range limited addresses" could mean two things here:  (1) Addresses
that inherently have limited range, or (2) Addresses that effectively
have a limited range, because the entire address is filtered at some
boundary.

There is also a third alternative...  Port/Address filtering.  It may
be that a particular address has limited range on some ports, and is
globally accessible on other.

So the fact that someone uses filtering does not necessarily imply
that they have a need for addresses that inherently have limited
range.

Margaret

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Aug 2003 22:21:55 +0200

> that they have a need for addresses that inherently have limited

I was just about to draft a reply when I read this excellent one. This 
is exactly
the point I was trying to make.

       Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Aug 2003 22:30:31 +0200

>printer, it is a different story. 
That is a matter of configuration mgmt (guis etc etc) not a question of 
how the
filtering is done.

>unique addresses to them, would you be filtering that address range at the
Nope! The rest of the mail was nicely covered by Margret W.

       Cheers Leif

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Aug 2003 13:40:48 -0700

Margaret Wasserman wrote:
> > > addresses give me anything worth the effort. Those are my 
> 5 cents - 
> > > since you asked for
> > > details :-)
> >
> >Wait, you started off by saying that you really need to 
> filter and keep 
> >some addresses local use, but then turn around and say you 
> don't have 
> >any application for that. Which is it? We agree there is no need for 
> >you to have ambiguous addresses, but you appear to have a 
> requirement 
> >for range limited addresses because you intentionally 
> filter. Getting 
> >back to the question, is not trusting the hosts the requirement?
> 
> "Range limited addresses" could mean two things here:  (1) 
> Addresses that inherently have limited range, or (2) 
> Addresses that effectively have a limited range, because the 
> entire address is filtered at some boundary.

With that choice of terms, the only way to create (1) is to predefine
boundaries for network managers. Since that is not something the IETF can
do, the only useful meaning is (2). Is the distinction you are trying to
describe is automated vs. manual filtering ??? When the goal is automated, a
'well-known' prefix simplifies the boundary device implemention. 

> 
> There is also a third alternative...  Port/Address filtering. 
>  It may be that a particular address has limited range on 
> some ports, and is globally accessible on other.

See the thread: Multi-homing (was ......]]) for why port filtering is not
viable in a consumer environment. It is much simpler to have each host take
care of its own global/local accessability than it is to get it right in a
remote edge box (witness regular configuration failures by trained IT
professionals). The multi-app case is also easier to deal with if there is
an obvious differentiation in the address for each app to bind to. Yes that
means apps should be halfway intelligent, but it they choose not to be the
worst that happens is delay.

> 
> So the fact that someone uses filtering does not necessarily 
> imply that they have a need for addresses that inherently 
> have limited range.

Assuming 'inherently' means 'well-known', yes it is true that manually
configured filtering does not *require* a well-known prefix. It is also true
that automation is required for consumers. Just because it is possible to do
manual filtering doesn't invalidate the requirement for automated
simplicity. 

We need to stop propagating the idea that requirements are invalid when -
'if the user was educated they would just do it my way, and they aren't
educated so they shouldn't be doing it'. By definition consumers will not be
technically educated, so approaches that work in a large managed network
will simply fail. They need something as simple as; light switches by
default are only accessible internal to the home,  but if say the front
porch light needs to be exposed they can explicitly configure it to be
global. 

Technically they could (A) go to a border router and block the light-switch
port, then figure out which address the front porch light had and allow it
to pass, or (B) they could buy a box that filters a local range prefix, and
a light switch that the ability to configure an additional prefix for global
access. (A) requires them to know technical details whenever any new
appliance/app comes out, and get an IPv6 address configured (without typo's)
into a border device. (B) requires the light switch vendor to provide a
configuration of limited-range by default, with a mechanism to add a global
prefix when required.

In other words, (A) puts the cost on the consumer, while (B) puts the cost
on the app developer. Since the consumer will always go for the lowest cost,
and the app developer has the technical capability to figure out automation,
(B) will always win in an open market contest between the two. Unfortunately
the IETF is overpopulated by app developers looking to move the cost out of
their scope. While many are complaining that putting the cost in the app is
too painful, the alternative is putting the cost on the end consumer. That
is even more painful, and aligned with the point where the financial
decisions are made. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Aug 2003 15:01:03 -0700

Brian E Carpenter wrote:
> 1. We've been arguing about it for years and have reached no 
> sort of consensus. That suggests to me that there is in fact 
> no consensus to be reached.
> 
> (What's a site? Is the whole of a corporate network a site? 
> Is the DMZ inside or outside the site? etc.)

We intentionally don't define the boundaries of an area in an IGP, so why do
we need to do so here? Of all the arguments about scope, this one is the
most bogus.

> 
> 3. We aren't clear whether we want scope because it maps 
> security boundaries, reachability boundaries, routing 
> boundaries, QOS boundaries, administrative 

That is because these are all local decisions, and the IETF can't dictate
where any one of them might be. All we can do is provide the tools for the
implementers of those boundaries to make the job easier.

> 
> 4. There are some well known and important scope-breaking 
> phenomena, such as intermittently connected networks, mobile 
> nodes, mobile networks, 
> inter-domain VPNs, hosted networks, network merges and 
> splits, etc. Specifically, this means that scope *cannot* be 
> mapped into concentric circles such as a naive 
> link/local/global model. 

Well, I have to disagree with this. 

> Scopes overlap and extend into one another. 

No, a link must be wholly contained within a site, and by definition
anything that is less than global fits wholly within global. Yes multiple
local regions can overlap, but that does not invalidate the overall model.

> The scope relationship between two hosts may even be 
> different for different protocols.

There is nothing inherently wrong with that. The file mount on likely wants
to be restricted, while a 3party conf app on the same hosts would likely
want to avoid being restricted. From an improving the overall Internet
security perspective, I think the default case should be restricted, then
provide a hook to get around that when appropriate. 

> 
> 5. In practice, scope is not explicit; it's implicit in 
> firewall rules, VPN setup, static routes, DNS entries, 
> application level trickery, 

The logical endpoint of your argument is to abolish brains ...

> concepts could be defined. If we can't define such an API, we 
> can forget about expecting middleware to do anything sensible 
> about scope.

I agree with the last sentence, but not the premise about defining an API.
One way to describe a desired outcome would be, bind to a limited range
address associated with ibm.com. 

> 
> So I don't believe that a scope field as part of the address 
> format is a meaningful idea, because I don't think scope is a 
> single- valued function in the first place.

I assume you mean a way to identify > link but < global. While there might
not be clear contiguous boundaries for each of the values in that space,
they can all be described as a single value for 'something inbetween'. 

> I think we'd be better off to simply forget about address scope.

We could choose to ignore the most commonly deployed segment of the existing
Internet, but how useful would the results be.

Tony

> 
>    Brian
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - Brian E Carpenter 
> > Having a Scope field in unicast addresses seems (to me) to solve 
> > all-so-many problems. I would go further to allow nodes to 
> only send, 
> > receive and forward packets from- and to- the same scope.
> > 
> > Being still on the IPv6 learning curve I might well be 
> wrong, but it 
> > seems to me the silver bullet for:
> > - Killing NAT ("site local" interfaces, whether globally 
> unique or not, may never communicate with global unicast
> > interfaces)
> > Coming from a router design point-of-view, the current address 
> > architecture, and more important, the forseeable and unforseeable 
> > changes within it, make it difficult to desgin a mechanism that 
> > identifies the source/destination address scopes.
> > 
> > > replace all current local addresses with a single type of local 
> > > addresses with a Range or Scope field like the multicast 
> addresses. 
> > > It would looks more consistent, more flexible, more scalable, and 
> > > could even help the WG move the current situation forward more 
> > > smoothly and smartly.
> > >

---

From: [email-masked]
Date: Fri, 08 Aug 2003 00:27:17 +0200 (CEST)

> configuration of limited-range by default, with a mechanism to add a

You are assuming that there is only one boundary in that consumers house. I can 
assure you that the teenage daugther or son in that house will have a 
completely different opinion on who's got the right to access what light 
control in her or his room. Particularly if there is a brother or sister in the 
next room. 

How will you solve that kind of access control, one site local from another 
within the same site? Buy one filtering box for each room? 

You should not assume that there is an entity small enough to be called "site". 
There are many sites within a site, each with different access requirements. 
Some unique, some shared, and it varies over time.

For example, how will you solve the neighbours access to the controls while the 
family is on vacation. That is two sites that needs to be merged over the 
Internet for some duration of time. That neighbours master control point in an 
identical apartment must be able to turn on and off the exact same light 
switches in two different homes, both using site local addresses? But of 
course, the neighbour can't have access to all controls. The light in the safe 
is restricted. And the teenagers room...

Your filtering devices, it seems, needs to be able to do quite a lot more than 
just differentiate between "site" local and global addresses. 

Maybe that is only possible if all light switches are able to have global 
access and unique addresses? 
--------------------------------------------------------------------
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: Eliot Lear <[email-masked]>
Date: Thu, 07 Aug 2003 15:27:13 -0700

> porch light needs to be exposed they can explicitly configure it to be

Once again, Tony, you are putting forth a security solution that is not 
secure.  You cannot *ARCHITECT* security into a protocol based on an IP 
address.  It is one thing for the customers to do that- they *may* know 
their environments.  As we have seen with all sorts of spyware and 
viruses, they probably do not.  It's thus even worse when you architect 
a standard based on what are false assumptions today and are likely to 
be false assumptions in the future.

The solution to the problem you have raised is a standard enrollment 
protocol that is invoked between an element and a security management 
tool.  That tool itself must be made user friendly.  You're trying to 
solve the problem at the wrong level.  Leave the IP address out of the 
argument.

Eliot

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Aug 2003 15:53:27 -0700

Eliot Lear wrote:
> > configured filtering does not *require* a well-known prefix. It is 
> > also true that automation is required for consumers. Just 
> because it 
> > is possible to do manual filtering doesn't invalidate the 
> requirement 
> > for automated simplicity.
> > 
> > We need to stop propagating the idea that requirements are invalid 
> > when - 'if the user was educated they would just do it my way, and 
> > they aren't educated so they shouldn't be doing it'. By definition 
> > consumers will not be technically educated, so approaches 
> that work in 
> > a large managed network will simply fail. They need something as 
> > simple as; light switches by default are only accessible 
> internal to 
> > the home,  but if say the front porch light needs to be 
> exposed they 
> > can explicitly configure it to be global.
> 

I don't see any content in this message. Like it or not, it is accepted
security practice to limit access by filtering on bits in the IP header, and
restricting what prefixes are announced in routing protocols. One set of
bits in the header is just as valid to filter on as another, though
addresses are easier to find and consistently exposed. In any case, I was
not even claiming that any packet filtering was happening in that scenario.
The presumption was that the prefix for local use was not being routed
outside the home, while the global one was. In that case, packet filtering
is not required as the origin can't get packets to the destination.
Restricted routing is just one component in a comprehensive security plan.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Aug 2003 16:05:08 -0700

[email-masked] wrote:
> You are assuming that there is only one boundary in that 
> consumers house. 

No, I am assuming there is at least one boundry between the consumer and
other networks. 

> I can 

Teenagers can go to work and buy their own boundary router if they choose.

> access and unique addresses? 

draft-hinden-ipv6-global-local-addr-02.txt creates unique addresses, even in
the case where the teenagers have independent boundary routers. Global
access is not generically necesssary or desired. To accomplish your neighbor
scenario, it would make more sense to put PA addresses on the specific
allowed devices than to have the whole network continually exposed to dos
attacks.

Tony

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Aug 2003 02:36:58 +0300

Hans,

The "application" is wireless connectivity to network XYZ, where the
network manager of network XYZ controls the choise of the address space
used. Multi-access basically stands for simultaneous access to multiple
different networks, possibly under different administration. I.e., the
terminal is effectively a host participating in multiple sites at the
same time. Since we can't control the network managers, we simply have
to assume that some of them will choose to use limited range addressing.

	MikaL

---

From: Mans Nilsson <[email-masked]>
Date: Fri, 8 Aug 2003 02:16:41 +0200

> allowed devices than to have the whole network continually exposed to dos

By forcing the end user to NAT and hide things behind a "broadband router" 
or similar device, you now give the attacker one convenient weak spot 
which, once attacked and brought to its knees, will deny every node in the 
house network service, especially since this box probably also
serves as switch, 802.11 access point, print server and whatnot..
Probably not what you wanted.

-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

over in west Philadelphia a puppy is vomiting ...

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Aug 2003 17:27:50 -0700

Mans Nilsson wrote:
> house network service, especially since this box probably 
> also serves as switch, 802.11 access point, print server and 
> whatnot.. Probably not what you wanted.

Who said I was forcing the end user behind a NAT, though I agree it creates
a single point of failure. There appears to be a lot of IPv4-centric
single-address-per-interface thinking going on in this thread. Just because
some nodes in a network are using addresses that are not globally routed
does not force other nodes to forego use of globally routed addresses. That
is the IPv4 model of the world. Multi-addressed IPv6 nodes can
simultaneously use limited range and globally routed addresses for different
destinations. 

Light switches, file mounts, printers, etc. should not by default be
globally exposed. If someone chooses to change the configuration, fine, but
forcing the 'managed enterprise network' model on the consumer will not
work.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Thu, 07 Aug 2003 17:35:45 -0700

Tony Hain wrote:
> I don't see any content in this message. 

I'll deal with this elsewhere.

> Like it or not, it is accepted
> restricting what prefixes are announced in routing protocols. 

But that filtering is done EXPLICITLY based on a PARTICULAR device in a 
PARTICULAR environment.  Neither the device nor the firewall can make 
that decision, and that is what you are claiming.  You are OVERLOADING 
security operations on the IP address, a construct that is poorly suited 
for the task.

> In any case, I was not even claiming that any packet filtering was happening in that scenario.

And that is where you are relying on the routing protocol for security, 
and that too is a bad architectural assumption.  It's bad for all the 
reasons I wrote in the message you claim had "no content".

> Restricted routing is just one component in a comprehensive security plan.

Since it doesn't really do the job, and since we are talking about a 
home system as a use scenario, less is more.  Provide a single mechanism 
that works correctly such that the individual can manipulate it in one 
place if he/she has to.

I don't claim that filtering shouldn't happen in many or most cases, and 
it might even happen in THIS case.  But let's not architect for such a case.

Eliot

---

From: Mans Nilsson <[email-masked]>
Date: Fri, 8 Aug 2003 02:42:50 +0200

> simultaneously use limited range and globally routed addresses for different

I fail to see why you need scoped addresses for this. When I want my printer 
to stay off the net, I remove the default route. Done. All the benefits of
site-local, and none of the scoping. Yes, it is reachable by UDP -- correct.
But it can neither reply, nor should it be connected to a network
if bad things happen when you give it UDP packets that it can't
reply to. The solutions for this, though, are grossly off-topic -- more 
appropriate work for those apps people who have left ipng believing 
that the SL ghost is gone for good and all is well.  

The only reason to have non-unique, unroutable addresses is if there was 
a shortage. Heck, people even claim that there is v4 space in abundance. 
How can then, pray tell, v6 benefit from it? 

I just remembered something about a TOAD!

---

From: Michael Mielke <[email-masked]>
Date: Thu, 7 Aug 2003 20:51:15 -0400 (EDT)

> allowed devices than to have the whole network continually exposed to dos

Is this telling us, that IPv6 is being introduced in more than just the 
internet.  like a replacement to phone numbers, for example.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Aug 2003 18:17:07 -0700

Eliot Lear wrote:
> > security practice to limit access by filtering on bits in the IP 
> > header, and restricting what prefixes are announced in routing 
> > protocols.
> 

No, I am using a well established construct of limiting access by
restricting where prefixes get routed, and limiting access by filtering on
header bit patterns. That is not overloading on the IP address any more than
current practice does. 

> > In any case, I was not even claiming that any packet filtering was 
> > happening in that scenario. The presumption was that the prefix for 
> > local use was not being routed outside the home, while the 
> global one 
> > was. In that case, packet filtering is not required as the origin 
> > can't get packets to the destination.
> 

Then why do network managers every have limitations on routing
announcements, both sent and heard? It is because they want to limit access.

> 
> > Restricted routing is just one component in a comprehensive 
> security 
> > plan.
> 
> Since it doesn't really do the job,

What job? Provide perfect security? If that is the case, what does the job
today? If such a product exists, why is route filtering so prevalent? 

>  and since we are talking about a 

There is nothing about providing a local use space that precludes a single
point of control. Architecturally requiring a single point of control
however precludes distribution and increasing scale. 

The network is not the simple Internet of 1990, and extrapolating that
growth forward says we must not be architecting in bottlenecks. Particularly
when they are simply based on favored operational practice of a few large
entities. The consumer doesn't want to know about the technology that makes
the Wal-mart appliance work, they just want to bring it home and turn it on.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Thu, 07 Aug 2003 19:00:02 -0700

> header bit patterns. That is not overloading on the IP address any more than

But we need no more than we have.  You are building an operating 
assumption around a bunch of bits in the address field that isn't safe. 
  People who use this today understand its limitations.  If you look at 
most of the home "routers", they have more of a notion of "inside" and 
"outside" interfaces.  Even the HOME router doesn't build an assumption 
along the lines you are discussing.  It doesn't look at the bits in the 
address field, other than to NAT permitted stuff through.

Now let's look at the enterprise case.  Unless you claim you are going 
to do away with the OTHER access-lists, then this is just another bit 
pattern for an ACL and there is no architectural need, and there is some 
peril as Michel has described.

> announcements, both sent and heard? It is because they want to limit access.

Mostly to protect the routing system itself.

> today? If such a product exists, why is route filtering so prevalent?

For all sorts of reasons:

1.  Protection of the routing system itself is the big one.
    a.  unwanted loops
    b.  unwanted accidental transit
    c.  malicious tampering with the routing system
2. And indeed people do not want advertised that which they want kept 
off the Internet.  Why invite the attack?  But it is as much as not 
having DNS information for an unreachable host behind a firewall.

> however precludes distribution and increasing scale.

I am not mandating any such thing.  I am saying that you are 
architecting toward a solution that is best solved elsewhere.  AND what 
we have works without such constructs - with two notable exceptions:

We do need to handle the disconnected and intermittenly connected 
network carefully and in a reasonable way.  Here I don't think we have 
good answers -- YET.  I do not wish to sweep this one under the rug.

And then there is the case of renumbering and managing networks through 
renumbers.  That's where Fred's stuff comes in.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Thu, 7 Aug 2003 22:38:56 -0400

> restricting where prefixes get routed, and limiting access by
> filtering on header bit patterns. That is not overloading on the IP
> address any more than current practice does. 

lots of stupid things are current practice.  NATs, for example.
trying to justify something that we know is harmful by citing
current practice isn't very convincing.
--------------------------------------------------------------------
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: [email-masked]
Date: Fri, 08 Aug 2003 05:01:51 +0200 (CEST)

> header bit patterns. That is not overloading on the IP address any more

Limiting access based on restricting where prefixes gets routed does not 
require a standards based scoped range of addresses. This can be done with any 
addresses. Therefore something called "site locals" are not required to 
continue to use prefix route filtering. 

> announcements, both sent and heard? It is because they want to limit

Do not confuse limit access (1) = prevent hacking, DoS attacks with limit 
access (2) = not provide a service.

Filtering on routes sent is commonplace to ensure that the route receiver gets 
a proper picture of the world and does not try to use the network to access 
things they shouldn't (transit for example). 

Filtering on routes received is commonplace to ensure that the next guy doesn't 
swamp your routingtable becasue somebody down the line screwed things up. Don't 
trust anybody elses routing.

Neither of these requires anything called "site locals". Both describe the 
primary use of route filtering. If somebody thereby also gains a bit of extra 
security because the next guy doesn't know about a certain prefix, fine. Site 
locals would add nothing here.

(1) is done with firewalls, packet filters, encrypted communications, secured 
operating systems and other such measures way before route-filtering.

> today? If such a product exists, why is route filtering so prevalent? 

Among who? You continue to talk about consumers and how things would be easier 
for them with site-locals. No consumers are using route filtering today. No 
consumers will need to use route filtering. 

ISPs use route filtering. People with corporate networks use route filtering. 
But they do it for the other reasones (see above), not for security. Thus "site 
locals" add nothing new.

> the Wal-mart appliance work, they just want to bring it home and turn it

Site-locals will not make consumer products any cheaper, easier or better. On 
the contrary, site locals will make them more complex, less interoperable and 
as a consequence more expensive to the consumer because he has to buy more of 
them to make things work!

Just look at NAT. How many different ways have been invented to go around NAT, 
to make applications work through NAT and to take advantage of things that are 
readily accepted through NAT and firewalls ("Lets run Protocol A over HTTP 
because it gets through everywhere...") just to avoid having to do a REAL 
solution?

That is application developer creativity working for you on network layer 
problems. And you want more of that??

---

From: Andrew White <[email-masked]>
Date: Fri, 08 Aug 2003 14:10:08 +1000

Leif Johansson wrote:
> hypothetical thread is fast approaching amateur night in layer 7.

3 hours programming and 200 lines of Java later I have a simplistic but
working library that attempts multiple (in fact all applicable) source and
destination pairs in parallel and returns the one that first works.

Adding necessary filtering to implement some form of address selection is
doable busy-work. It would also be quite plausible to delay acceptance long
enough to check if a certain pair worked before accepting another.

This discussion is increasingly degenerating into people who say "I refuse
to believe it would ever work or why someone would want to do it" and those
who can point to working deployment scenarios.

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 8 Aug 2003 06:24:49 +0200

> internet.  like a replacement to phone numbers, for example.

No, see RFC 2916.

Telephone numbers as in E.164 is acting at a completely different layer 
in the stack.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 8 Aug 2003 06:22:57 +0200

> forcing the 'managed enterprise network' model on the consumer will not

Whether an address is globally exposed or not is a management issue. It 
has absolutely _nothing_ to do with the addressing architecture.

     paf

---

From: Eliot Lear <[email-masked]>
Date: Thu, 07 Aug 2003 22:08:41 -0700

> who can point to working deployment scenarios.

The question isn't whether you *can* do it but whether it's a good and 
scalable approach.  There was code *before* this debate started.

Eliot

---

From: Leif Johansson <[email-masked]>
Date: Fri, 08 Aug 2003 08:08:00 +0200

>destination pairs in parallel and returns the one that first works.
Listen Andrew, I am sort of impressed by your tennacity (if that is the 
word I
am looking for) but writing a loop through a table does not quite 
constitute
"running code". You actually need to use this in an application and 
demonstrate
its utility on the Internet. My guess is that your application will be 
uselessly
slow when confronted with multiple choices to try if several of them are
unreachable. I look forward (sort of :-)) to hearing about your further 
explorations.

       Cheers Leif

---

From: Mark Smith <[email-masked]>
Date: 08 Aug 2003 15:59:40 +0930

Hi Nir,

I suggest you visit this page, which provides reasonable access to the
ipng mailing list achives.

http://marc.theaimsgroup.com/?l=ipng&r=1&w=2

Probably over the last two years, certainly over the last year, if there
is a dramatic jump in email traffic eg  around 200 one month to 600 or
more the next month, it is likely to be a discussion about site-local,
GUSL and every other possible variant within the "scoped addressing
theme".

October / November 2002 was one such occasion.

Most of your suggestions are likely to have come up.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Aug 2003 12:51:13 +0200

>                                         [email-masked]

No. I should have made it clear that I was talking strictly
about unicast. Scope for multicast is an entirely different matter,
and I assume it is needed.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Aug 2003 13:17:29 +0200

inline...

> we need to do so here? Of all the arguments about scope, this one is the

I'm not sure which way you intend this to be read. What I mean to say is that
I really cannot see a usefully defined generic category between link-local
and global; and I don't see the use of what you suggest later, i.e. such
a category with a fuzzy meaning. I don't know how to use it, since I don't
know what it contains or excludes. Point 3 is more explicit about that:
> where any one of them might be. 

Exactly. And these various boundaries will overlap in different ways
in different user networks - so the category "less than global scope"
doesn't provide any useful information.

> All we can do is provide the tools for the

Indeed. What I have come to believe is that a single-valued scope
function is not a useful tool for that.

> local regions can overlap, but that does not invalidate the overall model.

I think it does, because it makes "less than global" ambiguous. Does it mean
"my intranet", "my intranet plus a VPN to company X", "a VPN to company X
but not my intranet", "my VPNs to companies X and Y plus a secure subset
of my intranet", or a combinatorial number of similar choices?

> provide a hook to get around that when appropriate.

Yes. I don't see how a single-valued scope function helps with that.
> The logical endpoint of your argument is to abolish brains ...

Might help sometimes :-)
> address associated with ibm.com.

Indeed. Good example. It turns out to be a list of about 139 IPv4 prefixes,
manually maintained. I got that from my VPN setup. That's exactly the
problem.
> they can all be described as a single value for 'something inbetween'.

They can, but I've tried to argue above that this is useless.
> Internet, but how useful would the results be.

That's not what I'm suggesting. I'm suggesting that trying to solve it
with a simple concentric-circles model of scope is impossible.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Aug 2003 14:24:23 +0300 (EEST)

[...]
> forcing the 'managed enterprise network' model on the consumer will not

So, what exactly is wrong with the Bellovin/Zill Router Advertisement
option proposals which make it very easy for normally local-only
appliances to restrict the nodes they allow access from?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Aug 2003 13:52:54 +0200

If they do that, they will have ignored the health warnings
we will put on the RFC.

   Brian

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Aug 2003 17:38:36 +0300

> If they do that, they will have ignored the health warnings

Seeing as a good many of those networks will be residential, some of
those network managers very probably will not know about any health
warnings (having bought the zero configuration home gateway box and WLAN
base station from Wall Mart). What I wanted to point out, though, is
that network merging might not be the most common collision scenario by
a fair margin.

I would prefer it if the use of semi-unique local scope addresses were
restricted to non-connected networks. For any connected network you can
assume that the network manager is able go to some registry website and
grab a guaranteed unique prefix.

	MikaL

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Aug 2003 09:26:11 -0700

Pekka Savola wrote:
> So, what exactly is wrong with the Bellovin/Zill Router 
> Advertisement option proposals which make it very easy for 
> normally local-only appliances to restrict the nodes they 
> allow access from?

For the function it performs, nothing. What it lacks is a prefix space to
advertise that is not in any way associated with an aggregate that is being
announced in global routing. Fortunately that prefix space is available
using the Hinden draft.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Aug 2003 09:50:33 -0700

Brian E Carpenter wrote:
> > anything that is less than global fits wholly within global. Yes 
> > multiple local regions can overlap, but that does not 
> invalidate the 
> > overall model.
> 
> I think it does, because it makes "less than global" 
> ambiguous. Does it mean "my intranet", "my intranet plus a 
> VPN to company X", "a VPN to company X but not my intranet", 
> "my VPNs to companies X and Y plus a secure subset of my 
> intranet", or a combinatorial number of similar choices?

Why do you assume it needs a predefined meaning? I am approaching this from
the perspective that the local network manager defines what it means in
context. They do this all the time with routing areas, so why is a scope
context any different?

> ...
> > I agree with the last sentence, but not the premise about 
> defining an 
> > API. One way to describe a desired outcome would be, bind 
> to a limited 
> > range address associated with ibm.com.
> 
> Indeed. Good example. It turns out to be a list of about 139 
> IPv4 prefixes, manually maintained. I got that from my VPN 
> setup. That's exactly the problem.

So add sub-domains whenever there is a real difference in usefulness of any
prefix in the list (fwiw: I assume that the 139 are artifacts of history,
and there are probably less than 6 real groupings).  Since these are unique,
once the system has one it will be clear which interface or context it
should be used with.

> > We could choose to ignore the most commonly deployed segment of the 
> > existing Internet, but how useful would the results be.
> 
> That's not what I'm suggesting. I'm suggesting that trying to 
> solve it with a simple concentric-circles model of scope is 
> impossible.

I doubt it is impossible. More challenging than global flat routing? Yes,
but not impossible. 

In any case, I think the point you are bringing up is that truly global
routing is a rare exception, and the vast bulk of the environment lives in
the middle space. If so, I agree which leads to the question, why are we
trying to optimize the address space and api's around the least likely usage
scenario? I realize it makes app development simpler to assume the world is
flat, but if the bulk of reality says otherwise, shouldn't we acknowledge
that and bring app development into the 21st century?

Tony

---

From: Fred Templin <[email-masked]>
Date: Fri, 08 Aug 2003 10:39:14 -0700

Eliot,

Eliot Lear wrote:

> architecting toward a solution that is best solved elsewhere.  AND 
> what we have works without such constructs - with two notable exceptions:
>

In the interest of not seeing this swept under the rug as you say, let's 
discuss
the disconnected/intermittently-connected network case. We require stable
addressing for apps within such networks independent of what may be going
on with the provider point(s) of attachment. This seems to rule out 
provider-
assigned prefixes, since these are not portable and expire after extended
periods of disconnected operation. (Do you have a differing opinion on 
this?)

It seems to me that if the world were perfect, each "site" could procure its
own global prefixes independent of any provider and arrange to have the them
advertised into the global backbone by their current provider; even if 
they skip
around to different provider points of attachment from time to time. But, we
all know that this would lead to an immediate scaling issue for the 
global routing
table. If someone knows that a solution for scalable global routing in a 
flat address
space is close at hand, I wish they would speak up so that we could all 
get on with
the business of deploying it! Failing such, we seem to have limited 
range addressing
and "graceful" renumbering as alternative options. Perhaps there are 
others also?

> And then there is the case of renumbering and managing networks 
> through renumbers.  That's where Fred's stuff comes in.

Yes, but if you read the draft, the renumbering procedures Fred (Baker) 
describes
are anything *but* "graceful". I shudder at the prospect of "finding all 
the places"
(where addresses to be renumbered lurk)  in anything but the simplest of 
networks.
I'd sure like to hear Fred's perspective on this, however.

Fred
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Fri, 08 Aug 2003 10:50:54 -0700

> periods of disconnected operation. (Do you have a differing opinion on 

No and yes.  No, I think that given today's technology I believe we need 
stable addresses so that lack of connectivity does not cause internal 
transport connections to fail.  Yes, I wonder whether this could be 
sufficiently handled by minimum length leases that are retained for 
orders of months.

> 
> Failing such, we seem to have limited 
> range addressing

Yes: a default address, which is different from a limited range address.
The default address goes away when overriden.

> I'd sure like to hear Fred's perspective on this, however.

I think I've contributed some words to Fred's draft, at this point.  But 
this is where I would put my ernest efforts.  Getting from one prefix to 
another is indeed painful at this point and probably requires some 
protocol development here and there.  For instance, consider the NS 
record that is stored in the GTLD servers.  How does that get updated 
automatically?

Then there is the order of operations in terms of both internal and 
external DNS servers.  We need to see that authentication is widely 
implemented for DDNS (SIG(0) and such).

Eliot

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Aug 2003 11:11:12 -0700

Eliot Lear wrote:
> ...
>  No, I think that given today's technology I 
> believe we need 
> transport connections to fail.  

?!? 

> Yes, I wonder whether this could be 

This is a business model issue and out of scope.

> Yes: a default address, which is different from a limited 
> range address. The default address goes away when overriden.

Reconcile this with your first point. Maybe you don't care if a file mount
drops every time the SP provided prefix changes, but there are many business
critical applications where disruption is simply unacceptable. Just because
dropping connections is acceptable in one environment does not invalidate
the requirement for stable addresses in another environment.

> implemented for DDNS (SIG(0) and such).

DNS is the least of the concerns, because it is a 'centralized' database
that the network manager knows will need to be dealt with. The real problems
are all the places that addresses get stored by the end users, therefore out
of sight. You can say this is wrong and bad procedure, but it happens
regularly, and often for business critical reasons. Prefix overlap is the
best we are going to do in terms of renumbering, and that is still
unacceptable instability for internal-only applications. 

Tony

---

From: Eliot Lear <[email-masked]>
Date: Fri, 08 Aug 2003 12:09:48 -0700

Briefly (as I am short for time today):

> This is a business model issue and out of scope.

BCPs cover business model, but before we argue whether it's a business 
model problem -- because if that's all it is the market can decide, then 
let's at least understand just how far we can get with it technically. 
See below.

>>>and "graceful" renumbering as alternative options. Perhaps 
>>
>>there are 
>>
>>>others also?
>>

I think we have different notions of "change" here.  I don't see a need 
or a reason for an IP address to vanish like a routing update.  Instead, 
it should linger for some "reasonable" period of time first until some 
other prefix is preferred (and that might yet again be the default) and 
then be removed some time after that.

In answer to your first sentence, however, I do believe work needs to be 
done in this space.  It's not easy to renumber  -- yet (although it's a 
lot easier than it was 10 years ago).

> unacceptable instability for internal-only applications. 

First, I'd like to point out that even here there has been major 
improvement.  I sit here and type on a desktop that changes IP addresses 
routinely, and I am able to send and retrieve mail, as well as 
participate in interactive multimedia conversations.  Having said all 
that, I would agree that there remains a lot of work to be done.  I 
think a key component, though, is seeing that renumbering occurs 
smoothly with DNS and that DNS properly identifies those objects that 
need identifying.

Perhaps it's time to revisit the work done by the old PIER working group 
so that we can get some understanding of where these addresses still get 
burried.  This brings us back to Fred Baker's draft.

As to instability, I have to say that you can't know till we've tried 
and right now I don't really think we've done a good job of trying.  In 
today's world, given today's tools, I would agree with you that there is 
a lot of instability and using the IP address as a stable identifier is 
your only option.  So this is what network admins use -- not because 
they want to, but because they HAVE to.  If they WANTED to use this sort 
of identifier, DHCP and PPP would not be so popular.

So, I'd suggest that we continue to flesh out the renumbering procedures 
draft, looking for those hidden addresses.  I'd also suggest that until 
we've done that, we're going to go around in circles.

Eliot

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Aug 2003 12:52:30 -0700

Eliot Lear wrote:
> > Reconcile this with your first point. Maybe you don't care 
> if a file 
> > mount drops every time the SP provided prefix changes, but 
> there are 
> > many business critical applications where disruption is simply 
> > unacceptable. Just because dropping connections is 
> acceptable in one 
> > environment does not invalidate the requirement for stable 
> addresses 
> > in another environment.
> 

So how does the system work when a new app comes up while the initial one is
still running with the 'lingering' address? Does it take the new or the old
one? If new, how does it contact a node that is currently in the prefix
space of the lingering address, since the internal route will claim that is
still on link? For that matter, how do bits get routed to the 'lingering'
interface if the prefix has been moved in the routing system? What if the
lingering one is one of the apps that insists on passing the now stale
address to a 3rd party? I don't believe there are any realistic current
technologies that make this work. Your argument ammounts to making the
address stable for the duration of the app, but there is no way for the app
to tell the routing system how long it will need it. The requirement is for
applications to be stable, independent of what is happening at the SP
interconnect. Given TCP behavior, this leads to a requirement for address
stability.

> lot easier than it was 10 years ago).

Renumbering host interfaces is easier, but there is a lot more involved in a
renumbering scenario. While it arguably viable to renumber external prefixes
using the RA overlap technique, that is not sufficiently stable for
internal-use applications. If there is no space set aside for this purpose,
network managers will simply take a random number and use NAT. Business
critical stability will trump 'the good of the Internet' every time.

> ...
> > DNS is the least of the concerns, because it is a 'centralized' 
> > database that the network manager knows will need to be dealt with. 
> > The real problems are all the places that addresses get 
> stored by the 
> > end users, therefore out of sight. You can say this is 
> wrong and bad 
> > procedure, but it happens regularly, and often for business 
> critical 
> > reasons. Prefix overlap is the best we are going to do in terms of 
> > renumbering, and that is still unacceptable instability for 
> > internal-only applications.
> 

You are arguing that the capability of doing something within the context of
a single trust domain will translate into the interdomain space. While I
agree that an authenticated DDNS is a critical component, we are nowhere
near close to a scalable definition of that. Primarily due to lack of a
decent ubiquitous key infrastructure.

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Aug 2003 16:08:41 -0400

> internal-use applications. 

there is no justification for the idea that internal-use applications have a
greater need for stability than other applications.

actually, it's not clear that there is a significant class of inherently
"internal-use applications".  for most things that people put into that
category (e.g. printing, file access), there are significant and valid use
cases for running them across network boundaries.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Fri, 08 Aug 2003 22:30:22 +0200

>cases for running them across network boundaries.
Exactly. My experience as an edge-site operator is that there are few if 
any apps
which are only used internally.

       MVH leifj

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Aug 2003 14:07:52 -0700

Keith Moore wrote:
> there is no justification for the idea that internal-use 
> applications have a greater need for stability than other 
> applications.

Not in an academic environment, but when people's jobs are on the line they
tend to set the bar *much* higher. One example of an app that requires
stability is maintaining the multi-$M cash flow through the database backend
to a company's ecommerce app. The bar becomes 'did you do everything you
could with current technology to keep it running?' When the answer is 'no, I
could have put in a NAT to isolate those systems from any external prefix
change', what do you think will happen? It doesn't matter that the IETF said
'nat is bad & crashing applications during a renumber is not a problem',
they will do what they have to before they allow a failure.

> 
> actually, it's not clear that there is a significant class of 
> inherently "internal-use applications".  for most things that 
> people put into that category (e.g. printing, file access), 
> there are significant and valid use cases for running them 
> across network boundaries.

Running them across network boundaries does not invalidate the need for them
to be stable when run internally. It would be nice if people would stop
trying to invalidate someone else's requirements just because their own are
different.

Limited range prefixes do not solve all known problems. They simply solve a
subset of the existing problem space. Yes a single aggregatable PI address
would solve many of the same requirements, but not all. There will still be
a need for prefixes which are explicitly not routed, even accidentally as
part of some larger aggregate. 

fwiw: I have offered documents about a PI space on a couple of occasions,
but the chairs have not taken that up. I suspect part of that is due to the
multi-homing discussion being handed to multi6. As recent threads show, this
topic can't be isolated in an off-the-radar wg because it is the core of the
disagreement here. By definition all IPv6 interfaces are multi-homed, and
those that can reach off link have to deal with multiple scopes. Wishing
that there was a single flat globally routed address space is not going to
make it happen. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Aug 2003 18:00:45 -0400

> tend to set the bar *much* higher. 

(Should I counter with a comment about vendors that try to get their customers
to invest in shortsighted and inflexible solutions?)

> One example of an app that requires
> to a company's ecommerce app.

Lots of apps require stability.  The question is, are many of those apps
inherently confined to a particular subnet?  The answer is no.  Now, if
those apps are important enough and it turns out that you can make their
network more stable by putting them all in the same subnet, you might do so,
even if you have to do bridging, VPNs, or whatever to create that illusion. 
But you're only having to do that because the basic network technology didn't
meet your needs.

> The bar becomes 'did you do everything you
> change', what do you think will happen?  It doesn't matter that the IETF
> said'nat is bad & crashing applications during a renumber is not a problem',

Yup, they'll do so, until someone with a clue points out that the NATs are
actually causing failures and making the network harder to manage.  Then the
question will be "why did you install this technology which causes our
networks to be brittle and inflexible and our applications to fail?"

IETF's purpose is not to provide justification for shortsighted practices. 

> to be stable when run internally. 

Nor does it invalidate the need for them to be stable when running across a
network boundary.  What you seem to be saying is that (a) the "local apps that
need stable addresses" case is so compelling that we need to adopt a
solution which we know causes a lot of problems and (b) the requirements of
other apps for stable addresses are by comparison so unimportant that we
should delay working on that solution and meanwhile add special-case
complexity to solve the problem for purely local apps.

However if you can identify a significant class of apps that really is
inherently local and really has a greater need for address stability than
other apps, I can propose a solution to this problem with essentially no
impact to apps (especially those that don't need this extra stability), with
small impact to hosts and routers, and which doesn't impose the notion of a
single "local" scope either.  The reason I haven't proposed this yet is
because IMHO it doesn't solve the real problem (we need a reasonable degree of
address stability for ALL apps), it adds complexity that would be unnecessary
if the real problem were solved, and because it would distract energy from
efforts to solve the real problem.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Aug 2003 15:42:21 -0700

Keith Moore wrote:
> > Not in an academic environment, but when people's jobs are 
> on the line 
> > they tend to set the bar *much* higher.
> 
> (Should I counter with a comment about vendors that try to 
> get their customers to invest in shortsighted and inflexible 
> solutions?)

You won't even accept my agreement that academic networks have a 'lack of
need' in the same class as those with $M's at stake. 

> > stability is maintaining the multi-$M cash flow through the 
> database 
> > backend to a company's ecommerce app.
> 
> Lots of apps require stability.  The question is, are many of 
> those apps inherently confined to a particular subnet?  The 
> answer is no.  Now, if those apps are important enough and it 
> turns out that you can make their network more stable by 
> putting them all in the same subnet, you might do so, even if 
> you have to do bridging, VPNs, or whatever to create that illusion. 
> But you're only having to do that because the basic network 
> technology didn't meet your needs.

I never said this was confined to a particular subnet, just that the
addresses had to be stable independent of any events at the SP edge. I don't
understand the point of changing the scenario.

> > could with current technology to keep it running?' When the 
> answer is 
> > 'no, I could have put in a NAT to isolate those systems from any 
> > external prefix change', what do you think will happen?  It doesn't 
> > matter that the IETF said'nat is bad & crashing 
> applications during a 
> > renumber is not a problem', they will do what they have to 
> before they 
> > allow a failure.
> 
> Yup, they'll do so, until someone with a clue points out that 
> the NATs are actually causing failures and making the network 
> harder to manage.  Then the question will be "why did you 
> install this technology which causes our networks to be 
> brittle and inflexible and our applications to fail?"

That has happened, and the answer 'because it is the only current way to
preserve n$M incoming cash flow' will always beat out other application
failures. Give them a stable address independent of SP, and the arguments
about application failure have a chance.

> > Running them across network boundaries does not invalidate the need 
> > for them to be stable when run internally.
> 
> Nor does it invalidate the need for them to be stable when 
> running across a network boundary.  What you seem to be 
> saying is that (a) the "local apps that need stable 
> addresses" case is so compelling that we need to adopt a 
> solution which we know causes a lot of problems and (b) the 
> requirements of other apps for stable addresses are by 
> comparison so unimportant that we should delay working on 
> that solution and meanwhile add special-case complexity to 
> solve the problem for purely local apps.

I never said delay working on alternatives. In fact the part you cut off was
about the effort I have been putting in for awhile now. FUD like 'a lot of
problems' is causing more delay than anything else. The problems you have
raised in the past stem from multi-homing, so stop claiming that a limited
range prefix causes them.

> 
> However if you can identify a significant class of apps that 
> really is inherently local and really has a greater need for 
> address stability than other apps, I can propose a solution 
> to this problem with essentially no impact to apps 
> (especially those that don't need this extra stability), with 
> small impact to hosts and routers, and which doesn't impose 
> the notion of a single "local" scope either.  The reason I 
> haven't proposed this yet is because IMHO it doesn't solve 
> the real problem (we need a reasonable degree of address 
> stability for ALL apps), it adds complexity that would be 
> unnecessary if the real problem were solved, and because it 
> would distract energy from efforts to solve the real problem.

Which is the ultimate failure here, there is no single 'real problem'. The
limited-range document describes a set of requirements (read that: real
problems), and there are probably more. In keeping, there is no single 'real
solution'. Manual configured filtering of PA meets one set of needs,
auto-configuration of limited range prefixes meets another set of needs, PI
meets yet another set of needs, and these sets of needs all overlap in
different ways. Rather than persist with FUD to prevent one set of problems
from being solved, we need to get on with defining and deploying the
mechansims to solve each of them. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Aug 2003 19:03:56 -0400

> > > on the line  they tend to set the bar *much* higher.
> > 

You appear to be trying to make an implication that my arguments are specific
to, or focused on, academic networks, and so therefore are narrow and/or less
relevant.  You're wrong on both counts.

> > answer is no.  
> addresses had to be stable independent of any events at the SP edge. 

I think the requirement is better stated that apps (not just local apps)
continue to operate independent of any normal address change events, whether
or not at the SP edge.

> I don't understand the point of changing the scenario.

I don't understand the point of stating the scenario in narrow terms in order
to argue for a problematic solution with limited applicability.

> failures. 

except when those failures prevent that cash flow.

> I never said delay working on alternatives. 

No, but your insistence on SL is having that effect.

> The problems you have

I've raised lots of problems regarding scoped addresses, only some of which
have to do with multi-homing.  Since scoped addresses are being used to
justify forcing hosts and apps to rely on address selection (with its inherent
problems) to a much greater degree than would otherwise be necessary, it makes
sense to focus attention on the dubious assumptions behind scoped addresses.

> Which is the ultimate failure here, there is no single 'real problem'.

True enough - it's just a question on how large you want to draw the circle. 
The trick is to draw the circle in such a way that the solutions are
inexpensive and work well.  Usually this happens somewhere near (though not
precisely at) a complexity minimum.

> The

No, it doesn't follow.   What you suggest would be reasonable if the various
mechanisms were not too costly, did not conflict with one another, and did not
preclude development of better solutions.

But again, we can solve the local stability problem if there really is a
significant use case for it.  

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Aug 2003 16:38:34 -0700

Keith Moore wrote:
> ...
> I think the requirement is better stated that apps (not just 
> local apps) continue to operate independent of any normal 
> address change events, whether or not at the SP edge.

Nice goal, but requires changes to transport to pull it off. The point is to
deliver service long before that will happen.

> I don't understand the point of stating the scenario in 
> narrow terms in order to argue for a problematic solution 
> with limited applicability.

To bound the problem space to something that can be accomplished without
changes to transport. Yes it has limited applicability, but that is not a
failure, and the problems only arise when the mechanism is used outside the
scenario. For those cases, there are other mechanisms.

> No, but your insistence on SL is having that effect.

Clearly you are not reading the documents or the mail carefully. I am not
insisting on SL. The Hinden draft is not SL, and meets the requirements that
have been raised for limited-range.

> 
> > The problems you have
> > raised in the past stem from multi-homing, so stop claiming that a 
> > limited range prefix causes them.
> 
> I've raised lots of problems regarding scoped addresses, only 
> some of which have to do with multi-homing.  Since scoped 
> addresses are being used to justify forcing hosts and apps to 
> rely on address selection (with its inherent
> problems) to a much greater degree than would otherwise be 
> necessary, it makes sense to focus attention on the dubious 
> assumptions behind scoped addresses.

From my recollection, the ones that are not due to multi-homing are simply
wishes that filtering in the network would go away. 

> The trick is to draw the circle in such a way that the 
> solutions are inexpensive and work well.  Usually this 
> happens somewhere near (though not precisely at) a complexity minimum.

Again you are looking for a single solution ('the circle'). There are
multiple options here and they solve different problem sets. If we really
were forced to come up with a single solution, we will be back at nat as the
lowest common denominator.

> 
> > The
> > limited-range document describes a set of requirements (read that: 
> > real problems), and there are probably more. In keeping, 
> there is no 
> > single 'real solution'. Manual configured filtering of PA meets one 
> > set of needs, auto-configuration of limited range prefixes meets 
> > another set of needs, PI meets yet another set of needs, and these 
> > sets of needs all overlap in different ways. Rather than 
> persist with 
> > FUD to prevent one set of problems from being solved, we 
> need to get 
> > on with defining and deploying the mechansims to solve each of them.
> 
> mechanisms were not too costly, did not conflict with one 
> another, and did not preclude development of better solutions.

Nothing here conflicts with or prevents other solutions. The fact that a
limited range address space exists and is used in some networks does not at
all impact an individual network manager from using manual configuration
from a different prefix space. If a PI approach existed, it would not
preclude use (or meet the need) of another space that is known to be
excluded from the global routing tables. The only thing that is preventing
development of 'better' solutions is spending time trying to kill ones that
are achievable in realistic timeframes. If by some magic a killer solution
to all the problems showed up, it would easily push the complexity of
multiple solutions out of the market. We can't be sitting around waiting
until the magic happens. 

> 
> But again, we can solve the local stability problem if there 
> really is a significant use case for it.  

So solve the requirements and there will not be a need for other approaches.
Until then, this filibuster is delaying network managers from deploying IPv6
in a way that will meet their requirements.

Tony

---

From: Leif Johansson <[email-masked]>
Date: Sat, 09 Aug 2003 01:49:18 +0200

>need' in the same class as those with $M's at stake. 
You should spend some time in the academic world. In most countries the
academic institutions are essentially companies offering education and
research on a competitive market. There is not inherent difference and real
money is just as much at stake.

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Aug 2003 19:53:42 -0400

> deliver service long before that will happen.

every solution requires some changes.    the point is to find a deployable
path to a desirable end-state.  whatever solution we come up with, we're going
to have to live with for quite awhile.

> scenario. For those cases, there are other mechanisms.

Again, I don't see the inherent desirability of limiting change to transport
if it forces lots of pain on hosts, apps, and operations.

> have been raised for limited-range.

I don't buy the requirements you've cited for limited-range.  IMHO they still
presume too much.

> wishes that filtering in the network would go away. 

No, that's your interpretation of those arguments, and I've explained that on
more than one occasion.

> lowest common denominator.

There are lots of problems and lots of circles.  But so far I've seen no
compelling reason to separate the problem of providing address stability for
local apps from the problem of providing address stability in general. 
 
> > Rather than persist with FUD to prevent one set of problems from being
> > solved, we need to get on with defining and deploying the mechansims to
> > solve each of them.
> > 
> > No, it doesn't follow.   What you suggest would be reasonable 
> > if the various mechanisms were not too costly, did not conflict with one 
> Nothing here conflicts with or prevents other solutions. 

Anything that involves ambiguous addresses will cause problems. 
Anything that increases reliance on address selection will cause problems.
Anything that makes it easy for limited reach addresses to leak outside
of their routing scope will cause problems.
And the more different ways we have to provide address stability, the
more failure scenarios we're creating.

> in a way that will meet their requirements.

Well it's not clear that such requirements are valid. Somebody needs to make a
convincing case.

And even if one accepts the need for a separate local stability solution,
this still wouldn't necessarily justify ambiguous addresses or increased
reliance on address selection.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Aug 2003 17:58:37 -0700

> Anything that involves ambiguous addresses will cause problems. 

Please read
http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedrange-00.
txt and note there is no requirement for ambiguous addresses. Please read
http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-02.t
xt and note there are no ambiguous addresses defined. 

> Anything that increases reliance on address selection will 

Having more than one address requires address selection, therefore this
issue is with multi-homing, not a particular prefix.

> Anything that makes it easy for limited reach 
> addresses to leak outside of their routing scope will cause 
> problems. 

So ban applications from passing addresses. This has nothing to do with any
particular prefix, because it applies to all equally. Routing and access
filters are a reality and will not go away.

> And the more different ways we have to provide 
> address stability, the more failure scenarios we're creating.

I happen to see if from the glass-half-full perspective and note that we are
providing more solution scenarios. 

> > So solve the requirements and there will not be a need for other 
> > approaches. Until then, this filibuster is delaying network 
> managers 
> > from deploying IPv6 in a way that will meet their requirements.
> 
> Well it's not clear that such requirements are valid. 
> Somebody needs to make a convincing case.
> 
> And even if one accepts the need for a separate local 
> stability solution, this still wouldn't necessarily justify 
> ambiguous addresses or increased reliance on address selection.

Continuing to raise ambiguous addresses is simply creating FUD. The
requirements are valid to those that have them, independent of acceptance by
the IETF. The network manager will meet the requirements with the tools we
provide, even if that means using ones we wish they would not. Our only
recourse is to provide alternative tools that meet the requirements. 

Tony

---

From: Pekka Savola <[email-masked]>
Date: Sat, 9 Aug 2003 20:02:58 +0300 (EEST)

> announced in global routing. Fortunately that prefix space is available

Why exactly is advertising the aggregate a problem?  The nodes will filter 
out those sources they are auto-configured not to speak to before even 
seeing any maliscious packets.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Aug 2003 11:17:59 +0200

Mika,

> grab a guaranteed unique prefix.

Ideally, yes. But that doesn't solve all the real world problems - see 
the Hain/Templin draft.

   Brian

---

From: "Nir Arad" <[email-masked]>
Date: Sun, 10 Aug 2003 17:40:52 +0200

> > mathematics of random draw probabilities.

Actually, I believe we do not have a birthday paradox issue in this case.
The birthday paradox would exist only if ALL 1.2 million self-drawn prefixes would see each other.
However, in our scenario, the merging of two enterprises, only the two local prefixes may collide with each other.
They can not collide with the other 1.2 million or any other number of prefixes out there.
Thus, the probability remains 2^-40.

Regards,

-- Nir Arad

---

From: Mika Liljeberg <[email-masked]>
Date: 10 Aug 2003 18:32:20 +0300

> Ideally, yes. But that doesn't solve all the real world problems - see 

Which requirement are you referring to?

I don't see any requirement for (even slightly) ambiguous addresses,
aside from the case where it is, for whatever reason, not possible to
quickly acquire a guaranteed unique limited range address from a central
registry.

	MikaL

---

From: Eliot Lear <[email-masked]>
Date: Sun, 10 Aug 2003 12:26:58 -0700

If the sole purpose of these addresses is for layer 3 connectivity as 
envisioned for LOCAL USE, then I would agree with Nir Arad that we do 
not have a problem.  Stop reading here if that's your position.

If on the other hand, as Geoff states in his draft, and some people seem 
to be implying, that these addresses could be used as some sort of end 
point identifier outside of the routing system, then we do have a problem.

The reason this is an interesting problem is because these addresses 
have properties that would seem to align well with many people's idea of 
conceptually separate end point identifiers.  In particular:

  o  Statistical v. Administrative uniqueness
     -- see the NSRG draft

  o  Easy processing as a fixed size and at a (mostly) fixed point in
     the packet.

  o  Below the transport that could be used to maintain connections.

  o  non-aggregatability
     -- some would believe that since only a forward mapping is
     necessary there is no need for aggregatability, and that indeed
     one shouldn't allow these things to have properties of addresses
     in order to avoid overloading of functions.

A word of caution is in order.  It is just that overloading, however, 
that we are doing in the context of local connectivity.  And so for 
those who are considering this approach, you would be wise to consider a 
bit further as to the implications of that overloading.  In particular, 
ipv6.arpa issues should be considered as well as any *forward* mapping 
from this address to globally routable IPv6 addresses.

The problems with doing this, however, are well stated in Geoff's draft. 
    All of a sudden you are not simply interacting locally but more 
globally, and that means that for statistically "unique" values one 
should assume some collisions *will* occur (albeit rarely).

So in a peculiar sort of way, various efforts are converging towards 
very similar architectural properties but for somewhat different purposes.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Aug 2003 14:28:40 +0200

Eliot,

I kept reading, because if these things are created they *will*
certainly end up being used as end point identifiers. We have to invent
some multi6 solution quickly to prevent them also being NATted.

Unfortunately, this applies even if they are not created. Before RFC 1918,
lots of sites were configured with Net 1, because at least one vendor shipped
boxes configured for that by default. Similarly, IPv6 sites that can't get 
stable PA prefixes will configure *something* as a stable prefix, 
even if the IETF does nothing.

As for the locally-assigned pseudo-random variant of Hinden/Templin,
it carries a low risk of collision, which is why the centrally-assigned
option is there. I would advise my own employer to go for the
central solution, to avoid the minute risk of a collision. But the central
solution will take a while to set up, for reasons that Geoff has
documented. The local solution could be there in a hurry, by IANA action.
If I needed a limited-range prefix this week, I'd prefer that to nothing.

As I think I already said, if you want cryptographic assurance of identity,
an IPv6 prefix isn't the solution. They are too easily forged. That's
the real risk, not a random number collision.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Aug 2003 14:40:06 +0200

> context. They do this all the time with routing areas, so why is a scope

Quite correct. What I'm pushing back on is the idea that three levels
of scope (link, local, global) capture much of anything useful. If we were
talking about scope between say 0 and 255, where 0 means link, 255 means
global, and 1..254 are user defined, we might be able to define something
of value to enterprise network operators. But that is a whole new
ball game, and not something we can tackle as part of this debate IMHO.

> once the system has one it will be clear which interface or context it

Certainly it's less than 139, but I suspect (without bothering to check)
more like 10 real groupings. It's significantly more than one, in any case.
 
> that and bring app development into the 21st century?

Possibly, but it's hard, and I think we have to separate it from this debate.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Aug 2003 15:05:39 +0200

> quickly acquire a guaranteed unique limited range address from a central

Exactly! In that case, whatever the reason, a pseudo-random value with a
tiny probability of collision is a fine alternative. 

   Brian

---

From: Steven Blake <[email-masked]>
Date: 11 Aug 2003 10:38:00 -0400

> registry can close down, and there's no need for continued fees.

Why do the allocations have to be escrowed by the registry, instead of
the allocation recipients?  I can prove I possess an allocation by
producing a signed e-mail from the registry.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-9913

---

From: Eliot Lear <[email-masked]>
Date: Mon, 11 Aug 2003 09:48:35 -0700

Brian,

There is a major difference between now and 1994.  There should be no 
hurry for anyone to NAT IPv6.  If you're going to NAT IPv6 you might as 
well stay on IPv4.  What disturbs me most is this rush to fix something 
with a solution that would derail or delay other solutions simply 
because "better the devil you know".

Rather than argue the point further, however, I propose to work with 
Fred to help him develop the renumbering draft.

Eliot

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Aug 2003 20:23:35 +0300

> tiny probability of collision is a fine alternative.

You're a confusing person. First you disagree and then you agree. :)

	MikaL

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 11 Aug 2003 22:03:36 -0700

Leif Johansson wrote:
> slow when confronted with multiple choices to try if several 
> of them are unreachable. I look forward (sort of :-)) to 
> hearing about your further 
> explorations.

Uselessly slow is a local decision. If that is the case for your network,
then by all means, don't use these addresses. For others, speed is less of a
concern than other attributes. Please stop trying to force a single
operational model on everyone. We need to provide tools that meet the
requirements, not keep claiming the requirements are invalid.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 11 Aug 2003 22:03:36 -0700

Leif Johansson wrote:
> You should spend some time in the academic world. In most 
> countries the academic institutions are essentially companies 
> offering education and research on a competitive market. 
> There is not inherent difference and real money is just as 
> much at stake.

I have been in the R&E world, and no the level of need is not the same. Yes
academic institutions are businesses, and need sufficient stability to
maintain the cash flow. They are not funded to maintain stability necessary
to support a $4M/hr incoming cash flow rate. People tend to get really
paranoid when it is cheaper to hire a small army to replace you, than suffer
a 20 min outage. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 11 Aug 2003 22:03:36 -0700

> seeing any maliscious packets.

You clearly trust your filter configuration manager. Not everyone does, and
there is ample 'operational failure from typo' evidence to back up their
mistrust.

The point is that if there is no route, there is nothing that will need to
be filtered. The security paranoid will both remove routes, and install
filters, on the belief that failures will not occur in both at the same
time. Despite the noise about not providing security, these are two
mechanisms used in basic layered security models.

Tony

---

From: Geoff Huston <[email-masked]>
Date: Tue, 12 Aug 2003 15:27:54 +1000

>point identifier outside of the routing system, then we do have a problem.

That quote was a quote from the Hinden/Haberman draft

"These addresses are also candidates for end-to-end use in some
         classes of multihoming solutions."

The point I was trying to make was that if this was a serious objective, 
then there
was a valid case to be made for assured uniqueness in these addresses 
rather than
assumed statistically likely uniqueness, and if so then I felt that this 
was not
appropriate to use local self-assigned prefixes.

Geoff

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Aug 2003 16:31:46 +0930

On Mon, 11 Aug 2003 22:03:36 -0700
"Tony Hain" <[email-masked]> wrote:

> be filtered. 

True, but in my experience in a large, multi-departmental govenment network, is it fairly common that end user security / access requirements don't fall neatly along route / prefix boundaries. Typically this is because security has crept into the network, triggered by attachement to the Internet.

In government networks, route filtering is a useful tool to have, but mostly it is a "nice to use", because it is too blunt to facilitate the security / access requirements of the end users. 

Typically, the order of use of available network / transport layer security tools to meet common end-user requirements is :

(1) "application" level - ie. filter on TCP / UDP ports, possibly in combination with IPv4 source and / or destination address.
(2) network layer - filter IPv4 source and / or destination IPv4 adress.
(3) route filtering

Service providers, OTOH, protect their end-users by protecting the network itself. Route filtering is one of the primary tools for doing that, so (3) on my enterprise list is one of the (1)s on the service provider list.

Since IPv6 prefixes are going to be mapped along the same boundaries as IPv4 prefixes ie., layer 2 broadcast domains, IPv6 route filtering in an government network will be just as dull a tool as it is in IPv4. 

The security paranoid will both remove routes, and install
> mechanisms used in basic layered security models.

The security paranoid, at least in an government environment, would *like* to perform route filtering as part of a defense in depth strategy in addition to filtering, but end-user access requirements usually put an end to that idea.

Regards,
Mark.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 Aug 2003 09:04:45 +0200

>requirements, not keep claiming the requirements are invalid.
I am trying to lower my ranking so I only respond to select messages now 
:-) This
one qualifies.

The problem with your argument "use of local addresses is a local 
decision and is
does not affect anyone but you" is false. Address leakages will occur 
and in more
ways that you realise - stack and dns are *not* the only was an address 
can and *will*
travel.

       Cheers Leif

---

From: "Fredrik Nyman" <[email-masked]>
Date: Tue, 12 Aug 2003 11:19:10 +0200

> mechanisms used in basic layered security models.

Maybe the router vendor should develop appropriate tools to let the user 
verify that the filers work as expected and let it be up to the user to 
decide if he want to use the vendor with or the vendor without such tools 
and leave the flexibility in the design?

"Do you want subnet vault.acme.com announced to all the hackers out there 
[y/N]?"

-- 
Fredrik Nyman
PacketFront Sweden AB
http://www.packetfront.com/

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Aug 2003 10:51:12 -0400

> requirements, not keep claiming the requirements are invalid.

For applications to have a large market, there needs to be uniformity in how
networks operate.  Please stop trying to force application developes to cope
with dysfunctional networks.
--------------------------------------------------------------------
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: Fred Templin <[email-masked]>
Date: Tue, 12 Aug 2003 09:26:06 -0700

Keith,

Quick question - you have been nay-saying on local-use addressing for
as long as I can recall, but do you truly have an alternate proposal that
will work for intermittently-connected/disconnected sites, sites that
frequently change provider points of attachment, multi-homed sites,
etc? I asked others the same question and they mumbled something
about HIP but ducked my pointed questions as to how soon we could
expect to see an alternate proposal.

I'm trying to keep an open mind about this stuff, but I continue to see
nothing of substance coming from the anti local addressing camp. So,
unless there is some grand solution currently being architected in some
skunkworks project out of the public eye, are you really doing anything
more than just empolying stalling tactics? (And if there is such a stealth
mode project in the works, I think it high time that it be fully disclosed
to the community in good faith.)

Truly curious,

Fred
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Aug 2003 13:55:05 -0400

> as long as I can recall, but do you truly have an alternate proposal
> that will work for intermittently-connected/disconnected sites, 

disconnected sites - should use some sort of PI space - either
globally-unique or probably-unique

intermittently-connected sites with stable addresses - should use
PA space, even when disconnected.

nomadic sites, and intermittently-connected sites without stable
addresses - should use mobileIP externally.  I am working on a proposal
to allow them to use PI addresses internally without disrupting the
operation of applications.

multi-homed sites - this is being worked on by another group.  granted
it is a difficult problem.

> I'm trying to keep an open mind about this stuff, but I continue to
> see nothing of substance coming from the anti local addressing camp.

that's because a few people are still trying to push SL.  note that
SL doesn't "solve" the above problems either.

> So, unless there is some grand solution currently being architected in
> some skunkworks project out of the public eye, are you really doing
> anything more than just empolying stalling tactics? 

not stalling.  I want the group to focus its energy in useful
directions, not in directions already shown to be counterproductive.
--------------------------------------------------------------------
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: Fred Templin <[email-masked]>
Date: Tue, 12 Aug 2003 11:42:03 -0700

>it is a difficult problem.
And, what are the solutions being proposed by that "other" group? (Don't
worry; I know about multi6.) Is it HIP? Is it globally-routable PI? Is it
something else?

As they say at PacBell Park: "You can't know the players without a program!"

Fred
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Aug 2003 14:47:35 -0400

> >multi-homed sites - this is being worked on by another group. 
> >granted it is a difficult problem.
> >
> And, what are the solutions being proposed by that "other" group?
> (Don't worry; I know about multi6.) Is it HIP? Is it globally-routable
> PI? Is it something else?

I'm not caught up with that group enough to know.  I do know it's not
within scope for this group.
--------------------------------------------------------------------
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: Pekka Nikander <[email-masked]>
Date: Tue, 12 Aug 2003 22:18:09 +0300

Fred,

Fred Templin wrote:
> ...  but do you truly have an alternate proposal that

As far as I see, HIP does not currently provide anything for
intermittently-conneted/disconnnected sites.  Perhaps it could,
but AFAIK nobody has *seriously* considered that question.
(My gut feeling is that if HIP was adopted, the nature of this
and many other questions would change quite a lot.  But that
is just an educated guess, at best.)

>                                                            ....  So,
> skunkworks project out of the public eye ...   (And if there is such a stealth

I don't know about any skunkwork projects.  However, since HIP was
mentioned, perhaps I should try to clarify the situation.

There was a HIP mailing list for a long time @lists.freeswan.org.
However, due to hardware problems the list crashed three times during
the last year or so, losing its membership at least once, and the
archive at least once, too.  (I don't remember the details).

Anyway, there is now a new HIP mailing list @honor.trusecure.com,
see http://honor.trusecure.com/mailman/listinfo/hipsec
We tried to subscribe everybody we knew about to the new mailing
list, but I am sure some addresses just got lost.  If you
are interested, please join to the new mailing list.  It is currently
very low volume, but may get some traffic fairly soon (see below).
However, I don't expect it to get anywhere near IPNG volumes...

What comes to the architecture and base protocol specs, they are
fairly close to be ready for experimental.  On the other hand,
serious work on multi-homing, mobility, IPv4 NAT traversal and
DNS issues has only recently begun, and requires lots of work
before completed.

As I mentioned at the multi6 meeting in Vienna, there are currently
four interoperating implementations, at least two of which also
support limited HIP based mobility.  At least one even supports
mobility between IPv6 and IPv4.  I am not aware of any implementations
that would seriously support multi-homing, even though some support
for that is in draft-nikander-hip-mm-00.txt

There are also some discussions going on with some ADs about the
possibility of a working group that would produce experimental RFCs.
However, it is not clear whether such a group, if created, should be
a working group or an IRTF research group.  That is an issue that
should be discussed fairly soon at the hipsec ML.

--Pekka Nikander

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Aug 2003 13:12:34 -0700 (PDT)

> globally-unique or probably-unique

So I have a question: what does "disconnected"
really mean?  Does it mean people who do not have
any internet access whatsoever and never will? Or
does it mean people who want parts of their
network to be either physcially or through
firewalling to be disconnected from some or all of
the net?

If it's the former, maybe I'm heretical but do we
really much care? Back in the bad old days that
led to what what's been morphed now into the
"documentation prefix", but 10 years ago
disconnection from the Internet was pretty much
the norm... today though? Should we really fall
all over ourselves for individuals/organizations
that don't want to pay $9.95/mo and get a PA /48
that they can use to number their disconnected
network?

If it's the latter... a /48 gives 16 bits of
subnets. Surely that's enough to carve out a
network or two for their disconnect networks. And
even if they changed providers... so what?  If
it's a disconnected network using the old prefix
certainly doesn't _hurt_ anything until... you
want to connect it, but if you want to connect a
disconnected network you needed to renumber
anyway!

What am I missing?

	Mike

---

From: Fred Templin <[email-masked]>
Date: Tue, 12 Aug 2003 13:26:35 -0700

Pekka Nikander wrote

> archive at least once, too.  (I don't remember the details). 

Yes, I'm subscribed to that list - since 7/16/2002, actually. There was
a pretty healthy amount of traffic between 3/14/03 - 3/26/03 and then
it went silent. Since then, I have received two messages - one on 6/29/03
and another on 8/10/03 (only two days ago) - both messages were from
you, actually. I never saw any announcement of the new list...

> list, but I am sure some addresses just got lost.  If you

I guess I must have been one of those who just got lost - but isn't it
strange I should still be seeing messages on the old list then?

> However, I don't expect it to get anywhere near IPNG volumes... 

Gee - maybe *this* is the skunkworks project I have been sensing?! :^}
Sure; I'll go ahead and subscribe myself to the new list.

Fred
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Aug 2003 16:41:54 -0400

> Keith Moore writes:
>  > > Quick question - you have been nay-saying on local-use addressing
>  > > for as long as I can recall, but do you truly have an alternate
>  > > proposal that will work for intermittently-connected/disconnected
>  > > sites, 
>  > 
> any internet access whatsoever and never will? 

IMHO a truly disconnected network would have no connectivity to any
other net, at least at the present time.  If such a network were to
acquire Internet access it should renumber, much as if it were a site
moving from one ISP to another.

there's another useful category of site that has no connectivity to the
global/public Internet but does wish to connect to other sites, some of
which might connect to the global/public Internet.

> Or

no, it doesn't mean that.  of course if you want an entire network to be
isolated you can treat that as a disconnected network.  but usually you
want to allow some degree of external access to or from some of the
hosts on the network. if you do that, you should have global addresses
for all of those hosts even if you filter traffic to and from most of
them. otherwise you can't really expect apps to work between the
"privileged" hosts and the"unprivileged" ones - especially if those apps
also involve external hosts.

> really much care? 

yes, because isolated v4 networks that picked an arbitrary prefix and
then later connected to the rest of the net did cause and experience
problems.  we want them to be able to make a smooth transition.  also,
some networks that lack connectivitity to the global internet will still
want to interconnect with other networks.

> disconnected network you needed to renumber

not true.  in order to understand whether there's a potential
address conflict you need to consider the transitive closure of all
connections available to all hosts on the network.  if the same address
refers to different hosts anywhere in the network then it can still
cause problems for apps doing referrals even if the meaning of that
address is well-defined for every individual host.

---

From: "Todd T. Fries" <[email-masked]>
Date: Tue, 12 Aug 2003 17:22:25 -0500

I would think long and hard before I would mandate that my upstream ISP can
renumber me as a customer `at a whim'.  This screams `DOS' and `exploit haven'.
-- 
Todd Fries .. [email-masked]

Penned by Tony Hain on Wed, Aug 06, 2003 at 01:59:38PM -0700, we have:
| Leif Johansson wrote:
| > Yet another old argument. I remember several opposing voices 
| > from the SL 
| > debate.
| 
| Appearing to be primarily from service providers. By my count most of the no
| voters were from edge focused people. 
| 
| > I am running a large edge network. I have both PI and PA v4 and yet I 
| > don't see
| > the need for site-locals. 
| 
| So is all of your space is globally routed without any filtering or
| exclusion from routing protocols? Not everyone is in such a lucky position
| to have all of their network globally exposed.
| 
| > I think it is time to drop the "silent 
| > majority" argument.
| > 
| > What edge-network do you run?
| 
| Currently an insignificant one, but in past lives I have been involved in
| both large scale edge and core network management. The point is not what you
| or I think about the need for local addressing, it is about what the manager
| who can't get PI space is going to do. Insufficient resources to justify PI
| space does not invalidate their need for internal network stability. 
| 
| In the absence of NAT, allowing the ISPs to renumber customer networks at a
| whim will ensure 'address-portability' becomes a hot button. We can help
| mitigate what would become random PI by providing local stability. We can go
| further by providing a 'less-than-perfect' PI. PI will solve most of the
| requirements for local space, but by definition can't deal with the
| requirement to avoid accidentally becoming part of a routed aggregate.
| 
| Tony
| 
| 
| 
| 
| --------------------------------------------------------------------
| IETF IPng Working Group Mailing List
| IPng Home Page:                      http://playground.sun.com/ipng
| FTP archive:                      ftp://playground.sun.com/pub/ipng
| Direct all administrative requests to [email-masked]
| --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 13 Aug 2003 06:45:22 +0300

Fred,

Fred Templin wrote:
> it went silent. 

I guess the list crashed at 3/26/03, short shortly thereafter.
Your address probably got lost already then, since it did have some
more traffic afterwards.  Then it crashed again sometime in July,
and AFAIK it has not been restored after that.

> Since then, I have received two messages - one on 6/29/03

Those must have been crossposted to some other list.
The 8/10/03 message I meant to crosspost to the new list
(not the old one), but my fingers made a mistake.  The other
list the message was crossposted to was multi6.

I don't remember about the 6/29/03 one.  (I've been spending
time with my family all the summer, and reading mail at odd
hours without enough of coffee.)

We announced the new list on the new list :-)  My intention is to
annouce it elsewhere, too, but that is just still in my pipeline.

--Pekka Nikander

---

From: Andrew White <[email-masked]>
Date: Wed, 13 Aug 2003 17:11:43 +1000

Michael Thomas wrote:
> 
> So I have a question: what does "disconnected" really mean?

For my thoughts, read 'real life scenario - requirements' (posted Thu 07
Aug, 2003, 1:54 am GMT).  It think it quite adequately answers your
questions.  If not, perhaps you can rephrase them?

It also explains why a 'disconnected' network might want to maintain a
stable PI prefix for local use <emphasis>and continue to use that prefix
locally even when global prefixes are available</emphasis>.

A designated local prefix allows the wider network to filter these local use
prefixes, providing disincentive for using them as *globally* routeable PI,
and allows applications to favour local prefixes when available.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 13 Aug 2003 10:43:58 -0700

Mark Smith wrote:
> True, but in my experience in a large, multi-departmental 
> govenment network, is it fairly common that end user security 
> / access requirements don't fall neatly along route / prefix 
> boundaries. Typically this is because security has crept into 
> the network, triggered by attachement to the Internet.

This is inconsistent with your statement later about prefixes mapping to
broadcast domains.

> 
> In government networks, route filtering is a useful tool to 
> have, but mostly it is a "nice to use", because it is too 
> blunt to facilitate the security / access requirements of the 
> end users. 

So is this a statement that the approach is not useful in government
networks, or a statement that the tool is inadequate because it does not
solve the government network problems? 

> 
> Typically, the order of use of available network / transport 
> layer security tools to meet common end-user requirements is :
> 
> (1) "application" level - ie. filter on TCP / UDP ports, 
> possibly in combination with IPv4 source and / or destination address.
> Service providers, OTOH, protect their end-users by 
> protecting the network itself. Route filtering is one of the 
> primary tools for doing that, so (3) on my enterprise list is 
> one of the (1)s on the service provider list.

SP's aren't protecting their end-users by route filtering, they are
protecting their resources from other SP's. 

> 
> Since IPv6 prefixes are going to be mapped along the same 
> boundaries as IPv4 prefixes ie., layer 2 broadcast domains, 
> IPv6 route filtering in an government network will be just as 
> dull a tool as it is in IPv4. 

This shows IPv4 thinking, where the network has a single prefix / L2. While
I agree the initial deployments will likely mirror the IPv4 network, there
is no reason to preclude having additional prefixes / L2, where the
reachability characteristics are different.

> > filters, on the belief that failures will not occur in both at the 
> > same time. Despite the noise about not providing security, 
> these are 
> > two mechanisms used in basic layered security models.
> > 
> 
> The security paranoid, at least in an government environment, 
> would *like* to perform route filtering as part of a defense 
> in depth strategy in addition to filtering, but end-user 
> access requirements usually put an end to that idea.

That is only because there is a single prefix shared between those needing
accessibility and those wanting to be hidden. There is no requirement that a
single prefix be shared this way in an IPv6 network. 

Tony

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Aug 2003 11:22:23 -0700 (PDT)

> address is well-defined for every individual host.

In trying to formulate an answer to this it occurs
to me that there's a better question to ask: if it
is inevitable that we need PI space for
disconnected networks, then do you concede that we
will end up with (a) NAT's and (b) route growth
(due to advertizing /48's) for people who decide
to get and (ab)use them?

I've seen nothing which would dissuade me of that
notion, and plenty of evidence in the here and now
that that's exactly what will happen. Since IPv6
does not have an adequate solution for renumbering
-- and any such solution being the path of least
resistance is highly dubious -- are we not in the
same situation as IPv4 with respect to the
inevitabilty of NAT's since global PI is
inherently self-limiting due to route growth?

	   Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Aug 2003 15:01:26 -0400

> This shows IPv4 thinking, where the network has a single prefix / L2.
> While I agree the initial deployments will likely mirror the IPv4
> network, there is no reason to preclude having additional prefixes /
> L2, where the reachability characteristics are different.

...except that apps won't have any way of knowing which prefixes to use
for which purposes.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Aug 2003 14:57:05 -0400

> (due to advertizing /48's) for people who decide

I don't see either of these results as inevitable.

I think that we can make rules that say "no NATs in IPv6" and
"advertisements of PI prefixes on the public Internet should be
filtered" and that those rules will have a useful effect. They might not
entirely prevent either practice, but they may make them rare enough
that they do not cause huge problems.

In the case of NATs, I believe users will be less eager to deploy
NATs in IPv6 because (a) the absence of NATs in IPv6 allows the Internet
to support new kinds of applications that will drive deployment and (b)
IPv6 gives users better ways to solve some problems (renumbering,
attachment of a home network) whereas in IPv4 NATs were the
best tools available.  That and there is a greater awareness of NAT
problems than there used to be.  IMHO the big wildcard is security-
whether users will realize that NATs actually provide very little
security benefit as compared to say, stateless firewalls (which
themselves provide only a marginal benefit). Just as with poorly-chosen
countermeasures against spam and terrorism, there's currently a
widespread belief that any countermeasure against network attack is
justified, no matter how little protection it provides and how much
damage to functionality it does. Eventually people will learn better,
but I don't know how long this will take.

In the case of advertising PI prefixes, I believe ISPs will understand
the wisdom of filtering them.  They might not start filtering them
immediately, but if routers get overloaded, the price of advertising a
PI prefix will increase rapidly.  It might become cheaper to buy
redundancy using PA prefixes than to buy it using PI prefixes.  (I
could even imagine allocating PA prefixes to small sets of ISPs, for use
by customers that get connectivity from more than one of them.)  And I
suspect that if we recommend it, and get buyin from network operators'
groups,  a substantial fraction of ISPs will filter PI prefix
advertisements from peers.  That and I'm convinced that it's possible to
"aggregate" non-adjacent prefixes for route computation purposes with
only small changes in BGP (which doesn't do much for router memory size
but does a lot for routing computation overhead).  So basically I think
there are lots of ways to solve this problem.

Of course, we do need to provide better solutions for scalable routing
renumbering, and multihoming.  We also need a better security
architecture.  My impression is that we are devoting too much energy
to freaking out, when there are important problems we need to be
working on.

In particular, we need to get ourselves out of the habit of crying "that
will lead to NAT" or "that will lead to route explosion" and using these
as excuses to stop investigating a solution path.   Of course these are
hazards that should be respected, and I think everyone here understands
that.  But none of us knows with anything resembling certainty what the
market will demand, and so treating either of these as the "kiss of
death" for an idea serves no purpose other than to prevent us from
investigating (and thus, failing to discover) potential solutions.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Aug 2003 13:07:59 -0700 (PDT)

> that they do not cause huge problems.

Enforced by whom? Heck, forget enforcement.
*Voiced* by whom?

 > best tools available.

If people really, really want PI space -- which
they manifestly do to isolate themselves from PA
address changes amongst other things -- why does
it not follow that they'd like to make those nice
unroutable PI addresses that we so kindly provide
to not have reach farther than was intended? As
in, why doesn't the experience of RFC 1918
directly apply here? Even if you can get a
globally routable PA provided address, would the
network adminstrators who desire PI even want to
deal with them? Because they're still faced with
the daunting task of renumbering PA addresses if
they use them which was... sort of the reason that
they like PI addresses.

 > PI prefix will increase rapidly.  

Sure. Which leads directly to NAT's to get around
the perceived meanness of the ISP.

 > to freaking out, when there are important problems we need to be

I dunno, is it "freaking out" when the end result
of this exercise looks like the current IPv4
deployment except for a larger IP header?
 
 > as excuses to stop investigating a solution path.   

Even when there's ample existance proofs that it
will? It's sort of disingenous to claim Chicken
Littlism when the ipv4 sky has already fallen.

	 Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Aug 2003 16:37:32 -0400

>  > filtered" and that those rules will have a useful effect. They
>  > might not entirely prevent either practice, but they may make them
>  > rare enough that they do not cause huge problems.
> 

IETF.  Who did you think?

Do we need enforcement in order for vendors to more-or-less conform to
other specifications that we write?  

>  > NATs in IPv6 because (a) the absence of NATs in IPv6 allows the
>  > Internet to support new kinds of applications that will drive
>  > deployment and (b) IPv6 gives users better ways to solve some
>  > problems (renumbering, attachment of a home network) whereas in
>  > IPv4 NATs were the best tools available.
> 
> If people really, really want PI space -- which they manifestly do to
> isolate themselves from PA address changes amongst other things -- why
> does it not follow that they'd like to make those nice unroutable PI
> addresses that we so kindly provide to not have reach farther than was
> intended?

I can't even tell what question you are asking.  could you rephrase
that more simply?

> As in, why doesn't the experience of RFC 1918 directly apply
> here? 

*which* experience of RFC 1918?   there are lots of experiences,
some of them conflicting.

> Even if you can get a globally routable PA provided address,
> would the network adminstrators who desire PI even want to deal with
> them?

it depends.  do they want their networks to be able to communicate with
other networks (outside of private agreements) or not?  if no, PI
space will do just fine.  if yes, they'll need to use PA space for those
hosts (unless of course we solve the problem of making PA addresses
universally usable). 

> Because they're still faced with the daunting task of
> renumbering PA addresses if they use them which was... sort of the
> reason that they like PI addresses.

bad assumption.  renumbering need not be a daunting task if you have
tools and the necessary support.  I've seen fairly large v4 networks
renumbered without too many glitches - it will be even easier in v6 if
we finish the work. though it seems like we'd rather argue that it's
infeasible than work on the tools... 

>  > In the case of advertising PI prefixes, I believe ISPs will
>  > understand the wisdom of filtering them.  They might not start
>  > filtering them immediately, but if routers get overloaded, the
>  > price of advertising a PI prefix will increase rapidly.  
> 

nayh, nayh, nayh.  saying "this will lead directly to NATs" is starting
to sound a lot like comparing somebody to Hitler.  it's a meaningless
assertion because there's no way to evaluate it.

IMHO: you won't use NATs in IPv6 - because NATs will break your apps -
because the very reason you adopted IPv6 was to get away from the
problems with NATs and to let you run apps that aren't NAT compatible. 
for the forseeable future, apps that are NAT compatible are going to use
IPv4.

>  > Of course, we do need to provide better solutions for scalable
>  > routing renumbering, and multihoming.  We also need a better
>  > security architecture.  My impression is that we are devoting too
>  > much energy to freaking out, when there are important problems we
>  > need to be working on.
> 

yep, that's freaking out.  stop assuming that the past will repeat
itself - first because v4+NAT isn't going away (why bother with v6 if
you're going to keep using NATs?), and second, because the conditions
aren't the same.

>  > In particular, we need to get ourselves out of the habit of crying
>  > "that will lead to NAT" or "that will lead to route explosion" and
>  > using these as excuses to stop investigating a solution path.   
> 
> will?

no such proofs exist, just unfounded assertions based on questionable
assumptions.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Aug 2003 13:51:39 -0700 (PDT)

Keith Moore writes:
 > Hitler.

This is pointless.

Bye.

		Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Aug 2003 16:54:07 -0400

> This is pointless.

exactly my point.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 13 Aug 2003 14:04:15 -0700

Keith Moore wrote:
> ...except that apps won't have any way of knowing which 
> prefixes to use for which purposes.
> 

Only due to the refusal to accept that hinden/haberman prefixes would
provide a clue, and those used with the bellovin/zill RA provide a clear
indication to any app that cares to look. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Aug 2003 17:15:15 -0400

> > > network, there is no reason to preclude having additional 
> > > prefixes / L2, where the reachability characteristics are different.
> > 
> provide a clue, and those used with the bellovin/zill RA provide a
> clear indication to any app that cares to look. 

hinden/haberman prefixes as currently defined do not provide a clue.
just because a PI prefix is in use does not mean that it's more
or less suitable for a particular purpose than a PA prefix.  in practice
the app needs several attributes: stability of the address-to-host
binding, routability of the address among the hosts that will need to
use it, etc.  depending on which nodes the app will need to talk to and
their locations in the network, a PI prefix might do better in some
cases and a PA prefix in others, and there's really no good way to tell.

I am still in catchup mode and haven't read the bellovin/zill RA
proposal yet, and actually am having trouble figuring out which I-D
people mean when they say this.  please send a pointer in private mail.

Keith

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 Aug 2003 12:50:14 +0930

Hi Tony,

On Wed, 13 Aug 2003 10:43:58 -0700

> This is inconsistent with your statement later about prefixes mapping to

My point was that users who are members of a single prefix commonly have different security access requirements.

Far more often than route filtering a prefix to deny or permit access, I have :

(1) Applied access permissions to an individual "user" (obviously really a device), based on their IPv4 address, and the application (TCP/UDP ports) they are granted or denied access to.

(2) Applied access permissions to an individual "user", based on their IPv4 address.

(3) One or the other of the previous two methods, but to a subset of the prefix members eg., a /29 group within a /24 prefix. Sometimes multiple, different size subsets within the same prefix.

IPv4 addressing in the a number of cases in the past wasn't deployed along security boundaries, because security wasn't or wasn't much of a concern. Functionality was.

Some customers won't mind restructuring their network to meet their changed or newly recognised security requirements, but others know that packet filtering functionality usually comes for free with a router, and they want you to use it.

As a note on (3), after a while you start to realise that using network layer addressing for security isn't really that effective. If a user doesn't like the security access they have from their workstation, they will go and use somebody else's who has more access. While this could be classed as a physical security issue, it would be better if security could be applied at or nearer to the application layer, irrespective of network addressing or location. It is people we do or don't trust, not machines.

I'm hoping that some of the "uglyness" of IPv6 addresses, including EUI-64 addressing for nodes, will encourage application security to be moved up the stack closer to the the users. Then I will have far less packet filtering to do, with all the associated "how does this application actually work at the transport layer" learning I have to do, on a per application basis. (Hmm, the inside of a network security person's head might be as ugly as a NAT code base ... )

> solve the government network problems? 

I think it is inadequate, because it doesn't provide the resolution necessary to implement a number of customers' security access requirements. My examples above hopefully show that.

> protecting their resources from other SP's. 

I'm using the word "protect" in this case in the context of protecting their end-users by providing availability.

> reachability characteristics are different.

I agree.

But unless we are going to be able to allocate IPv6 addresses to applications*, I don't think route filtering is ever going to be as effective as packet filtering on individual network layer addresses and / or TCP / UDP ports. And that is a very common security request.

Regards,
Mark.

* Peter M. Gleitz and Steve Bellovin have written a paper called "Transient Addressing for Related Processes: Improved Firewalling by Using IPV6 and Multiple Addresses per Host", which seems to suggest doing this. I've only had a chance to briefly read the abstract, so I don't know how feasible or practical it would be to deploy this idea.

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Aug 2003 10:07:53 +0100

> attachment of a home network) whereas in IPv4 NATs were the

So where are the cost savings in renumbering an IPv6 network as opposed to
renumbering an IPv4 network?   This would be an interesting question to expand
on I think...

Tim

---

From: Carlos Friacas <[email-masked]>
Date: Thu, 14 Aug 2003 11:20:07 +0100 (WEST)

> renumbering an IPv4 network?   This would be an interesting question to expand

renumbering an IPv4 network:
- The 1st critical parameter is *size*.
*if* you are not using dhcp, even in an /27 segment (30 hosts if 100%
used) it can be real hard to renumber. it consumes *time*, although being
a simple/basic task. If you have a /24 or /23, well.. it is a real pain.
- The 2nd critical parameter is how many "hard-wired" addresses
(regarding services) you have inside it.
dns servers are usually the biggest pain. if you use dhcp, resolvers are
not a problem (if they are inside the network being renumbered), you just
have to change a parameter in the dhcp server, if not it is a pain.
but the trickiest/hardest part usually lies with authoritative
nameservers -- If your "upper levels" (forwards and reverses) aren't fast
enough to respond, you will think twice before going into a renumber. :-)

renumbering an IPv6 network:
- The 2nd critical parameter i've mentioned is also valid for IPv6. :-(((

One more comment:
Renumbering from 6BONE addresses to RIR addresses... it might be a good
solution/idea to still route the /128s associated with addresses that are
in somewhat way hard-wired to some services, as part of the phase-out
process. e.g: keep the routing to 3FFE:XYZW:1:2::1/128 in your IGP to
2001:XYZW:1:2::1/128, but stop configuring 3FFE:XYZW:1:2::/64 on its
gateway/router. This will prevent other machines to get a prefix in 3FFE,
but still guarantees the connectivity to one single server in the "6bone
context".

Regards,

./Carlos                                  "Upgrade the Internet! -- Now!"
--------------         [http://www.ip6.fccn.pt]        http://www.fccn.pt
<[email-masked]>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup
FCCN - Fundacao para a Computacao Cientifica Nacional  fax:+351 218472167

 "Internet is just routes (125953/461), naming (millions) and... people!"

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Aug 2003 11:24:48 +0100

Carlos, the question is "where are the cost savings in renumbering an 
IPv6 network as opposed to renumbering an IPv4 network".

Tim

PS. According to dnsop people, everyone will use DHCPv6(!)

---

From: Carlos Friacas <[email-masked]>
Date: Thu, 14 Aug 2003 11:28:09 +0100 (WEST)

> inherently self-limiting due to route growth?

"route growth":
I would really prefer to see 20.000 IPv6 routes if 20.000 ASNs exist, but
today i think there is no problem with having 120.000 routes, the same way
it wouldnt be a problem to have 500.000 -- just keep upgrading the memory
on your border routers, thus keeping the vendors happy! ;-)

*However*... if i saw more than 127.000 on the v4 global routing system, i
would say that a lot of it might have just one cause: people dont know
what they are doing! With some task-force *acting* regarding routing,
mistakes could be seriously reduced. In terms of IPv6, there is the GRH
project... my thoughts on this are pretty clear: it *now* the time to
prevent mistakes to happen while the IPv6 global routing table is short,
and at the same time estabilish the means to keep it *clean*!

Regards,

---

From: Carlos Friacas <[email-masked]>
Date: Thu, 14 Aug 2003 12:33:55 +0100 (WEST)

> PS. According to dnsop people, everyone will use DHCPv6(!)

Use of DHCPv6 will solve the resolver issue, if its inside the renumbering
network... however some predictions will prove to be wrong later...

About the costs: If the IPv4 network being renumbered already uses dhcp, i
dont see any real cost difference. :-(

---

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Aug 2003 07:35:57 -0400

Taking Carlos' analysis a step further, there are two kinds of "stuff" that
has to be fixed during a renumbering event: stuff that can be fixed
automatically (cost essentially independent of network complexity) and stuff
that has to be fixed manually (cost that scales with network complexity).
For example, addresses assigned through autoconf can be fixed automatically
while hard-wired addresses buried in config files have to be fixed manually.
  At the risk of over-simplification, there will be cost savings in
renumbering IPv6 networks - cost savings that can be directly attributed to
IPv6 - if there is more stuff in the first category for an IPv6 network than
for an IPv4 network.  That is, if we can point at stuff that can be fixed
automatically in an IPv6 network, we can identify cost savings.

The cost savings analysis in the previous paragraph focuses on time (and
$$$s) saved by network admins.  Another cost metric might be
time-to-renumber; that is, how quickly can a renumbering event be completed.
  For example, IPv4 hosts using DHCP can be automatically renumbered, but
there is a latency in the renumbering related to the length of the leases on
the addresses assigned through DHCP.  IPv6 hosts using autoconf can be
automatically renumbered by changing the advertised prefixes, presumably
with less latency.

Another potential advantage for IPv6 that is a little harder to quantify is
the notion of "graceful" renumbering - the ability to have a transition
state in which both the old and new prefixes are in use simultaneously.
Will this transition state work in practice?  Has anyone actually tried it?

So, here are three ways to assess the renumbering advantages for IPv6:

* Stuff moves from "manually configured" in IPv4 to "automatically
   configured" in IPv6, as a direct result of the design of IPv6
* Renumbering latency is reduced
* Renumbering is enabled by IPv6 (graceful renumbering) that can't be
   accomplished with IPv4

- Ralph

---

From: Carlos Friacas <[email-masked]>
Date: Thu, 14 Aug 2003 12:34:45 +0100 (WEST)

s/will prove/might prove.

:-)

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Aug 2003 13:37:56 +0100

> * Renumbering is enabled by IPv6 (graceful renumbering) that can't be

How different is this to the multi-addressing multihoming scenario, which
Christian Huitema's proposals are attacking?   I think this is good work,
but the brickbats come from those who wish to push/enforce central policy 
to hosts for the host address selection algorithms (moreso in larger
corporate networks than the SOHO networks that Christian's work seems very
well suited for).

The "Renumbering is easier/cheaper in IPv6" quote comes up quite frequently;
it's nice to perhaps delve into it a bit deeper (I don't recall anyone has
recently...)

Tim

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Aug 2003 08:56:48 -0400

> state in which both the old and new prefixes are in use simultaneously.

the effect of this on renumbering cost is going to be highly site-dependent.
"graceful" renumbering offers the potential to renumber with zero downtime,
and without breaking open connections.  if you lose a substantial amount of
money for every minute of downtime, this matters a lot.
--------------------------------------------------------------------
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: Ralph Droms <[email-masked]>
Date: Thu, 14 Aug 2003 09:03:49 -0400

Agreed - there are significant potential savings.  Does it work?

- Ralph

---

From: Mans Nilsson <[email-masked]>
Date: Thu, 14 Aug 2003 15:04:57 +0200

> renumbering an IPv4 network?   This would be an interesting question to expand

It is still entirely possible to do the stoopid mistakes of hardwiring
addresses in v6, much as it is (way too common) in v4. But, given
the built-in ability to autoconfigure, and the yet-to-be-built
nature of much v6 deployment, client and simple network services
can be made to switch centrally, by adjusting the RA prefix and
moving things in DNS, perhaps using DynDNS[0]. 

There will always be pain. That is why we have network admins. But,
given that brain is switched on before net design commences, it is
with v6 possible to considerably lessen the cost/work impact of a
renumber event. Naturally, this can be done in v4 too -- BTDT. 

Still, I wonder why I'm debating this here. It is v6ops material. 
-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

Wait ... is this a FUN THING or the END of LIFE in Petticoat
Junction??

[0] Jakob Schlyter has done a nice summary of a working methodology
for this; see http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Aug 2003 09:34:23 -0400

On Thu, 14 Aug 2003 13:37:56 +0100

> corporate networks than the SOHO networks that Christian's work seems very

address selection won't work except in very simple cases.  it's a lousy 
way of implementing routing policy.  it needs to die, violently if necessary.

but being able to renumber without breaking open connections (well, without
breaking connections that are open with long periods of time)  is really
useful for disruption-sensitive environments.

also my impression is that stateless address autoconf is a lot more
generally applicable than DHCP, because it provides a stable address
for the host without requiring any per-host configuration on the DHCP
server.  this makes renumbering easier because there's less configuration
data that has to be changed.
--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Thu, 14 Aug 2003 18:16:53 +0300 (EEST)

> PS. According to dnsop people, everyone will use DHCPv6(!)

To be clear, there seems to be a rather large number of people who think
that DHCPv6 will be used to configure "other" fancy stuff on network (e.g.
DNS resolver addresses).

I don't think all that many would step up if we stirred in the address 
assignment of DHCPv6 to the mix.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 14 Aug 2003 09:39:59 -0700

Mark Smith wrote:
> > networks, or a statement that the tool is inadequate 
> because it does 
> > not solve the government network problems?
> > 
> 
> I think it is inadequate, because it doesn't provide the 
> resolution necessary to implement a number of customers' 
> security access requirements. My examples above hopefully show that.

The examples show there environments more complex than a simple tool can
deal with. That does not make the tool inadequate for the simple
environments. 

> prefixes / 
> But unless we are going to be able to allocate IPv6 addresses 
> to applications*, I don't think route filtering is ever going 
> to be as effective as packet filtering on individual network 
> layer addresses and / or TCP / UDP ports. And that is a very 
> common security request.

Yes that is a common security request, but it falls flat on its face when
the TCP/UDP ports are masked by IPsec, or simply spoofed by the application
(ie: both ends agree that 80 is a remote file mount). To your earlier
comment about filtering is free, it really isn't. Yes it is included in the
box, but doing the work requires time (increased app latency), or dedicated
hardware (increased device cost), so it isn't free. 

* To some degree this is the deployment model. Not to explicitly allocate an
address to an individual app, but to allocate addresses with the
characteristics of 'local use' and 'global use', then have the apps bind to
the appropriate one. If a local policy is more complex than the simple two
layers, it will need additional (out of scope for this approach) mechanisms
to sort out which app should be bound to which address.

Tony

... Please send a pointer to the Gleitz/Bellovin paper

> 
> Regards,
> Mark.
> 
> * Peter M. Gleitz and Steve Bellovin have written a paper 
> called "Transient Addressing for Related Processes: Improved 
> Firewalling by Using IPV6 and Multiple Addresses per Host", 
> which seems to suggest doing this. I've only had a chance to 
> briefly read the abstract, so I don't know how feasible or 
> practical it would be to deploy this idea. 
>

---

From: Bill Manning <[email-masked]>
Date: Thu, 14 Aug 2003 09:51:56 -0700 (PDT)

% On Thu, 14 Aug 2003, Tim Chown wrote:
% [...]
% > PS. According to dnsop people, everyone will use DHCPv6(!)
% 
% To be clear, there seems to be a rather large number of people who think
% that DHCPv6 will be used to configure "other" fancy stuff on network (e.g.
% DNS resolver addresses).
% 
% I don't think all that many would step up if we stirred in the address 
% assignment of DHCPv6 to the mix.

	there was a hairbrained idea to have Internic (pre-RIR)
	run the DHCP server for the Internet... :)

	from the old PIER wg...

	things that don't like renumbering:

	BGP endpoints
	SNMP agents & collectors & network mgmt code
	syslog
	DNS authoritative servers
	DHCP servers
	(anything w/ access controls or policy based on IP addresses)
	(anything w/ hardcoded or well-known addresses)

-- 
--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: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 15 Aug 2003 03:12:19 +0900

>>>>> On Thu, 14 Aug 2003 07:35:57 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> Will this transition state work in practice?  Has anyone actually tried it?

Not sure if this answers your question, but we tried site-(IPv6)renumbering
in an experimental environment 3 years ago.  In that testing, we had a
transition state with the both old and new prefixes.  The presentation
slides of a report at an IETF meeting are available at the following URL:
http://www.jinmei.org/mgp/ietf49-renumber/

					JINMEI, Tatuya

---

From: Fred Templin <[email-masked]>
Date: Thu, 14 Aug 2003 11:25:57 -0700

Ralph,

> while hard-wired addresses buried in config files have to be fixed 

How would you categorize "stuff that is cached in data structures supporting
active sessions/applications"? Seems to me that this stuff needs to 
either be
immune to renumbering events or gracefully responsive to renumbering
events.

> Will this transition state work in practice?  Has anyone actually 

Yes, I have tried it in fielded demonstrations - but, I don't have a good
sense as to whether you can consider this "practice". I can't make any
claims as to robustness, responsiveness to renumbering events, etc;
only that it makes for an interesting demonstration.

Fred
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Aug 2003 16:59:35 -0400

> * To some degree this is the deployment model. Not to explicitly
> allocate an address to an individual app, but to allocate addresses
> with the characteristics of 'local use' and 'global use', then have
> the apps bind to the appropriate one. 

This is not an appropriate model.  It doesn't actually aid security, and
it makes the apps more complex without any sound justification for doing
so.

---

From: Mark Smith <[email-masked]>
Date: Fri, 15 Aug 2003 11:32:58 +0930

On Thu, 14 Aug 2003 09:39:59 -0700

> deal with. That does not make the tool inadequate for the simple

Fair enough.

Obviously route filtering is not the only tool necessary in complex enviroments, nor the first one that will be used, which is what I though you were initially suggesting.

> (ie: both ends agree that 80 is a remote file mount).

Absolutely.

Thats another reason why implementing security at the application end-points, eg., by identifying the user, not the machine they are coming from, will become a far more effective.

Various "tunnel over http" and other techniques take advantage of this fact.

(http://openvpn.sf.net is the best example I've seen - uses UDP, with a selectable port, SSL for encryption, and uses SSL session IDs for tunnel end point identification ie. the tunnel end point IP addresses can change, and the tunnel still works - nice for flakey dial up links, or ADSL sessions where your ISP insists on occasionally changing your IP address. Under linux, it can emulate an ethernet interface, so IPv6 autoconfiguration just works. I wonder how many firewalls thoroughly check the contents of UDP port 53 a.k.a DNS traffic ...)

 To your earlier
> hardware (increased device cost), so it isn't free. 

I agree it isn't free. But it is common for the router to have enough excess capacity such that it is effectively free, when compared with e.g., creating a new layer 2 segment, allocating a new prefix, possibly purchasing and implementing a firewall for that segment, developing a new firewall rule set to suit the user(s) and renumbering. 

After implementing this filtering, I've never come across a user who has complained about performance.

> ... Please send a pointer to the Gleitz/Bellovin paper

My pleasure.

http://www.research.att.com/~smb/papers/tarp.pdf

Regards,
Mark.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 17 Aug 2003 17:43:47 +0200

>Still, I wonder why I'm debating this here. It is v6ops material. 
Hmm Yes. One of the ops ADs even spoke up to support Måns in this, which
is a hint as good as any imho. Go request a slot for a renumbering-BOF 
at the
next IETF and lets move on.

       Cheers Leif

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 17 Aug 2003 14:37:39 -0700

Forming a WG to fantasize about renumbering will not suddenly remove the
edge network manager's requirement for stable address space. The only way
this comes close to being an Ops problem is due to the lack of reliability &
scale in DNS. As long as end users feel that name resolution is
insufficiently reliable to meet their business goals, they will continue to
embed literal addresses in applications & databases that are outside the
network manager's control. If you want to form an Ops WG, create one to
provide a reliable replacement for DNS.

Architectural management of the address space belongs in this WG, and there
is a requirement for space which is not currently allocated. If you don't
want to participate in that discussion, fine. Just stop getting in the way
of those that are trying to solve real day-to-day problems.

Tony

> [mailto:[email-masked]] On Behalf Of Leif Johansson
> Sent: Sunday, August 17, 2003 8:44 AM
> To: Mans Nilsson
> Cc: [email-masked]
> Subject: Re: inevitability of PI
> 
> 
> Mans Nilsson wrote:
> 
> >
> Hmm Yes. One of the ops ADs even spoke up to support Måns in 
> this, which is a hint as good as any imho. Go request a slot 
> for a renumbering-BOF 
> at the

---

From: Keith Moore <[email-masked]>
Date: Sun, 17 Aug 2003 21:11:51 -0400

For once, Tony and I are in agreement.  This has nothing to do with
operations; it has everything to do with the programming model that the v6
Internet supports.

But I'll go even farther.  You can improve DNS reliability a bit through
saner operations, but you still can't make DNS good enough to replace
addresses as endpoint identifiers.   DNS names are already used (some would
say "overloaded") for too many different things for us to start insisting 
that they be usable as stable endpoint identifiers.  Furthermore, the very
structure of DNS (the size and structure of the names, way the names are
federated, the way lookups are federated) also makes it unsuitable for this
purpose.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Mon, 18 Aug 2003 11:34:33 +0200

>operations; it has everything to do with the programming model that the v6
I am saving this email :-) Who am I to argue with such overwhelming 
opposition.

       Cheers Leif

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 12 Aug 2003 16:13:06 +0200

I am away on vacation and have missed all the fun...for what i matters, 
I think A is the way to go. That sends a clear signal to network 
managers, implementors etc. B and C will leave us in a vacuum.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 12 Aug 2003 17:45:47 +0200

> address allocation and a globally unique PI address allocation.

Bingo! So let's kill SLs and start working on the real issue...

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 12 Aug 2003 16:42:07 +0200

> provider independent addresses, then it would have to be deployed in 
> most routers in the Internet before it would be useful.  Probably all 
> routers from the site boundary to the core of the Internet.  Given 
> that I suspect any solution in this area would not be an incremental 
> changes to a routers implementation (i.e., not another BGP extension), 
> perhaps even changes to the routers route lookup engines (in hardware 
> in many cases) this would likely take a long time to accomplish.  
> Also, a bit of a chicken and egg deployment problem that everyone 
> working on IPv6 understands too well.

We will need to go through this anyway. Local scoped addresses will 
probably make that transition even harder.

> types of addresses.  The registries might be able to do it, but as 
> they are currently structured they are mostly focused on ISPs, not 

Erh, no. Perhaps every enterprise the sites belong to though.

> to be some incentive for the ISP to want to carry these type of 
> routes.  They are great for the customers, but it makes it easy for 
> their customers to switch ISPs.  We have seen how well the phone 
> providers have embraced provider independent phone numbers.  They only 
> "agreed" to support them after governmental action.

This has not been a problem in most European countries that I know of.  
But I am no expert on this. I know that in Sweden it is currently the 
other way around.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 12 Aug 2003 17:04:15 +0200

> This would break nothing that runs today.

As with reusing /8s in IPv4, keep as IANA reserved for a while, then 
use.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 19 Aug 2003 00:08:01 +0200

Fred,

> (Don't

there are two design teams as well as a number of individual 
submissions. HIP is one of the "individual" (well) proposals. 
Globally-routable-like features are the goal of most of the proposals. 
Globally-routable-as-is-addresses have AFAIK only been proposed by me, 
and then in a very short-lived bridging solution into something else.

You are right that we don't know what the outcome of the design-teams 
will be, and we don't know how we will make the selection between them. 
Ideally, they are not to far enough and can be merged. But this is 
dependent on a lot more issues than what have been discussed here.

Best regards,

- kurtis -

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Aug 2003 16:02:06 +0200 (CEST)

> <draft-hinden-ipv6-global-local-addr-02.txt> as a working group document in 

I didn't know there were such side effects associated with accepting that
as a WG document.
My assumption was that it was a fine thing to work on possible replacements
and to understand the cost/benefit tradeoffs of such replacements.

But presumably the WG should be capable to still say "we don't like any of
them". 
Your logic seems to preclude such a conclusion.

FWIW, I think a multi6 solution with id/loc separation will make the
local addressing concerns go away. 

  Erik

---

From: "Alan E. Beard" <[email-masked]>
Date: Tue, 19 Aug 2003 12:57:52 -0400 (EDT)

Erik:

I'm going to poke my nose into this thread in hope of alleviating some
possible misapprehension concerning interpretation of the original "fourth
alternative" text. Please see below for comments.

> Your logic seems to preclude such a conclusion.
From a review of previous messages in this thread, the text which seems to

>>but I think the working group has made it clear that this is not a

As I interpret Bob's text cited at the head of this note, the citing of
the decision to accept <draft-hinden-ipv6-global-local-addr-02.txt> as a
WG document is evidence in support of the assertion that the fourth
alternative (specifically, to decline to replace site locals in any form)
has not found any credible level of support in the list. As I interpret
the history, and based on my memory of the tenor of disussions at Vienna
(yes, I snuck in), the decision to accept said draft as a WG document was
a direct result of the WG collective opinion that one or more alternatives
to SL are clearly necessary, and that
<draft-hinden-ipv6-global-local-addr-02.txt> offers at least the potential
of a workable alternative. Based on this sequence and history, the
decision to accept the Hinden draft was a consequence, rather than the
origin, of the disapprobation of the suggestion to deprecate Site-Locals
without pursuing work on suitable replacements for local addressing
allocations.  As I remember the discussions, it is not Bob's logic, but
rather the collective logic of the group as demonstrated in the WG
decision (expressed as a show of hands), which precludes the conclusion
that SL may or should be deprecated without some provision for work on
viable alternatives.  Notwithstanding the very strong IETF tradition of
stare decisis, it is possible (although not, IMO, likely) that after
discussion we will conclude that we cannot find a workable alternative.
Should we reach this eventuality, we will have, if deprecation of SL
proceeds before viable alternatives are codified, exactly the condition
postulated in the fourth alternative; but that is, as I read the history,
clearly _not_ the intended outcome. (If anyone is brave enough to attempt
a diagram of that last sentence, I'd love to see the result. ;-(  )

> local addressing concerns go away.
While a multi6 solution such as you suggest above would undoubtedly
obviate one set of requirements which drive demand for local addressing,
other requirement sets now extant will not be obviated thereby; the demand
for local addressing will persist until _all_ requirement sets which drive
that demand are satisfied by other solutions. Some of these requirement
sets (such as address stability and address portability for enterprise
networks across ISP changes) are perhaps less amenable to engineered
solutions than are the multihoming issues.

I devoutly wish that the issue of local addressing were so straightforward
that a single solution would resolve the issue entirely; sadly, that does
not appear to be the case, based discussions in this WG.

Regards,

AEB

-- 
Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529

---

From: Bob Hinden <[email-masked]>
Date: Tue, 19 Aug 2003 16:23:29 -0700

Erik,

>Your logic seems to preclude such a conclusion.

I don't think it precludes such a conclusion in the future as any solution 
will need to go through normal IETF processes to advance.  But I do think 
it represented a reasonable conclusion at the time based on the Vienna IETF 
sessions and subsequent discussion.

>local addressing concerns go away.

Also FWIW, I think opinions differ on this topic and we will know more when 
there is a specified solution so it's benefits and weaknesses can be 
evaluated.  I note that people have been talking about for almost as long 
as IPv6 has been around.  However, I think it would be unwise for the 
working group to defer what we can do now in this area to wait for this to 
happen.  When or if it happens, it's benefits will encourage everyone to 
adopt it quickly.

Bob

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 19 Aug 2003 18:04:05 -0700

Erik Nordmark wrote:
> ...
> FWIW, I think a multi6 solution with id/loc separation will 
> make the local addressing concerns go away. 

Well a 'solution' might do that, but I don't see one happening in our
lifetimes. Any separation will require a mapping infrastructure to
dynamically bind the values back together. Such a mapping infrastructure
will have all of the scaling concerns of DNS, plus the constraint that its
convergence times are extremely short. There is no well-known technology for
running a global multi-master, cross trust boundary, database, with
appropriate caching for scale, and convergence times that are useful for
application failover. If one exists, maybe the end system stacks can be
rebuilt to use it within a decade ...

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Aug 2003 19:56:05 -0400

On Tue, 19 Aug 2003 18:04:05 -0700
"Tony Hain" <[email-masked]> wrote:

> dynamically bind the values back together.

agreed.

> Such a mapping infrastructure
> will have all of the scaling concerns of DNS,

Not clear.  Nothing says that the mapping service has to be organized 
like DNS.  It is not inherently necessary (though quite possibly 
desirable) that assignment of stable IDs be federated similarly to the
way address blocks are federated, so that the service can do mapping
on a per-block basis rather than a per-address basis.  However, there 
is no inherent reason that the servers that provide the mapping have 
to be provided by the assignees of those ID blocks.  Nor is there
any inherent reason that propagation of updates has to be like DNS.

>  plus the constraint that its
> application failover. 

What would you call BGP then?  Granted, it's not exactly a database, but it's
certainly "multi-master" and "cross trust boundary" and it at least attempts
to converge within a timeframe in which apps can fail over.

I'm not claiming that defining this mapping infrastructure is an easy problem
- certainly it is not.  However it doesn't seem like a good idea to assume
that it needs to look like DNS.  If anything, it's precisely because we know
the pitfalls of DNS, that we should look for a somewhat different solution.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Aug 2003 10:46:42 +0200

I prefer B (I don't want to see private reinvention of SLs).

[email-masked]