Subject: A use for site local addresses?

From: Mike Saywell <[email-masked]>
Date: Mon, 24 Mar 2003 14:05:21 +0000

Hi all,

I've only just joined the list - I'm mailing about the proposed abandoning
of site locals because I'd like to use them!

Basically I'm involved in setting up a community wireless network in
Southampton, UK.  The wireless network itself is a fully routed mesh
using private (10.13/16) addresses, the long term goal is to get ISPs
to provide internet gateways which you connect to via a VPN, PPPoE or
some other method, over which you get a public address.

We'd like to start running v6 on the network alongside the 10.13 addresses
and site-locals seem like the most sensible choice since it's the only
allocation of v6 addresses which is going to be available for us to use
and which is large enough to accomodate a /48 per access point (of which
there could be hundreds).  Obviously the same internet access model could
be used so you would get a public prefix over the PPPoE connection.

The site-local addresses would only be used for traffic contained within
the the wireless mesh, if some areas offered open internet access then
they could advertise an additional prefix routed from their own internet
connection, thus avoiding any NAT.

Well, that's my use and case for Site-Locals in a nut-shell!  I realise
that this type of deployment is quite a rare case, but I think it
represents a legitimate use of private addresses.

By the way, another option which would work very well in this type
of scenario is the geographical based addressing -
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt

Thanks,

Mike Saywell

Southampton Open Wireless Network
http://www.sown.org.uk

PhD Student, Dept ECS, Southampton UK.
--------------------------------------------------------------------
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: Mon, 24 Mar 2003 16:50:57 +0200

This could be covered under the prefix FEC0.

This  is the prefix of a site local address. Site local addresses are the equivalent of a private IPv4 address.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Mar 2003 17:43:24 +0100

But would there be a problem in using any legitimate /48 prefix instead?

  Brian

---

From: Mike Saywell <[email-masked]>
Date: Mon, 24 Mar 2003 17:25:53 +0000

> But would there be a problem in using any legitimate /48 prefix instead?

It's not really enough address space... ideally I think we should be
offering each site connected to the network a /48 like an ISP would.
I suppose in reality less would be sufficient, perhaps a /56...

If everybody connected to the network had a /48 from their ISP it would
be ok, but that's not going to be possible for a while.

Also if you're giving people a global address, then they would probably
expect it to be exactly that (i.e. globally routable).  Whereas in this
case it wouldn't be...

Cheers,

Mike

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 24 Mar 2003 11:09:41 -0800

This is very close to the use case I referred to at the microphone
during the Thursday session in San Francisco when I spoke of
intermittently-connected networks. Take for example an ad-hoc/mesh
network that travels together and may from time to time lose connection
with the global Internet; perhaps reconnecting at a different point
of attachment at some later time. While detached, the nodes in the
intermittently-connected network should still be able to communicate
with one another. But, when reconnecting to a different point of
attachment, ongoing intra-network communications should not be
impacted by monolithic renumbering events.

Site-locals seem like a natural mechanism for such use cases, but if
they are to be deprecated a different scheme is needed. Possibilities
include having one or more nodes in the intermittently-connected network
"own" a global prefix that gets injected into the global routing tables
at the current point of attachment, a geo-addressing scheme such as the
one referred to below, or perhaps some new scheme that is yet to be
identified.

IMO, use cases such as these need to be identified and addressed in
whatever mechanisms are chosen as we move forward. New ideas and
further discussion along these lines would probably be a good thing.

Fred Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Mar 2003 22:00:09 +0200 (EET)

> impacted by monolithic renumbering events.
[...]

This case could work if you just use addresses with a lifetime long enough 
to survive the disconnection (and deprecate the addresses immediately when 
you reconnect and start using new ones).

It's bit of a hack, and details have to be worked out to see if there are 
any gaps in this (one is that you can't deprecate an address faster than 
2 hours unless IPsec is used).

-- 
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: "EricLKlein" <[email-masked]>
Date: Tue, 25 Mar 2003 10:46:50 +0200

When did site local addresses die and why? I changed companies and missed
several months of discussion.

Currently I am working on NMS related changes based on:
* FE8, FE9, FEA, and FEB are Link local addresses
* FEC0 is the prefix of a site local address. Site local addresses are the
equivalent of a private IPv4 address

As stated by several other comments recently, I see taht there is not a
consensus about the fate of Link local addresses.

To many people are used to thinking of using the 10 net as their local
(corporate or internal) address space. If we do not take this into account
then these people will adopt ::10:X:X:X:X  as the local addresses just as
before. When this is related to large companies and their internal (not
addressable fro the public Internet) hardware they still need some sort of
site or organization local addresses.

We can not pass this by just to prevet slowing otherthings down. There are
too many documents out there that refer to FEC0 as the site local, so you
will not be able to use it for other applications, thus we will have a de
facto standard based on old information while the offical standard will have
no alternate.

We must take the lead on this issue.
Eric Klein
NGN Solutions Manager
TTI Team Telecom International

----- Original Message -----
From: "Tim Chown" <[email-masked]>
To: "EricLKlein" <[email-masked]>
Sent: Monday, March 24, 2003 6:54 PM
Subject: Re: A use for site local addresses?

> Read the email.  Site locals are dead, hence the question :)
>
> On Mon, Mar 24, 2003 at 04:50:57PM +0200, EricLKlein wrote:
> > This  is the prefix of a site local address. Site local addresses are
the equivalent of a private IPv4 address.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Mar 2003 10:02:08 +0100

> (corporate or internal) address space. If we do not take this into 

The same people are also trying to understand why a number of 
applications doesn't work in their network and how come that trojan 
send their password file to a unknown destination. Private addresses 
comes at a cost that is becoming more and more apparent. No need to pay 
that price in IPv6 as well as in IPv4.

If you absolutely want NAT take a random address block and NAT it for 
you. You will get the same problems / benefits.

Site-locals was voted down in the WG meeting in SF.

- kurtis -

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 25 Mar 2003 11:06:53 +0200

> you. You will get the same problems / benefits.

Who is going to priovide the registered addresses that will be used for all
corporations and at what price? Most companies will not want to have to pay
for a public address for all their printers and copiers (and microwaves as
those are added by Microsoft).

> Site-locals was voted down in the WG meeting in SF.
How do those of us who can not attend these conferences get into these
limited participation votes? I for one can not make frequent international
trips for a non-customer related meeting.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 25 Mar 2003 10:13:59 +0100

>facto standard based on old information while the offical standard will have
Let's please remember that the architechture devised here will primarily 
be used to
run _applications_. Long experience shows that private addresses in any 
form are a
bad idea on the Internet. This was discussed at length on the v6 wg 
meeting last week
and I believe that deprecating sl is the best we can do.

       leifj

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 25 Mar 2003 11:36:29 +0200

----- Original Message ----- 

> and I believe that deprecating sl is the best we can do.

I am willing to admit that there are big problems with private addresses, but a simple search on www.yahoo.com for 

+ipv6 +"local address" 

The results are 13,400 pages.

We need to define this very clearly and get it out there as the already too much confusion as to how it is recommended to implement this. At least two people have posted that they don't think that the fe80:: range will be able to be used due to this prepublication of the concept (see draft-itojun-ipv6-local-experiment-00.txt for example).

As a recommendation team we need to offer an alternative not just a "the old way was bad so don't used it anymore" kind of answer. 

I understand that there was a discussion and vote in SF, great. Who is going to put out a new draft-RFC that will explain this clearly enough that end-user implementation people (think LAN installation) will understand it and will be willing to work with it. They have a history of doing the old way why should they change now?

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Mar 2003 11:07:21 +0100

> those are added by Microsoft).

You can get addresses from your upstream provider.

> trips for a non-customer related meeting.

The vote needs to be confirmed on the mailinglist so you will have an 
opportunity to vote. However, the vote in SF was pretty clear.

- kurtis -

---

From: Mark Thompson <[email-masked]>
Date: Tue, 25 Mar 2003 10:03:31 +0000

* Leif Johansson <[email-masked]> 20030325.0913:
>
> Long experience shows that private addresses in any 
> form are a
> bad idea on the Internet. 

But what I understand of Saywell's requirement is that this isn't the
Internet (big 'I'). It is _an_ internet, whose topology changes shape,
albeit not too frequently. Sometimes, some parts of this internet have
links to the Internet, and so will see globally routable address
prefixes that may be propagated to all the nodes in the 'site',
meaning that every participant node in Saywell's network will (for
that time at least) have 'n' globally routable addresses from the 'n'
nodes that have links up to the Big-I.  

However, that level of connectivity is ephemeral at best, for the
target audience, as I perceive it, includes people having nodes on
dial-up lines (therefore potentially getting a different global prefix
on each connection), DSL lines, and vary rarely any form of fixed
provider (its a community networking activity, right?). Therefore, it
is *not* clear that the nodes will have any form of
known/fixed/reliable address that they can communicate with each other
internally and, given that this is a multi-link network, there is a
desire for something that looks a lot like site local addressing.

(Or have I misinterpreted the application?)

Mark/

--
"There are no stupid questions, just stupid people"
  - Mr. Garrison, South Park, CO
--------------------------------------------------------------------
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: Leif Johansson <[email-masked]>
Date: Tue, 25 Mar 2003 11:13:47 +0100

Mark Thompson wrote:

No matter how you capitalize the word, it still needs to run the same
applications! Applications must not know about topology. Period.

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 25 Mar 2003 12:00:45 +0100

> applications! Applications must not know about topology. Period.

I am also *against* Link local.

IP's should be globably unique. Which will overcome many problems
like network mergers ('oh we need to NAT now'), e2e problems etc.

They can be handy for some situations, but those situations will
impose bigger problems later on requiring strange solutions for
something which could be so simple without all of this.

If you want security -> firewall or simply don't route the block ;)

And it should be quite possible for anybody to use one /64 out of
their /48 for 'printers' and 'microwaves'. Not even talking about
refridgerators full with IPv6 beer (seen that one already :)
I would like to give those appliances globally routable IP space
simply because it would allow my printer to order new paper from
the store when it's almost out. Or better... new beer in my fridge!

Greets,
 Jeroen

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 25 Mar 2003 13:46:30 +0200

----- Original Message -----
From: "Kurt Erik Lindqvist" <[email-masked]>
To: "EricLKlein" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 25, 2003 12:07 PM
Subject: Re: A use for site local addresses?

> You can get addresses from your upstream provider.

Ok, if I understand this from a hardware (not application) point of view  a
company like IBM (or any other large company with multiple sites) will be
required to pay an upstream provider for (private) local IP addresses for
their printers. Think about it, at the hardware side of this we are
encouraging them to keep using IPv4 for those items that will not be
connected to the public internet.

Or to look at it another way, the Macintosh computers on a LAN that used to
broadcast a request for every printer on a network whenever the printer
dialogue box was opened. With no local distinctions then entire WAN will be
polled for printers, if not the entire Internet.

We need to find some way to filter or block this kind of activity.

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 25 Mar 2003 13:57:07 +0200

> like network mergers ('oh we need to NAT now'), e2e problems etc.

The new address features of IPv6 should resolve this as easily as changing
providers.

> refridgerators full with IPv6 beer (seen that one already :)

This means that every SOHO will get a /64? Or every company with 100
employees (make that about 200 nodes)?

Done this way we will be defingin IPv7 real quick, as the unused addresses
will add up very fast.

> the store when it's almost out. Or better... new beer in my fridge!

Yes, or to have the new version of SPAM sent directly to your printer rather
than you e-mail or fax.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Mar 2003 12:57:45 +0100

> connected to the public internet.

You pay your provider per traffic volume or bandwidth. Not per IP 
address. At least non I know of. They will give you as much addresses 
you need. Now if you still want to put the globally unique addresses 
behind a NAT, you are free to. But it's a bad idea. The addresses given 
to you from your provider are not private.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Mar 2003 13:01:19 +0100

>
> This is very true, but there are certain scenarios (like the network 
> I've
> described) where we have a need for a large number of addresses, which
> dont require to be globally routable (since network is self-contained).

If it is self contained, does it matter what addresses you use?

>
> If it was possible to use global addresses then I would, however rules
> regarding the IPv6 address space allocation make this a near 
> impossibility
> for us. :(

What prohibits you from getting an adequate number of addresses?

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Mar 2003 13:03:31 +0100

> Done this way we will be defingin IPv7 real quick, as the unused 

Uhm, I think you need to go and look at the numbers...:-)

The current more or less standard policy is to give out /48s, even to 
SOHOs. Each host prefix is a /64.

> Yes, or to have the new version of SPAM sent directly to your printer 

Packet filtering is not the same as NAT.

- kurtis -

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 25 Mar 2003 14:50:34 +0200

Ok, rather than beat a dead horse, let me see if I understand.
The following prefixes are no longer going to be valid as there will not be
any local addresses
Prefixes:
·         FE8, FE9, FEA, and FEB are Link local addresses
·         FEC0 is the prefix of a site local address. Site local addresses
are the equivalent of a private IPv4 address.
·         FF02::1 is address that multicasts to all nodes on the LAN.
·         FF02::2 is address that multicasts to all routers on the LAN.

Multicast Prefixes:
·         ffx1 : node-local, packets never lead the node
·         ffx2 : link-local, packets are never forwarded by routers (they
stay on the link).
·         ffx5 : site-local, packets never leave the site.
·         ffx8 : org-local, packets never leave the organization. This are
handled by routing protocols.
·         ffxe : global scope

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 25 Mar 2003 13:50:51 +0100

Kurt Erik Lindqvist [mailto:[email-masked]] wrote:

> On tisdag, mar 25, 2003, at 12:00 Europe/Stockholm, Jeroen 
> Massar wrote:
> 
> >
> Sure you did not mean site-local?

Oops, typo :)
Thanks for catching it though :)

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 25 Mar 2003 14:02:50 +0100

Kurt Erik Lindqvist wrote:

> > Ok, if I understand this from a hardware (not application) point of 
> > view  a company like IBM (or any other large company with multiple 
> > sites) will be required to pay an upstream provider for (private)
> > local IP addresses for

A company like IBM is big enough to have their own global
infrastructure and can also get a TLA as they are an ISP
for theirselves most probably. Same goes for companies like
Microsoft, Apple or non-computer related: Shell for instance.

> you need.

Welll... in IPv6 I do see that coming, fortunatly, as otherwise
the complete IPv6 bet for e2e would be futile.

In the IPv4 world you actually do pay extra for IP addresses at
least as en end-user (home etc :).

Fortunatly I do have IPv6 which makes the boxes globaly reachable :)

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 25 Mar 2003 13:58:40 +0100

EricLKlein wrote:

> The new address features of IPv6 should resolve this as 
> easily as changing providers.

Well I thought that too at first untill some people who merged
big networks clued me in :)

> employees (make that about 200 nodes)?

No a /48 per endsite. Or quoting Timothy Love (RIPE) at AIAD:
"when in doubt that a endsite will ever get more than one
subnet give them a /48"

Which boils down to give every endsite a /48, for the
ease of administration. Of course one could use one /48 or so
for giving out /64's from that.

The same as using /64's from your /48 for printers etc..

> Done this way we will be defingin IPv7 real quick, as the 
> unused addresses will add up very fast.

There should be enough, check the HD ratio RFC's.
Or Steve Deerings presentation:
http://isoc.nl/activ/2002-masterclass-IETF-IPv6.htm

> Yes, or to have the new version of SPAM sent directly to your 
> printer rather than you e-mail or fax.

Never heard of a firewall? Just like normal SPAM you should ACL
your relay's, or just don't route certain blocks etc.
Remember: NAT is not security but obscurity

Greets,
 Jeroen

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 25 Mar 2003 15:12:18 +0200

True, but they will want to keep the private network hardware on their
backbone seperate from the public traffic. I suppose that they could take
seveal /48's some for internal use and some for customer use.

Call me old fassion but it seems a bit much to have that microwave with a
registered global address.

---

From: Mike Saywell <[email-masked]>
Date: Tue, 25 Mar 2003 12:54:21 +0000

> If it is self contained, does it matter what addresses you use?

Sorry that was poorly worded.  It's self-contained in that by default
there is no default route onto the internet, however some sites may offer
free internet access by advertising a second global prefix on their node
only.  The other option for internet access is via a gateway of some sort,
which you connect to using PPPoE etc, and you get a global IP from there.
So the addresses we use on the network cant clash with anything outside.

> What prohibits you from getting an adequate number of addresses?

Well each access point is typically located in someones house, if we
go with the recommendations then that's a /48 prefix.  So looking to
the future we need a large amount of address space, but since it's a
community project we dont want to (i.e. can't) pay anything.

I should probably be campaigning for community networks in general, so
if you want all of these to have global addresses then we're probably
into the realms of a /16...

If we really wasnt to avoid site-locals then I think the location based
addressing I pointed to a while back could be a neat solution, since it
gives everybody a block of address space "automatically" and then it's
up to the site as to whether it's made globally routable - you'd have
to negotiate it with your ISP.  I'm probably biased about this though
since it ties in with my PhD work... :)

Cheers,

Mike

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 25 Mar 2003 14:21:17 +0100

Mike Saywell wrote:

> there is no default route onto the internet, however some 
> sites may offer free internet access by advertising a second
> global prefix on their node only.
> The other option for internet access is via a gateway of some sort,
> which you connect to using PPPoE etc, and you get a global IP 
> from there. So the addresses we use on the network cant clash with 
> anything outside.

Read: Internet IP's are globally unique: get IP's from your upstream.
If one defines site-local addresses there are bound to be multiple
organizations using the same 'easy to remember' prefixes.
Cause thats why some companies also NAT to eachother.
Eg company A uses 10.0.0.0/8 and company B has that too.
How not handy.

One thing which could be done is allowing the registration of say
/48's at the RIR's from a pool of address space. But that would
match up getting space from your upstream and will only create swamps.

> community project we dont want to (i.e. can't) pay anything.

So you don't pay for the hardware either or the traffic either. Bummer.
Get it from an upstream or get a good sponsor.

> If we really wasnt to avoid site-locals then I think the 
> location based addressing I pointed to a while back could be a neat 
> solution, since it gives everybody a block of address space
 "automatically" and then it's
> since it ties in with my PhD work... :)

What you need is multihoming and you are referring to something known
as GFN (Geo For Now). But that has nothing to do with using sitelocals.
That's a multihoming issue. This is also apparent as you do not intend
to have any upstream of yourselves.

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 25 Mar 2003 14:29:25 +0100

EricLKlein wrote:

Then Eric wrote this: 

> backbone seperate from the public traffic. I suppose that 
> they could take seveal /48's some for internal use and some
> for customer use.

They are their own customer, though usually big companies have
an internal venture which handles the complete network and where
the other business units are customers of that venture.

And those venture's know how a firewall work.
Quite easy: filter at the edge or as near as possible to
the prefixes as possible. I really do not see why this would
mean that there even ever would be a need for site-locals.

> Call me old fassion but it seems a bit much to have that 
> microwave with a registered global address.

Again: Firewall or don't route it along.

Btw... RFC1918 have been leaked onto the global internet too.
There was even one stupid (now bankrupt :) company which
mailed a certain technical mailinglist at a certain IX
and said they where going to announce&use 172.16/16.
They claimed it was a stupid joke played onto a newbie.
But if somebody actually would, your 'sitelocal' microwave
would be reachable. Or do you firewall? :)

Greets,
 Jeroen

PS: check RFC1855 or for example a page like:
http://www.xs4all.nl/~hanb/documents/quotingguide.html
Makes it much clearer who said exactly what.

---

From: Mike Saywell <[email-masked]>
Date: Tue, 25 Mar 2003 13:47:10 +0000

> to have any upstream of yourselves.

Sorry, I was refferring to
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt,
I think it could be considered as a way to distribute quasi-private IP
addressses and avoid clashes and thus the need for NATing when networks
join.

Getting address space from your upstream ISP does not work in every
scenario, there should really be some other mechanism for obtaining
addresses to experiment with.

Mike

---

From: Leif Johansson <[email-masked]>
Date: Tue, 25 Mar 2003 15:40:15 +0100

Mike Saywell wrote:

>I can't really see the motivations to do NAT under v6 when it's so easy
>to have multiple addresses on an interface anyway.  Joining 2 networks
>which use the same address site-local addresses would be nowhere near
>as painfull as before since it's that much easier to re-number one of
>them under v6.
>  
>
Multiple addresses means the application has to choose which to use. This is
a non-starter.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Mar 2003 15:54:40 +0100

> community project we dont want to (i.e. can't) pay anything.

Well, you still need to pay someone to get to the rest of the Internet, 
right? There is your source of addresses.

- kurtis -

---

From: Ole Troan <[email-masked]>
Date: Tue, 25 Mar 2003 15:00:58 +0000

> Multiple addresses means the application has to choose which to use. This is

IPv6 has multiple addresses anyway. or do you propose to remove
link-locals too?

/ot

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 25 Mar 2003 17:06:05 +0200

I could be wrong here (and apparently it would not be the first time on this
topic today)  but it appears to me that:

The people who are in favor of local addresses are thinking hardware
implementation.
    and
The ones against are thinking application functionality.

Is there anyone that would be willing to put together a information RFC on
this topic explaining why the WG feels that local addresses are wrong, and
how to handle both sets of requirements?

---

From: Jasminko Mulahusic <[email-masked]>
Date: Tue, 25 Mar 2003 16:53:23 +0100 (CET)

> The people who are in favor of local addresses are thinking hardware

just to be clear, we are only talking about getting rid of site-local
addresses. not link-local, or other local addresses.

jasminko

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Mar 2003 17:27:11 +0100

Eric, I can't speak for IBM's IS people, but we have been splitting
Net 9 between internal and external use for many years, without
spamming the entire Internet looking for printers. There is no reason
we would do anything different with an IPv6 prefix. It's a simple
enough matter of scoping and configuration.

On a "legal" point, the chairs promised to test the WG consensus
to deprecate site local on this list. The strong consensus in the
room last week isn't definitive; it's the consensus (or oetherwise)
on this list that counts.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Mar 2003 17:56:15 +0100

> IPv6 has multiple addresses anyway. or do you propose to remove

Multiple addresses per host are a real-world feature of IPv4 and have
always been a design goal of IPv6. 

We've already defined the default address selection algorithm (RFC 3484).
Applications are welcome to use a different algorithm, but they
don't need to, which is why the default was defined.

(RFC 3484 will need touching up, if we confirm the deprecation of
site-local.)

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 25 Mar 2003 10:49:27 -0800

> Site-locals was voted down in the WG meeting in SF.

The IETF doesn't vote ... and there is no way a decision gets made in a
meeting. It doesn't matter that a few vocal people want to remove a
capability because they don't understand it, the rules of the IETF are
that decisions are based on mail list discussions. 

Site-locals are useful exactly for the case that started this thread,
though 6to4 from the public side of each nat would also work. They are
also useful for the intermittent connected network, because internal
connections are not dropped at every connect event. Those applications
that are concerned about the potential of breaking have a clearly
defined prefix to avoid using.

Tony

---

From: Quality Quorum <[email-masked]>
Date: Tue, 25 Mar 2003 13:57:12 -0500

> that price in IPv6 as well as in IPv4.

You can uniquely map each and every local address to a combination of a
single /64 + 64-bit unique id. So, organizations who care can have static
mapping.

> you. You will get the same problems / benefits.

It would be nice to know that this block is not used for something else.

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Mar 2003 11:26:46 -0800

Eric,

> The new address features of IPv6 should resolve this as easily as 

What features are those?

> Done this way we will be defingin IPv7 real quick, as the unused 

There are a _lot_ of IPv6 routing prefixes, namely 281,474,976,710,656 
(assuming every allocation is a /48 as is the current plan (last I 
heard)).  Right now, there are about 120K routing prefixes in the 
Internet.  I think IPv7 is a ways off.

Rgds,
-drc

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Mar 2003 22:23:46 +0100

> single /64 + 64-bit unique id. So, organizations who care can have 

Or real addresses?

> It would be nice to know that this block is not used for something 
Uhm, site-local blocks will most definite be used for something else...

- kurtis -

---

From: Leif Johansson <[email-masked]>
Date: Tue, 25 Mar 2003 22:33:10 +0100

>IPv6 has multiple addresses anyway. or do you propose to remove
Link-local are used in very special cases (bootstrap for instance) which 
have to have
lots of special case handling today anyway. Not a problem.

---

From: Quality Quorum <[email-masked]>
Date: Tue, 25 Mar 2003 16:48:12 -0500

> > single /64 + 64-bit unique id. So, organizations who care can have

Yes, but I would not be surprised to see a lot of organizations selecting
private space + NAT. I do not think that there is a compelling case
to do otherwise.

Thanks,

Aleksey

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Mar 2003 23:44:38 +0100

> private space + NAT. I do not think that there is a compelling case

We have a couple of RFCs about that, but since it's tired old argument, 
let's just not go there yet again.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Mar 2003 22:14:38 -0500

> that decisions are based on mail list discussions.

Tony,

It wasn't a few vocal people.  It was an overwhelming majority.  There 
were far more people in favor of deprecating site locals at that 
meeting, than the set of people in favor of site locals even if you 
include those on the list those who weren't present at that meeting.  
It was a clear consensus of the working group.  And yes, you can make a 
decision in a face-to-face meeting if there is such overwhelming 
support for the decision at the meeting that there simply aren't enough 
people on the mailing list to affect the consensus.

> Site-locals are useful exactly for the case that started this thread,

Site-locals are useful, but the cost is too high.  The additional 
complexity that site locals add to nearly every part of the Internet - 
in apps, DNS, routing, and elsewhere - simply isn't worth the benefit.  
There are less expensive ways to provide the same functionality.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Mar 2003 22:18:10 -0500

> don't need to, which is why the default was defined.

it's one thing to allow multiple addresses per host in the 
architecture, quite another to expect hosts and apps to be able to 
tolerate different addresses with different scopes and force them to 
choose between these addresses in order to interoperate.

the default address selection algorithm will only work in a fairly 
narrow set of cases.
it's simply not the case that applications "don't need to" use a 
different algorithm.

---

From: Naiming Shen <[email-masked]>
Date: Tue, 25 Mar 2003 21:37:53 -0800

As long as we are clear that, the "site-local" does not get special
treatment in terms of routing and dns, we should care less about if
"site-local" is deprecated or still lived. It's perfectly fine and
actually somewhat useful if "site-local" plays the same role as in
IPv4 addresses defined in rfc1918.

 ] 
 ] On Tuesday, March 25, 2003, at 01:49  PM, Tony Hain wrote:
 ] 
 ] >> Site-locals was voted down in the WG meeting in SF.
 ] >
 ] > The IETF doesn't vote ... and there is no way a decision gets made in a
 ] > meeting. It doesn't matter that a few vocal people want to remove a
 ] > capability because they don't understand it, the rules of the IETF are
 ] > that decisions are based on mail list discussions.
 ] 
 ] Tony,
 ] 
 ] It wasn't a few vocal people.  It was an overwhelming majority.  There 
 ] were far more people in favor of deprecating site locals at that 
 ] meeting, than the set of people in favor of site locals even if you 
 ] include those on the list those who weren't present at that meeting.  
 ] It was a clear consensus of the working group.  And yes, you can make a 
 ] decision in a face-to-face meeting if there is such overwhelming 
 ] support for the decision at the meeting that there simply aren't enough 
 ] people on the mailing list to affect the consensus.
 ] 
 ] > Site-locals are useful exactly for the case that started this thread,
 ] 
 ] Site-locals are useful, but the cost is too high.  The additional 
 ] complexity that site locals add to nearly every part of the Internet - 
 ] in apps, DNS, routing, and elsewhere - simply isn't worth the benefit.  
 ] There are less expensive ways to provide the same functionality.
 ] 
 ] Keith
 ] 
 ] --------------------------------------------------------------------
 ] 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]
 ] --------------------------------------------------------------------

- Naiming

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 26 Mar 2003 13:05:23 +0200

> Internet.  I think IPv7 is a ways off.

Not if we are assigning 200 addresses to each user (never to be reclaimed in
many cases) They touted IPv6 as 1 address per person in the world for years
to come. Look at the future.

You will need (assumes modern western culture person other cultures may have
different requirements as defined by B. Gates):
1 address per node on your computer (all must be registered as local
addresses are going away according to the list)
1 address for your work computer + printer + other "smart" device
1 address per hand held (Palm, IPaq, etc)
1 address per cellular phone
1 address per regular phone (possibly 1 per physical extension in your
house - but I think that can be avoided)
1 address per appliance on your network - Refrigerator, dishwasher, air
conditioner, alarm system, car radio, etc (again all must be registered as
above)
 and more address as they are used.

This will make it a case of the person in 2000 who has 15 phone numbers for
their family of 4 changing to the person in 2005 who had 200 IP addresses
(or names that DNS to addresses) for their house plus 50 addresses for that
same family of 4.

Some sort of local addresses space is a must.

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 26 Mar 2003 13:07:58 +0200

> > The new address features of IPv6 should resolve this as easily as

Autoconfiguration -  IPV6 allows autoconfiguration of the devices by either
the router, DHCP server or both.

This should resolve most of the problems when merging networks, just change
the part atthe front of the /64 (or /48) address and leave the hosts the
same.

SHould work the same as changing the ISP.

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 26 Mar 2003 13:14:31 +0200

> as painfull as before since it's that much easier to re-number one of
I agree, under the autoconfigure feature you should be able to do this
easily.

Say that both networks were using the FE8::xxxx:xxxx network, then one of
them could change this to FE9::xxxx:xxxx prior to the merge, and then just
link them.

Should be a piece of cake. An alternative would be simply to go from both
being FE8::xxxx:xxxx to one being FE8:1::xxxx:xxxx and the other being
FE8:2::xxxx:xxxx  This way there would be the ability of splitting sites and
such by the thousands, and only using NAT for the public Internet
connections.

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 26 Mar 2003 13:24:01 +0200

> in apps, DNS, routing, and elsewhere - simply isn't worth the benefit.

How high is the cost of setting a standard that says the following 4
prefixes are not broadcast over the Internet? It is one short rule in all of
the systems.

> There are less expensive ways to provide the same functionality.

Could you name a few that take into account not having an ISP providing
addresses.

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 26 Mar 2003 13:26:34 +0200

> IPv4 addresses defined in rfc1918.
Or to ask it a different way, (and maybe this is the solution) will all of
the 10.x.x.x (and the other IPv4 private addresses) suddenly become globally
broadcast?

This is a bigger problem. What will an IPv6 application or hardware do with
a ::10.x.x.x address?

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 26 Mar 2003 14:11:22 +0100

> private space + NAT. I do not think that there is a compelling case

You will break a number of applications.

- kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2003 14:51:39 +0100

Keith, I haven't done an analysis, but it seems to me that deprecating
site local is a significant simplification of the scoping problem,
and thereby greatly increases the number of cases where the default
algorithm will work.

   Brian

---

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

EricLKlein wrote:

> Autoconfiguration -  IPV6 allows autoconfiguration of the 
> devices by either the router, DHCP server or both.
> 
> This should resolve most of the problems when merging 
> networks, just change the part atthe front of the /64 (or /48)
> address and leave the hosts the same.

Make that /48 as that's what every endsite should be getting at
a minimum. That's where the RFC is for.

> SHould work the same as changing the ISP.

That's what I thought too and is quite correct for a small network.
But if one is going into a larger net (>50k hosts) you will also have
the following administrativia to handle:
 - dns (forward AND reverse)
 - firewall configs
 - router configs (though one could propagate, but how secure is that)

And then we are not even talking about telling the rest of the world
that you are changing prefixes. Eg clueing in Verisign and others
that your DNS servers changed. Seeing the fact that one can't even
clue them in to make a AAAA glue in the gtld... no comment ;)

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2003 14:49:56 +0100

Eric,

There are 35,184,372,088,832 48-bit prefixes available under the current
IPv6 allocation scheme. I think that allows for a rather significant
increase in the world population before we run out, or have to use the
other 87.5% of the total address space.

Address space is certainly no argument for private addresses.

(Before anyone starts a side track, the fact that we have enough space
doesn't automatically provide an allocation scheme or routeability, but
those are separate issues.)

   Brian

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 26 Mar 2003 16:14:32 +0200

All,

I personally don't mind soo much when I am corrected publically in the list.

But I do dislike it when I get multiple copies of the replies to me or to
others. (In one case I got 4 copies of a single reply)

Please only reply to the list, not to the message originator.

Thanks,
Eric

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2003 09:33:52 -0500

> "site-local" is deprecated or still lived.

no.  this is not sufficient.   apps must not need to care about 
site-local either.  nor is it acceptable to treat site-local as a 
security mechanism.

> It's perfectly fine and

no.  rfc1918 has been a disaster.  we need to learn from past mistakes, 
not repeat them.

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2003 09:40:13 -0500

On Wednesday, March 26, 2003, at 06:24  AM, EricLKlein wrote:

> the systems

no, that doesn't work.  one reason why that doesn't work:  applications 
and DNS are not aware of site boundaries, they don't know whether they 
are broadcasting a SL address over the Internet or not.

> Could you name a few that take into account not having an ISP providing

yes, but wait until I get back from vacation.

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2003 09:42:23 -0500

> and thereby greatly increases the number of cases where the default

I haven't done the analysis either, but intuitively, I think that's 
correct.  however, I'm not confident that this is sufficient to allow 
address selection to work, at least not without identifying some other 
constraints in routing.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 26 Mar 2003 16:08:20 +0100

> Please only reply to the list, not to the message originator.

Don't mind me correcting this point publicaly then as you
will either have to fix up your Reply-To: or use a Followup-To:
header. Though Followup-To is more for usenet ofcourse most
clued email clients also know what to do with it.
Note that your client is setting the Reply-To to you explicitly.
Based upon that most clients and people will honor your 'request' :)

I quote from the headers:
8<------------------------------
Message-Id: <[email-masked]>
Reply-To: "EricLKlein" <[email-masked]>
From: "EricLKlein" <[email-masked]>
To: <[email-masked]>
------------------------------>8

So change that or don't whine about getting dupes.
There are enough ways of avoiding them (Message-ID matching f.e.).

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 26 Mar 2003 16:40:18 +0100

EricLKlein wrote:

<SNIP>
> I agree, under the autoconfigure feature you should be able to do this

Should.

> Say that both networks were using the FE8::xxxx:xxxx network, 
> then one of them could change this to FE9::xxxx:xxxx prior to the
merge, 
> and then just link them.
> 
> Should be a piece of cake. An alternative would be simply to 
> go from both being FE8::xxxx:xxxx to one being FE8:1::xxxx:xxxx and
> the other being FE8:2::xxxx:xxxx  This way there would be the ability
of 
> splitting sites and such by the thousands, and only using NAT for the
> public Internet connections.

And another Should.

I suggest you use a lab setup with at least 50k hosts on both
sides and then try and merge those networks. And please take into
account that both netadmin groups don't like each others job to
be taken over by the other folks, because 'the network was first
ours and now we have to share' and that the external parties
which administer the out-of-organization facilities aren't
cooperating very well. Oh wait you will pay them a load of money
ofcourse ;)

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 26 Mar 2003 16:32:03 +0100

EricLKlein wrote:

To keep in context this is what Naiming Shen wrote...

> > IPv4 addresses defined in rfc1918.

The complete point behind IPv6 and 128 bit addresses is that
we will get back what was once normal: End to End communication.
And for that one needs globally unique IP's.

If you imply site-locals this complete point is gone and then
one can better stay with IPv4 and one big InterNAT.

If you really want to have IP space for 'non-internet networks'
then one should talk to the RIRs and request address space for this.
This address space should then be divided in /48's and everyone who
has a requirement for IPv6 address space and has a network which is
not connected to the internet can request a /48 from that space.
This will at least enforce global uniqueness. One should note that
when one does connect to the internet this address space is futile as
a single /48 cannot be announced into the DFZ and thus it will never
ever be routable.

Site-locals imply that networks will choose 'easy to remember' addresses
and thus will cause dupes. And they won't be globally unique.

> Or to ask it a different way, (and maybe this is the 
> solution) will all of the 10.x.x.x (and the other IPv4
> private addresses) suddenly become globally broadcast?

Please define 'global broadcast'

> 
> This is a bigger problem. What will an IPv6 application or 
> hardware do with a ::10.x.x.x address?

From a NetBSD's netstat -rn output (trimmed a bit):

Internet6:
Destination       Gateway Flags Refs  Use    Mtu  Interface
::/104            ::1     UGRS    0     0  33220  lo0 =>
::/96             ::1     UGRS    0     0  33220  lo0 =>
::127.0.0.0/104   ::1     UGRS    0     0  33220  lo0
::224.0.0.0/100   ::1     UGRS    0     0  33220  lo0
::255.0.0.0/104   ::1     UGRS    0     0  33220  lo0
::ffff:0.0.0.0/96 ::1     UGRS    0     0  33220  lo0
2002::/24         ::1     UGRS    0     0  33220  lo0
2002:7f00::/24    ::1     UGRS    0     0  33220  lo0
2002:e000::/20    ::1     UGRS    0     0  33220  lo0
2002:ff00::/24    ::1     UGRS    0     0  33220  lo0

In other words: nullroute those 'special' blocks.
Same goes for RFC1918 space btw.

Afaik there is no BCP about this though.

Greets,
 Jeroen

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 26 Mar 2003 17:46:04 +0200

>Please define 'global broadcast'

Think of it as if they were now suddenly 1::10:x:x:x, valid on the public
internet, and "routable" even though they were private before. This is what
I meant by "global" probably pore phrasing, but this example should show
what I was asking.

>Same goes for RFC1918 space btw.

Then what you are saying is the RFC 1918 private spaces are still private?

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 26 Mar 2003 17:51:04 +0200

>> then one of them could change this to FE9::xxxx:xxxx prior to the merge,
>> and then just link them.
>>

>cooperating very well. Oh wait you will pay them a load of money

This is the same as the current problems. So how will you do it, have them
both convert from the v4 10 net they are using to diffrent v6 addresses, and
then they will play nice together?

Someone mentioned not wanting to put money issues in a technicial
discussion, but you have just shown that money and interpersonal issues are
also a big issue here.

These two guys who don't want to play nice will love having to convert to v6
and then merge, or changeing addresses because one of the companies is using
a diffrent ISP so needs to change their block when then merge.

Mostly I don't care what the resolution is, but we need to consider the
mergers of 200 node companies not just the 50k ones. There are a lot more
smaller than 50k networks out there than larger than 50k ones.

---

From: Mike Saywell <[email-masked]>
Date: Wed, 26 Mar 2003 16:00:09 +0000

> cooperating very well. Oh wait you will pay them a load of money

I think everybody is in agreement that in your typical IPv6 commercial
or home deployment site-locals should not be used, the point is that there
are other environments where site-locals have a legitimate use and which
(imho) there has been no reasonable proposed alternative as of yet.

Mike

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 26 Mar 2003 17:19:31 +0100

Mike Saywell wrote:

> or home deployment site-locals should not be used, the point 
> is that there are other environments where site-locals have a
legitimate 
> use and which (imho) there has been no reasonable proposed alternative
as of yet.

Name those environments then.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2003 17:23:39 +0100

EricLKlein wrote:
...
> Then what you are saying is the RFC 1918 private spaces are still private?

RFC 1918 hasn't been deprecated, if that's what you are asking.

  Brian

---

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

> I meant by "global" probably pore phrasing, but this example 

1:: ? I hope you meant what other people proposed as
2002::10.x.x.x which is just a direct map of IPv4's
RFC1918 space of which 10/8 is one of them.

> Then what you are saying is the RFC 1918 private spaces are 

Why would those become routable all of a sudden?
Better ask where boxes would actually route these
as there really are no routing entries to these places
because there are numberous organizations and individuals
using this space.

Also see RFC3056 section 5.9.

Greets,
 Jeroen

---

From: Mike Saywell <[email-masked]>
Date: Wed, 26 Mar 2003 16:38:01 +0000

> Name those environments then.

Well off the top of my head...

#1
An initially isolated ad-hoc network which is larger than a single
subnet.  The ad-hoc network may become attached to the global internet
periodically, each time via a different ISP.  One example of this could
be on a boat which only gets global connectivty whilst in port.

#2 (related)
For an ad-hoc network to auto-config it needs an address range to use.
It's extremely limiting to confine them to a single subnet.

#3 (to be found at the root of this thread)
A provider independant (i.e. no upstream ISP) network which aims to
provide transit between 2 or more networks (which may or may not be
public).

I'm sure there are many others...

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2003 17:33:04 +0100

> >> public Internet connections.

Regardless of the other comments made on this, it would be even
simpler if both sites were using global address space. You could unite
them straightforwardly using OSPF and you wouldn't need NAT. (You would need 
to unite the firewall rules as well, in any case.)

Of course, this assumes multi6 comes up with a solution, but that
is another discussion on another list.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Mar 2003 19:00:19 +0200 (EET)

> RFC1918 space of which 10/8 is one of them.

There's a caveat to using 2002:FOO (where FOO is in private address
space).  If any implementation in the network has 6to4 pseudo-interface
enabled, the packets it sends in that network will be blackholed.

Not necessarily a bad thing, but one has to be careful when proclaiming it 
as a solution.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2003 18:19:52 +0100

below...

> provide transit between 2 or more networks (which may or may not be

Any address space is private if you choose not to announce a route
to it. So any address space that you can get legitimately will
satisify these requirements. Although 6to4 space was designed for
something else, as people have pointed out, it can be used this
way, if you can't get a normal global prefix.

We may well need an allocation mechanism for PI prefixes, known to
be unrouteable in general, but that is another thread.

    Brian

---

From: David Conrad <[email-masked]>
Date: Wed, 26 Mar 2003 09:37:02 -0800

Eric,

On Wednesday, March 26, 2003, at 03:07  AM, EricLKlein wrote:
>>> The new address features of IPv6 should resolve this as easily as
>>> changing providers.
>> What features are those?

And how will autoconfiguring a particular device affect the firewall 
filters and other related configurations?  How will I be able to 
autoconfigure (say) the DNS server(s), the DHCP server(s), or the 
routers throughout the entire site's infrastructure?

> the part atthe front of the /64 (or /48) address and leave the hosts 

I suspect you are underestimating the difficulty of renumbering and  
overestimating the level of clue of people asked to do the renumbering.

Rgds,
-drc

---

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

> people on the mailing list to affect the consensus.

There are significantly more people on this list than you could fit in
one of the rooms in SF. The chairs need to raise the question on the
list, because this is not a trival issue. From reports I heard the whole
SF discussion was based on a bogus assertion that SL == NAT. 

> There are less expensive ways to provide the same functionality.

If they exist then list them. There is currently no other way to provide
disconnected sites address space. There is no other way to provide
stable internal use addresses for intermittently connected sites. There
is no other way to provide consistent consumer-simple route filtering
for local use appliances and applications. 

The cost of allowing niche applications to drive the overall
architecture is too high. The mainstream applications will be consumer
oriented plug-n-play, so the addressing architecture has to take that
into account. Yes that means some apps will have to go out of their way
to specify a global scope address, but that is not a high cost, and it
is limited to the app developer. See if you can figure out a way for
Joe-sixpack to restrict the use of some applications on a machine to
local use while others are global use, using only global addresses. For
the consumer space, the only reasonable way to make this work is to have
the restricted apps use a restricted address space that the ISPs know to
filter. 

Tony

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Mar 2003 20:05:54 +0200 (EET)

On Wed, 26 Mar 2003, Tony Hain wrote:
> list, because this is not a trival issue. 

I certainly support asking the list..

> From reports I heard the whole

.. but this is not true.  In fact, (AFAIR) few arguments centered around
the fear of NAT.  When the choice was between "limited use" and
"deprecate", I guess this argument was mentioned -- but then the question
was only about how SL is going to be "put down" (ie. which kind of message
would be sent).  People didn't see the need for RFC1918 space in IPv6.

I don't like SL myself, but I was surprised to see people wanted even more
harsh action than I had anticipated, based on the IMO dangerous direction
we went in Atlanta.

My guess would be that there was new application/operator perspective to
the dialogue, and after writing a few drafts and revisions, folks seemed
to start realizing that actually making site-locals *work* (to some
definition of "work") would be going to be *painful*.  I personally have
struggled with at least one specification (SSM multicast architecture) in
the meantime -- and if we'd have to specify the scoping treatment in all
the specs for basically everything related to routing, and even further in
applications etc., I'd probably start crying.

*Not* worth the effort.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 26 Mar 2003 19:25:02 +0100

Pekka Savola [mailto:[email-masked]] wrote:

> space).  If any implementation in the network has 6to4 
> pseudo-interface enabled, the packets it sends in that
> network will be blackholed.

Good point.

> Not necessarily a bad thing, but one has to be careful when 
> proclaiming it as a solution.

That's why I'd rather see a /32 or something out of
which organisations can request space (/48's) for
non-internet connected networks. Because the /48's
will be too scattered around the world and only /35's
or bigger are allowed in the DFZ at this moment this
would also make sure that nobody will route between
them over the global inet. But they are globally unique
which overcomes all the "we will need NAT because we are merging"
and other problems.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2003 19:48:27 +0100

Tony Hain wrote:

> ... From reports I heard the whole

I think the point was more that by eliminating a whole layer
of complexity from the scoping rules, we resolve the whole bunch
of problems generated by all the usage models for SLs.

I agree that this is orthogonal to NAT.

   Brian

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 26 Mar 2003 19:44:59 +0100

legitimate 
> periodically, each time via a different ISP.  One example of 
> this could be on a boat which only gets global connectivty whilst in
port.

That's a good example.

The boat could use a /48, at least I think most cruisers need something
similar like that size, from their office allocation.
Eg "The Boat Company" requests 2 /48's from their office upstream and
use one of them for their boat. If they have more than 200 boats they
could even go for a TLA, though I doubt you can convince a RIR
that a boat is a client and that they really need that much space.

Btw: Geographical based multihoming won't work, unless there is Sea-Geo
;)

> provide transit between 2 or more networks (which may or may not be

Effectively all these three boil down to one thing:
 - globally unique addresses
 - not connected to the internet

A place to register globally unique, but non-internet-connected
address space would be the best place IMHO.
This will take quite some effort but it is quite probably the
best way to avoid problems like mergers.

> I'm sure there are many others...

If we can't identify them, we can't have a solution for them.

Greets,
 Jeroen

---

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

Pekka Savola wrote:
> People didn't see the need for RFC1918 space in IPv6.

Just like they didn't see the need for private address space in IPv4
until there were massive deployments of whatever random numbers people
found in documents. For those who have forgotten, private address space
was not set aside to support NAT, it exists to provide space for
disconnected networks, that won't collide with existing allocations when
those attach. NAT came along later and took advantage of the existence
of private space. 

There is a need for address space for disconnected networks. If the
argument is to set aside a different set of address space and define it
as unroutable, what is the point? We already have a defined unroutable
space, what value does a different one add? Any issues that are raised
for FEC0:: will hold for whatever new space gets defined.

Tony

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 26 Mar 2003 11:05:41 -0800

> best way to avoid problems like mergers.

In the case of the cruise ship, it makes sense for the ship to
"own" a globally unique prefix. But, in the pure ad-hoc case,
all nodes are peers and may be drawn from completely unrelated
interest groups/geographies. In this case, you need to ask: "who
owns the globally unique prefix?" and "what happens if the prefix
owner goes away?". (I'm perfectly happy if these questions can be
answered w/o site-locals, BTW.)

Fred
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Wed, 26 Mar 2003 11:06:14 -0800

Eric,

> to come.

I don't think you are grasping the scale of the IPv6 address space.

A little simple math (that I'm sure I'll get wrong :-)):

According to the US Census bureau:
- Estimated world population as of 3/26/03, 17:40:10 GMT+5: 
6,282,814,548
- Estimated world population in 2050: ~9,000,000,000

Taking Brian's number (35,184,372,088,832 or 2^45) for the number of 
/48s currently available for assignment according to the RFCs today, 
you get:
- 5600 /48s per person today
- 3909 /48s per person in 2050

Note that those are /48s (each capable of addressing 64K /64s or, if 
you want ignore the autoconfiguration goop that eats the lower 64, 
1,208,925,819,614,629,174,706,176 /128s).

A bit more than 1 address per person in the world.  And that's just one 
format specifier.

(Not that this matters,  we can't even route 0.001% of Brian's number, 
but that's a rant for another time)

Arguing for site locals on the basis of conservation of address space 
is a waste of time, regardless of the validity of those arguments -- 
IPv6 address quantities are just too big.  Where private addressing 
(including site locals) could conceivably have value is:
- removing the need to deal with the address allocation 
bureaucracy/cost;
- removing concerns about provider lock-in due to costs of renumbering.

One of the downsides of site locals is the same downside you get with 
1918 space -- merge two companies using private address space and 
you'll probably have to deal with address space collisions, forcing one 
of the two to renumber.  Much easier and simpler to simply allocate 
(potentially non-routed) globally unique /48s to everybody that asks.  
Note that last sentence well.

Rgds,
-drc

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Mar 2003 21:09:27 +0200 (EET)

> for FEC0:: will hold for whatever new space gets defined.

The counter-argument to this stems from the fact that:
 1) completely disconnected networks are relatively rare, and
 2) whichever address space you use, you have to renumber *completely*
anyway, so it doesn't matter that much which one it is.  (On the other
hand, if you can avoid renumbering by NAT, it is very important you don't
clash with any existing global address space.)

For my disconnected networks (small ones, admittably), I've certainly
never bothered with FEC0::/10.  That was the observation from some other
operators as well.

As for hijacking -- that's a problem when you become non-disconnected.  A
bug wherever you're connected to.

(FWIW, I'm ok with a semi-standard address space, which is treated as
globals.  For example, the documentation prefix will probably be used to
some extent.)

---

From: Leif Johansson <[email-masked]>
Date: Wed, 26 Mar 2003 21:23:06 +0100

>SF discussion was based on a bogus assertion that SL == NAT. 
Not true. In fact non-global addresses are just as bad as NAT from an 
applications
point of view but the discussion is SF was _not_ based on a 
missunderstanding of
what sl is or isn't. At least not on my part.

       Cheers Leif

---

From: Naiming Shen <[email-masked]>
Date: Wed, 26 Mar 2003 12:21:32 -0800

] > As long as we are clear that, the "site-local" does not get special
 ] > treatment in terms of routing and dns, we should care less about if
 ] > "site-local" is deprecated or still lived.
 ] 
 ] no.  this is not sufficient.   apps must not need to care about 
 ] site-local either.

If an application choose to care about SL and non-SL, I have no
problem at all. It's not our business to discuss it here.

 ]  nor is it acceptable to treat site-local as a 
 ] security mechanism.

If they trust the SL as their security mechanism(like 99% of IPv4 users
do it today), its their problem not to use firewall, but it should not
be forbidden.

 ] 
 ] > It's perfectly fine and
 ] > actually somewhat useful if "site-local" plays the same role as in
 ] > IPv4 addresses defined in rfc1918.
 ] 
 ] no.  rfc1918 has been a disaster.  we need to learn from past mistakes, 
 ] not repeat them.

If any IP users think using rfc1918 is a disaster, again, it's their
choice to avoid them(if they can get globally routable addresses).

there are many reasons to use rfc1918 addresses, not all related to
the internet security.

 ] 

- Naiming

---

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

Naiming Shen wrote:

<SNIP>

> choice to avoid them(if they can get globally routable addresses).

If one chooses to ignore any standards it's their problem.
Which indeed is true.

> there are many reasons to use rfc1918 addresses, not all related to

Name and eloborate on them.

Greets,
 Jeroen

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Mar 2003 17:35:39 -0500

Hi Eric,

>trips for a non-customer related meeting.

Two points of clarification:

         (1) We did not "vote down" site-locals.  The chairs asked
                 for a show of hands on the issue, to allow us to
                 determine if there was WG consensus to deprecate
                 site-locals.  In the case, the chairs (Bob Hinden
                 and I) did believe that consensus was reached within
                 the room to deprecate site-locals.

         (2) Like all consensus points that are reached in meetings,
                 this issue will be checked on the mailing list.
                 Bob and I will send a formal consensus check to the
                 list shortly.

Margaret

---

From: Naiming Shen <[email-masked]>
Date: Wed, 26 Mar 2003 16:08:56 -0800

] Naiming Shen wrote:
 ] 
 ] <SNIP>
 ] 
 ] > If any IP users think using rfc1918 is a disaster, again, it's their
 ] > choice to avoid them(if they can get globally routable addresses).
 ] 
 ] If one chooses to ignore any standards it's their problem.
 ] Which indeed is true.
 ] 
 ] > there are many reasons to use rfc1918 addresses, not all related to
 ] > the internet security.
 ] 
 ] Name and eloborate on them.

some examples which are not security specific:

 - to use the same gateway address in multiple locations for devices
   like laptops, assume someone does not want to run dhcp overhead.
 - someone does not want the addresses to be global dns reachable. some
   ISPs assign private addresses on all their backbone links just for that.
   the names showing up when they do internal troubleshooting, but not in
   external domain traceroute.
 - in router/etc documentation, its nice to have diagrams showing routers
   having 10.x.x.x addresses in their configuration examples, its not
   good to put legal addresses over there.
 - of course in v4, addresses are not free.
 - its safer to use private addresses during testing, e.g. routing
   protocol testing in lab. even if you leak out those addresses by
   mistake, the chances are your peer, or upstream is filtering them,
   so the damage is minimized.

i think my point on this related to SL is that, the SL space is already
carved and well known already to everyone, what is the point to reclaim
it for "normal" use? though i'm absolutely against to have routing/dns
support to SL.

cheers.

 ] 
 ] Greets,
 ]  Jeroen
 ] 
 ] 

- Naiming

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 27 Mar 2003 01:25:11 +0100

>    like laptops, assume someone does not want to run dhcp overhead.

IPv6 also has RA, I don't see a point here. Also if you are
talking gateways then you are also quite possibly talking
about internet connected devices, thus you will need to be
globally unique.

>  - someone does not want the addresses to be global dns 
>    reachable. some ISPs assign private addresses on all
>    their backbone links just for that.
>    the names showing up when they do internal troubleshooting,
>    but not in external domain traceroute.

Use a /48 out of the ISP's /32 and use that for those backbone links.
Then even people who are outside of the network still can find out
that this address space is owned by that ISP.

As for names showing up, those can only be handy to identify them.
Otherwise either use seperate DNS's or use BIND's 'view' capability.
Ofcourse other DNS implementations might have other facilities.

>  - in router/etc documentation, its nice to have diagrams 
>    showing routers having 10.x.x.x addresses in their
>    configuration examples, its not good to put legal
>    addresses over there.

That's where 2001:db8::/32 is for.

>  - of course in v4, addresses are not free.

In IPv6 they won't be free either. If you want 'free' space just
pick some random addresses and use them. But then don't complain
that you can't route it over the internet etc.

>    so the damage is minimized.

Then don't route it to the outside. Use firewalls etc.
One could also 'forget' to filter 2001:db8::/32 or any other space.
How many IPv4 smurfamp gateways where there still on the internet?
and how many ISP's do actually filter on egress from their customers?

> i think my point on this related to SL is that, the SL space 
> is already carved and well known already to everyone, what is
> the point to reclaim it for "normal" use? though i'm absolutely
> against to have routing/dns support to SL.

I don't see any relation whatsoever to the above points.
Also IPv6 is currently still not heavily deployed and still
be carved so that problems related to SL will be gone.

Also if you don't need routing then use fe80::/10.
And what do you mean for not having SL support in DNS?
How are you going to let an application get to that host then?
Are you letting the user remember and type in a 128bits address?

And what about security specific reasons?

Greets,
 Jeroen

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Mar 2003 20:09:51 -0500

>SF discussion was based on a bogus assertion that SL == NAT.

The chairs WILL raise the question on the list...

Please be patient.  I took a couple of days off after the IETF
and Bob hasn't been feeling well, but we'll get a question out to
the list soon.

Margaret

---

From: Naiming Shen <[email-masked]>
Date: Wed, 26 Mar 2003 17:24:08 -0800

my original comment was to "rfc1918 is a disaster", and your below
reasoning is completely v6 related. i agree with you that all those
problems can be solved with different mechansims(particularly in v6
domain), but they are not necessarily easier or better than using
private addresses. more inline.

 ] Naiming Shen [mailto:[email-masked]] wrote:
 ] 
 ] >  ] Naiming Shen wrote:
 ] >  ] 
 ] >  ] <SNIP>
 ] >  ] 
 ] >  ] > If any IP users think using rfc1918 is a disaster, 
 ] > again, it's their
 ] >  ] > choice to avoid them(if they can get globally routable 
 ] > addresses).
 ] >  ] 
 ] >  ] If one chooses to ignore any standards it's their problem.
 ] >  ] Which indeed is true.
 ] >  ] 
 ] >  ] > there are many reasons to use rfc1918 addresses, not all 
 ] > related to
 ] >  ] > the internet security.
 ] >  ] 
 ] >  ] Name and eloborate on them.
 ] > 
 ] > some examples which are not security specific:
 ] > 
 ] >  - to use the same gateway address in multiple locations for devices
 ] >    like laptops, assume someone does not want to run dhcp overhead.
 ] 
 ] IPv6 also has RA, I don't see a point here. Also if you are
 ] talking gateways then you are also quite possibly talking
 ] about internet connected devices, thus you will need to be
 ] globally unique.
 ] 
 ] >  - someone does not want the addresses to be global dns 
 ] >    reachable. some ISPs assign private addresses on all
 ] >    their backbone links just for that.
 ] >    the names showing up when they do internal troubleshooting,
 ] >    but not in external domain traceroute.
 ] 
 ] Use a /48 out of the ISP's /32 and use that for those backbone links.
 ] Then even people who are outside of the network still can find out
 ] that this address space is owned by that ISP.
 ] 
 ] As for names showing up, those can only be handy to identify them.
 ] Otherwise either use seperate DNS's or use BIND's 'view' capability.
 ] Ofcourse other DNS implementations might have other facilities.
 ] 

yes, you can do it those ways, but is that easier than using the
private addresses?

 ] >  - in router/etc documentation, its nice to have diagrams 
 ] >    showing routers having 10.x.x.x addresses in their
 ] >    configuration examples, its not good to put legal
 ] >    addresses over there.
 ] 
 ] That's where 2001:db8::/32 is for.
 ] 
 ] >  - of course in v4, addresses are not free.
 ] 
 ] In IPv6 they won't be free either. If you want 'free' space just
 ] pick some random addresses and use them. But then don't complain
 ] that you can't route it over the internet etc.

again, is picking up random addresses better than using private
addresses? isn't it creating more confusing for the users?

 ] 
 ] >  - its safer to use private addresses during testing, e.g. routing
 ] >    protocol testing in lab. even if you leak out those addresses by
 ] >    mistake, the chances are your peer, or upstream is filtering them,
 ] >    so the damage is minimized.
 ] 
 ] Then don't route it to the outside. Use firewalls etc.
 ] One could also 'forget' to filter 2001:db8::/32 or any other space.
 ] How many IPv4 smurfamp gateways where there still on the internet?
 ] and how many ISP's do actually filter on egress from their customers?

i didn't mean packet filtering, rather route filtering with bgp.
as far as the ISPs i know, they all filter private addresses from
the routing level. it would be nuts to accept your peer's private
address announcements. yes, people can 'forget' to do certain things,
but it does not make it better to use random addresses.

 ] 
 ] > i think my point on this related to SL is that, the SL space 
 ] > is already carved and well known already to everyone, what is
 ] > the point to reclaim it for "normal" use? though i'm absolutely
 ] > against to have routing/dns support to SL.
 ] 
 ] I don't see any relation whatsoever to the above points.
 ] Also IPv6 is currently still not heavily deployed and still
 ] be carved so that problems related to SL will be gone.
 ] 
 ] Also if you don't need routing then use fe80::/10.
 ] And what do you mean for not having SL support in DNS?
 ] How are you going to let an application get to that host then?
 ] Are you letting the user remember and type in a 128bits address?

what i meant is no "special" treatment in routing and dns for those
addresses. of course they are still routable, otherwise it would be
a "special" treatment. sure they can be put in your local dns record,
but it can not be searched from the root domain servers.

cheers.

 ] 
 ] And what about security specific reasons?
 ] 
 ] Greets,
 ]  Jeroen
 ] 
 ] 

- Naiming

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 27 Mar 2003 02:49:11 +0100

<SNIP>

> yes, you can do it those ways, but is that easier than using the

There is a difference between randomly picking a /48 from fec0::
or picking a globally unique /48 out of space you 'own'.

And yes, dns requires configuration, but leaking private space into
the global DNS isn't what one would like to see either. Example:
A host with IPv4 10.0.0.1 and a public IPv6 address. Locally one
can reach it over IPv4 and IPv6, but when trying to get to it over
the public internet, where only the IPv6 address gets published
there are no problems either, except that you can't reach it over
IPv4 because it doesn't exist globally. Note that this is common
practice today for sites having NATed IPv4 space but global
connectivity using IPv6.

If one did publish the RFC1918 IPv4 address in DNS one is bound
to come across a local box one day, which might be a big surprise.
Eg "telnet secure.example.net 'connected to secure' password"
That is what uniquenes is all about. (yeah I know use SSH :)
And ofcourse somebody could also route your unique prefix to an
odd box if they really want to. Point in this part: never ever
publish private addresses in the global DNS.

> addresses? isn't it creating more confusing for the users?

Addresses are addresses and you do want them to be globally unique.
Or are you expecting to never ever grow and by that merge networks
with another, which might have the same space?
 
> but it does not make it better to use random addresses.

I know a couple of badly behaved ISP's which simply do not filter
because the CPU of make R and F would not be able to handle the load.
Not everyone knows what RPF does unfortunatly. Spoofed (D)DOSses also
show that quite well, because how could they spoof if the ISP filtered?
Ever did a log of RFC1918 space coming into your network, not even
talking about DNS's publishing RFC1918 space.

> but it can not be searched from the root domain servers.

With 'globaly routable' I mean that everyone on the internet would
be able to reach them. All address space is routable ofcourse.

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2003 22:06:33 -0500

On Wednesday, March 26, 2003, at 03:21  PM, Naiming Shen wrote:

> problem at all. It's not our business to discuss it here

no, you have it backwards.  the existence of SL forces apps to care 
about them.

> do it today), its their problem not to use firewall, but it should not

we can't forbid people from doing stupid things.  but neither should we 
penalize every host, every router, every application in order to allow 
people to do stupid things.

---

From: Naiming Shen <[email-masked]>
Date: Wed, 26 Mar 2003 19:41:38 -0800

] 
 ] >  ]  nor is it acceptable to treat site-local as a
 ] >  ] security mechanism.
 ] >
 ] > If they trust the SL as their security mechanism(like 99% of IPv4 users
 ] > do it today), its their problem not to use firewall, but it should not
 ] > be forbidden.
 ] 
 ] we can't forbid people from doing stupid things.  but neither should we 
 ] penalize every host, every router, every application in order to allow 
 ] people to do stupid things.
 ] 

i can't see your logic that when some hosts "stupidly" using 10.x.x.x
address, it actually penalized the hosts/applications who don't use
them. if your point is the global reachable hosts can't directly reach
those private hosts, well, that is part of the purpose to use
private addresses.

- Naiming

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2003 23:34:19 -0500

> them.

it penalizes all hosts because applications are written for the common 
case.  any app that can't work with scoped addresses has a 
substantially reduced market.  and in order to make apps work with 
scoped addresses it often requires considerably more complexity in the 
app, additional infrastructure, etc.  so even when the apps work the 
apps cost more.

>  if your point is the global reachable hosts can't directly reach

people want it both ways.  they want private hosts to be able to 
participate in apps that reach outside the local net, and they want 
those hosts to be protected from external threats.  but address scoping 
is the wrong tool for this problem.

---

From: Naiming Shen <[email-masked]>
Date: Wed, 26 Mar 2003 21:47:22 -0800

] > i can't see your logic that when some hosts "stupidly" using 10.x.x.x
 ] > address, it actually penalized the hosts/applications who don't use
 ] > them.
 ] 
 ] it penalizes all hosts because applications are written for the common 
 ] case.  any app that can't work with scoped addresses has a 
 ] substantially reduced market.  and in order to make apps work with 
 ] scoped addresses it often requires considerably more complexity in the 
 ] app, additional infrastructure, etc.  so even when the apps work the 
 ] apps cost more.

ok, but if any special routing support for SL is removed, then the only
thing left is a private address space for SL. as in ipv4 case, i'm not
aware of any application treating 10.x.x.x addr any different from the
global routable ones.

 ] 
 ] >  if your point is the global reachable hosts can't directly reach
 ] > those private hosts, well, that is part of the purpose to use
 ] > private addresses.
 ] 
 ] people want it both ways.  they want private hosts to be able to 
 ] participate in apps that reach outside the local net, and they want 
 ] those hosts to be protected from external threats.  but address scoping 
 ] is the wrong tool for this problem.
 ] 

- Naiming

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2003 01:04:35 -0500

> aware of any application treating 10.x.x.x addr any different from the

many such apps do treat 1918 addresses differently than ordinary 
addresses, in an attempt to work around problems caused by NATs.

---

From: Naiming Shen <[email-masked]>
Date: Wed, 26 Mar 2003 22:10:35 -0800

] > ok, but if any special routing support for SL is removed, then the only
 ] > thing left is a private address space for SL. as in ipv4 case, i'm not
 ] > aware of any application treating 10.x.x.x addr any different from the
 ] > global routable ones.
 ] 
 ] many such apps do treat 1918 addresses differently than ordinary 
 ] addresses, in an attempt to work around problems caused by NATs.
 ] 

then the purpose is to work around the NAT, not necessary related
to the private addresses. if for any reason, people still want to
use NAT for v6, then those applications still need to adjust. there
is no other way around it. i can understand why people hate NAT
for various reasons, but private address is not equal to NAT.

cheers.
- Naiming

---

From: "EricLKlein" <[email-masked]>
Date: Thu, 27 Mar 2003 09:20:18 +0200

> overestimating the level of clue of people asked to do the renumbering.
I suspect the list is underestimating the resistance to change that 1000's
LAN / WAN people will have to changing both their network and their way of
thinking about addresses.

We need to make it easy to swallow not just easy to code in the application
layer.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 27 Mar 2003 07:41:00 +0100

>for various reasons, but private address is not equal to NAT.
The problems related to NAT and those related to private addresses are
in most cases the same.

---

From: Naiming Shen <[email-masked]>
Date: Thu, 27 Mar 2003 00:01:14 -0800

i know of some companies employee can be fired by surfing the
Internet during work hours. i would think those employee love to
have private addresses on their workstations and no NAT devices at
all, just in case they don't "accidentally" get fired. you can
have many use of private address without NAT involved also.

cheers.

 ] Naiming Shen wrote:
 ] 
 ] > ] > ok, but if any special routing support for SL is removed, then the onl
y
 ] > ] > thing left is a private address space for SL. as in ipv4 case, i'm not
 ] > ] > aware of any application treating 10.x.x.x addr any different from the
 ] > ] > global routable ones.
 ] > ] 
 ] > ] many such apps do treat 1918 addresses differently than ordinary 
 ] > ] addresses, in an attempt to work around problems caused by NATs.
 ] > ] 
 ] >
 ] >then the purpose is to work around the NAT, not necessary related
 ] >to the private addresses. if for any reason, people still want to
 ] >use NAT for v6, then those applications still need to adjust. there
 ] >is no other way around it. i can understand why people hate NAT
 ] >for various reasons, but private address is not equal to NAT.
 ] >  
 ] >
 ] The problems related to NAT and those related to private addresses are
 ] in most cases the same.
 ] 
 ] 
 ] --------------------------------------------------------------------
 ] 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]
 ] --------------------------------------------------------------------

- Naiming

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 27 Mar 2003 12:25:07 +0100

> have many use of private address without NAT involved also.

Either do ip -6 ro add default ::1
Or disable your DNS to be able to do global lookups.
Or pull the plug from your uplink.
Or ...

This is a firewalling and more over a personal issue.
I could just as well flip out my new IPv6 Cellphone and browse
the web with that. If the employee really wants to he will.

If you don't want to get to the internet on a network just
don't route it. Nobody stated that allocated prefixes should
be routed onto the internet now did they?

I don't see any reason whatsoever why having a special address
space set aside for a reason like this could have any advantage.

Greets,
 Jeroen

---

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

On Thursday, March 27, 2003, at 01:10  AM, Naiming Shen wrote:

> to the private addresses.

no, the purpose is to work around both NAT and scoped addresses.  NAT 
imposes limitations that scoped addresses do not (because the address 
is changed in transit and because NATs typically impose limitations on 
the direction in which a communication can be established).  but scoped 
addresses impose limitations whether or not NAT is used.

> if for any reason, people still want to
> use NAT for v6, then those applications still need to adjust.

no, IPv6 needs to adjust to not use scoped addresses.

>  i can understand why people hate NAT

not equal, but similar.

Keith

---

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

> all, just in case they don't "accidentally" get fired.

so we should cripple the v6 architecture just so some brain-dead 
company can't be bothered to block port 80?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Mar 2003 18:46:04 +0100

Naiming Shen wrote:
...
> though i'm absolutely against to have routing/dns
> support to SL.

SL's have to be routed within the site anyway, and probably have to be
in local DNS to be of any use, which pretty much forces the use of two-faced 
DNS to avoid accidentally exporting them.

In other words, the only sure way to avoid routing and DNS support for SLs
is to abolish them.

   Brian

---

From: Naiming Shen <[email-masked]>
Date: Thu, 27 Mar 2003 11:15:54 -0800

] Naiming Shen wrote:
 ] ...
 ] > though i'm absolutely against to have routing/dns
 ] > support to SL.
 ] 
 ] SL's have to be routed within the site anyway, and probably have to be
 ] in local DNS to be of any use, which pretty much forces the use of two-faced
 ] DNS to avoid accidentally exporting them.
 ] 
 ] In other words, the only sure way to avoid routing and DNS support for SLs
 ] is to abolish them.

this assumes there will not be any need for private addresses in v6.
otherwise, taking a random address block has the same issue. not only
it needs two-faced DNS support, but also it could be leaked out in routing
accidentally(people after use them for a while, will think its their
legal address block; your peers will not automatically filter those
announcements), people may randomly take microsoft.com's block and can't
get their dirver updated anymore, etc. thus random block certainly is
not better than a well known address block.

but if this list is sure there is no need for private addresses, lets
abolish them completely, not just from the special routing support sense.

cheers.

 ] 
 ]    Brian

- Naiming

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Mar 2003 11:50:14 -0800

Naiming Shen wrote:
> ...
> but if this list is sure there is no need for private 
> addresses, lets abolish them completely, not just from the 
> special routing support sense.

The point is that those commenting against SL don't run a real network.
There will be filtering done in real networks. This filtering creates
addresses and/or prefixes with a local scope of applicability. IE: There
will be local scope addresses in any case. The only question is if we
have a well-known prefix that everyone filters on, or random values that
require explicit n-way coordination. This also affects applications that
might want to leverage the prior knowledge of the existence of such a
filter.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 27 Mar 2003 15:01:10 -0500

Hi Tony,

>might want to leverage the prior knowledge of the existence of such a

On the contrary, some of the pushback on site-local addressing
has been from people who run real networks.  One of the deciding
factors in the WG meeting discussion was the statement from a few
real network operators that they don't need a special prefix for
non-connected networks -- since they'll have to renumber when they
connect, anyway, they could just use a random prefix on their
disconnected networks.

There is only one reason why using a random prefix on disconnected
IPv4 networks causes problems when those networks become globally
connected -- NAT.  Folks do not choose to renumber their networks,
they use NAT instead.  And, if they've chosen a random prefix, they
won't be able to connect to outside networks that use that same prefix.

We hope to avoid this problem in IPv6, by avoiding the use of NAT.

If you accept that you will have to renumber when you move from a
disconnected state to a globally connected state, why does it matter
whether you used a well-known prefix or a random prefix before the
renumbering?

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Mar 2003 22:13:39 +0200 (EET)

> The point is that those commenting against SL don't run a real network.

I resent this statement.  There were several speakers, which I believe,
*do* run real networks.  I think I do so too.

> There will be filtering done in real networks. 

I don't think anyone disputes this.

> This filtering creates
> will be local scope addresses in any case. 

But the real question is whether these local scope addresses need to be
treated any different than the others.  IMO, the obvious answer seems to
be "no, why on earth??"

> The only question is if we
> require explicit n-way coordination. 

N-way coordination is not necessary for the disconnected case.  And when
you connect, "default deny" at your ISP will block you from using your
random block or if the ISP doesn't do it, your return packets will be
routed to some unsuspecting guy and you'll change your addresses.

I see no problem.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 27 Mar 2003 21:49:25 +0100

>*do* run real networks.  I think I do so too.
Yeah, me to. It sure feels real :-) but then maybe since I use global 
address on my
10k boxes I am not real enough... May I respectfully ask for some 
edification from
those who do run real networks?

      Cheers Leif

---

From: Mike Saywell <[email-masked]>
Date: Tue, 25 Mar 2003 11:53:19 +0000

> like network mergers ('oh we need to NAT now'), e2e problems etc.

This is very true, but there are certain scenarios (like the network I've
described) where we have a need for a large number of addresses, which
dont require to be globally routable (since network is self-contained).

If it was possible to use global addresses then I would, however rules
regarding the IPv6 address space allocation make this a near impossibility
for us. :(

Cheers,

Mike

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Mar 2003 12:54:37 +0100

- kurtis -

---

From: "Jeroen Massar" <[email-masked]>
Date: Sun, 30 Mar 2003 19:38:17 +0200

> > I am also *against* Link local.

Not that this meant site local ofcourse as rectified in another message
;)

> This is very true, but there are certain scenarios (like the 
> network I've described) where we have a need for a large
> number of addresses, which dont require to be globally
> routable (since network is self-contained).

If the network is selfcontained then you neither have to uphold
the rules of the internet relating to address usage. One could
also simply start using 3f00::/8 for your self and nobody should
complain. If you move from your self-contained network to a
internet-connected network then you are bound to renumber anyways.
There is no need to set aside numbering here and as we are talking
about a /10 here that could count up one day.

> impossibility for us. :(
> I can't really see the motivations to do NAT under v6 when 
> it's so easy to have multiple addresses on an interface
> anyway. Joining 2 networks which use the same address
> site-local addresses would be nowhere near as painfull
> as before since it's that much easier to re-number one of
> them under v6.

It isn't all that much easier in v6 than in v4 if the site
is using RA or DHCP (IPv4 has DHCP remember :) for configuring
the networks. The 'pain' in renumbering is not the routing nor
making the host get it's new prefix, it's all the databases and
other configuration items that have to renumbered too.
And I won't delve deeper into people using IP addresses in
URL's to 'speed it up a bit' ;)
But fortunatly for IPv6 the guidelines have changed there
and browsers should not support it per default.
Storing IP's in anything but DNS will cause headaches.
One will need it to locate ones nameserver though but
that should be solvable with DHCP and maybe one day
even simple RA's...

And if one is using static IPv4 it has the same pains as static IPv6.
Nothing to work around there either.

Greets,
 Jeroen