Subject: Re: Limiting the Use of Site-Local

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 2 Nov 2002 02:38:51 +0100

>
> => Pekka, if all the ISP's between the client in your
> picture and the detination are stupid enough
> to not ingress filter the SL source, AND the end site is
> equally as incompetent, then yes, your client will
> get there. He will never get anything back though.
>
> I'm sorry but I don't see this as a realistic or serious
> issue.
>
Then I think you will be surprised at how often this is used to today 
in attacks...

Not getting data back is not always an issue. Inserting data can be as 
bad.

- kurtis -

--------------------------------------------------------------------
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: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 2 Nov 2002 02:52:50 +0100

This list is generating email enough as it is. Could one of the chairs 
please ask the political / personal insult threads to move to a more 
appropriate mailinglist?

- kurtis -

On torsdag, okt 31, 2002, at 18:27 Europe/Stockholm, Michel Py wrote:

>>> A Monica strike is what Bill Clinton did a while ago: Make a
>>> lot of noise launching a bunch of cruise missiles at Saddam
>>> to try to get the people's attention away from the fact that
>>> he had a young lady under his desk.
>
>> If your at this upcoming IETF I would love to speak to you
>> about this statement in person OK. So lets go offline and
>> figure out when we can meet.  How about the Hard Rock Café
>> one night. I would love to delve deeper into your knowledge
>> of the inner workings of one of our Presidents. Of course I
>> will share my opinion of your statement but only to you and
>> in person just btw us ok.  Also I was not a supporter of
>> this President but he was the President. Mind if I bring a
>> couple of Gulf War Veterans I can probably locate in
>> Atlanta?
>
> Someone tells me that you need to rent a movie called "Wag the dog".
>
> Michel.
>
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 2 Nov 2002 00:47:07 -0500

Please do not send your humor directly to me.  I did not respond last time.  Next time I will just come find you and not respond to the list and find out if you have a personal problem. As I believing in helping correct those with severe personal problems when I can do that favor for them.

Lets keep it to SLs and bits at least to me in the To: list.

Sincerely,

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

> -----Original Message-----
> From: Michel Py [mailto:[email-masked]] 
> Sent: Thursday, October 31, 2002 12:28 PM
> To: Bound, Jim; Margaret Wasserman
> Cc: [email-masked]
> Subject: RE: Limiting the Use of Site-Local
> 
> 
> about this 
> > statement in person OK. So lets go offline and figure out 
> when we can 
> > meet.  How about the Hard Rock Café one night. I would love 
> to delve 
> > deeper into your knowledge of the inner workings of one of our 
> > Presidents. Of course I will share my opinion of your statement but 
> > only to you and in person just btw us ok.  Also I was not a 
> supporter 
> > of this President but he was the President. Mind if I bring a

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 2 Nov 2002 01:05:15 -0500

thanks

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

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, October 31, 2002 3:42 PM
> To: Bound, Jim
> Cc: Rob Austein; [email-masked]
> Subject: Re: Limiting the Use of Site-Local 
> 
> 
> 
> > Mark,
> > 
> > > > Please think about this for a minute.  It's bad enough for
> > > > applications that are driven by a human who can type or 
> click or 
> > > > whatever from a list of possible scopes, but what do you do for 
> > > > programs like MTAs?  If you're longing for a return to 
> the days of 
> > > > fee!fie%foe@fum email addresess (or even 
> > > [email-masked].#Chaos),
> > > > you're on the right road.
> > > 
> > > 	No Rob.
> > > 
> > > 	I'm talking about 1 name with multiple addresses being
> > > 	returned in multiple scopes.  I'm taking about having
> > > 	getaddrinfo() then filter out the inappropriate addresses
> > > 	using local knowledge and setting sin6_scope_id.
> > > 	This deals with 99.9% of address lookup.
> > 
> > We have not even agreed on what sin6_scope_ID is?  It is also now 
> > deprecated for futher study in this wg in the base API except for 
> > link-local and in the IEEE.  So how can you justify putting 
> it in the 
> > DNS except as research?  Did not we all learn from AAAAv6?
> > 
> > Can you define what you mean by "local knowledge"
> 
> 	A mapping table between scope name (in the DNS) and 
> sin6_scope_ID
> 	(being the 32 bit value that being used by the node to identify
> 	that site / link).
> 
> > How does DNS know that scope applies to the node that did the 
> > getaddrinfo if it don't know?  Which all but a few implementations 
> > know today and I have many questions for those that say they do.
> > 
> > Regards,
> > /jim
> > 
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
>

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 2 Nov 2002 14:49:55 +0100

>>> Keith, what you are saying here is that the utility
>>> company is going to have to use PA addresses, that it
>>> does not own, to configure tens of thousands of devices
>>> on thousands of subnets, and be forced to renumber
>>> if they want to switch ISPs, even though these devices
>>> have nothing to do with the public Internet, just
>>> because you don't like SLs.
>
>> Kurt Erik Lindqvist wrote:
>> ....and the day the utility company decides to outsource the
>> monitoring they will have to renumber to global addresses
>> anyway.
>
> Total nonsense.
>

Why? That would be the case i they wanted to connect - which is not 
unlikely for the future. I know cities in Sweden where building owners 
are monitoring the utilities via public connections and I know places 
where the road administration uses the public Internet for monitoring 
devices.

In you model they would use site-locals, but what happens the day they 
connect to the public Internet?

- kurtis -

---

From: Dan Lanciani <[email-masked]>
Date: Sat, 2 Nov 2002 14:44:42 -0500 (EST)

"Tony Hain" <[email-masked]> wrote:

|I do have one question about your comment, do you believe transparent
|renumbering is a sham, or did I mis-read your intent? 

I don't believe that transparent renumbering in and of itself is a sham.  I
do believe that any claim that it will be implemented soon enough and well
enough to obviate the need for stable local addresses is a sham.  I also believe
that the claim that transparent renumbering is an easier problem to solve than
portable identifiers is a sham.  IMHO, the easiest way to make transparent
renumbering work is to introduce a level of indirection.  But that's really
just the same thing as having portable identifiers.  Any other solution to
the transparent renumbering problem is going to involve pervasive changes at
all levels of the stack, and APIs to put applications in the loop.  In other
words, it can be at best transparent to the user.  This is a lot of work.

|Your point is there will be end-user-controlled address space, the only
|option we have now is SL but we only need one mechanism that meets the
|requirement.

I certainly wouldn't object to having more than one mechanism.  My concern is
that if we keep waiting for a better solution we will have no solution and
NAT will prevail.  I don't see any benefit of NAT'ed v6 over NAT'ed v4, so why
bother to change at all?

Something else that bothers me about this discussion is that while there is
endless debate around such relatively subjective (and thus highly debatable)
topics as the potential security benefits of site-locals, I have yet to see
anyone directly address basic questions like:

How do I talk to my local network pinter without renting an additional address
from my ISP?  If I rent another address for my local file server, how much
extra do I have to pay to guarantee that it won't be renumbered in the middle
of a six-hour build?  Clearly since I'm doing builds and using a file server at
all I must have a profitable business, so the ISP will be justified in demanding
that I buy at least their ``small business package'' to get such a ``feature,''
no?

There have been several vague hints that v6 has offered up a solution to v4's
(arguably artificial) address shortage, but I've yet to see anything tangible.
In fact, v6's renumbering support makes the situation that much worse for end
users in as much as it goes way beyond DHCP in giving ISPs the ability to
disrupt a network.  Remember that--with a few exceptions--ISPs are in business
to make money.  Counting or limiting addresses (and in particular, stable
addresses) as a surrogate measure of bandwidth is a very popular business model.
I've heard absolutely nothing to convince me that the business model will change
with v6.  From those that claim that global v6 address space will be cheap and
easy to get I would like to hear specific details of the new business model that
ISPs are preparing to adopt.

|> So we are coming full circle?  We have the renumbering 
|> problem because the portable address/identifier problem was 
|> declared by fiat to be too hard to even think about solving.  
|> We are stuck with site-local addressing because the 
|> renumbering problem turned out to be too difficult to solve 
|> in practice.
|
|Please explain... I understand that renumbering and static configuration
|of things like filters can be a challenge, but those are solvable given
|a reasonable time period. Is this simply a matter of an app can't
|survive a reunmbering event?

For anything other than the indirection solution, I'm afraid applications
are going to have to be involved in renumbering.  Nobody seems to be working
actively on this anymore, so the time period may well be infinite.  In fact,
I think I've seen comments in this thread that applications should not be
expected to deal with frequent renumbering.  Since it isn't clear that dealing
with one renumbering event at a bad time is any easier than dealing with
frequent renumbering events, I think this is just a euphemism for saying that
it's ok for applications to fail in the face of renumbering.  As long as the
renumbering is infrequent users are supposed to accept such infrequent failures
from the applications.  Of course, there is no reason to believe that those
renumbering events and failures will be infrequent in real life. If applications
deal with neither scopes nor renumbering we are back to NAT again.

|This is because there is a complete lack of appreciation for the
|fundemental requirement that a network manager have stable locally
|controlled address space.

This has bugged me for years.  Being a cynic, I have to think that at least
some factions appreciate the requirement and look to an artificial shortage
of such address space with a profit motive.  But once again, we know that
trying to extract too much money this way simply fuels NAT usage.  Even if
v6 is more hostile towards NAT implementation, there are some pretty clever
authors out there...

|As a slightly off topic question, do you agree with the business driver
|assertions in draft-hain-ipv6-pi-addr-use-03.txt ? We can disagree about
|the approach in the PI format, but the fundamental reasons should be
|consistent.

I'm not sure I understand the question.  What is the business aspect? I
have nothing in particular against geographic addresses, especially if
they are the only kind of routable "portable" addresses I can get.  The
big questions will be whether ISPs feel they can charge a premium for
supporting such addresses and whether there will be some other entity
who will want to collect a (possibly recurring) fee to allocate them in
the first place.  (Granted the latter will seem a bit funny.  Why should I
have to pay to allocate address space defined by the land I own?  But weirder
things have happened.)  I did notice some wording in your draft that implied
a need-based usage, e.g., for multi-homed customers.  I hope there will be
nothing to allow ISPs to classify such addresses as a premium service because
of their association with what are perceived to be activities limited to
big/rich companies.

|Non-routable global addresses are by definition local. The only thing
|they bring to the table over SL is ambiguity in the scope of
|routability.

They may help with site merger.  My only point is that they don't remove the
need to deal with scopes, so they aren't in any sense an alternative--just a
variation.  Thus the argument that we don't have to worry about scopes if we
wait for non-routable globals seems specious.

				Dan Lanciani
				ddl@danlan.*com

---

From: "Michel Py" <[email-masked]>
Date: Sat, 2 Nov 2002 17:08:33 -0800

> Margaret Wasserman wrote:
> In your model of how site-local would be used,
> will there be devices that have both site-local
> and global addresses?

There is something else about this I meant to contribute as well:
Again the short answer is no, but I am opposed to deprecation in this
situation, even though I support the idea of not having both public and
site-local enabled at the same time.

The reason is operational: If someone cross-connects two vlans or puts a
cross-over cable between a public and a site-local subnet, and
deprecation is enabled, there is a chance of network outage because of
this condition. Not good.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Sun, 3 Nov 2002 13:47:35 -0800

Hi Margaret,

> I don't understand this picture:

<------------------- Global Addresses ---------------><-- SL addr -->
+-----+
| ISP |
+--+--+
   !
+--+-------+  +----------+     +----------+     +----------+
| Router A +--+ Firewall +--+--+ Firewall +--+--+ Router B +----+
+----------+  +----------+  |  +----------+  |  +----------+    |
                            |                |                  |
                        +---+--+          +--+---+         +----+----+
                        | DFZ  |          | Host |         | Control |
                        | Host |          +------+         | Device  |
                        +------+                           +---------+
               <---------------------- Network ---------------------->

> Is "Router B" the SBR?

I don't think so.

If you re-read postings a little earlier in this thread, this was the
second time I posted this diagram, and I asked you the very same
question the first time I posted it.

This is a semantic issue we have to clarify. Please refer to the
exchange that I had with Mark Smith recently. It all depends if you
define the site as being a geographical location, the span of the IGP of
the organization,  or whatever. IMHO, the site would be more or less
what I call "network" in the diagram above. (I will skip for the moment
the discussion about Router A or half of it being part of the site or
not).

On the other hand, one's reading could also be that the part that is on
the right of Router B, with site-local addresses, is one site, and the
left side is another site with global addresses. In this case, Router B
would indeed be the SBR.

The way I read the various documents out there is that there is nothing
that says that a site can not have both global and site-local addresses.
IMHO, the SBR here should be either the outside firewall or router A.

I support the idea that a _subnet_ should not have both site-local and
global addresses, not a site. Please also read what I posted earlier
concerning deprecation.

> In this situation, why/how would "Router B" ever route any
> packets? The control device(s) will only have site-local
> addresses, so they can't send packets that will be routed
> by "Router B", nor can any systems to left of Router B
> (outside the site?) send packets to the control devices...

Here are the traffic requirements:
- The Internet can have some restricted access (http only) to the DFZ,
no more.
- The DFZ has extremely limited access to the hosts behind the inside
firewall and not at all to the control devices subnet.
- The hosts between Router B and the inside firewall can access the DFZ,
the Internet, and the control devices (generally speaking, as further
access-lists are likely to restrict this on a per-host basis).
- The control devices can talk to the subnet between Router B and the
inside firewall, no more. (same here, some access-lists will limit
this).

> What am I missing?
Nothing if Router B is the SBR, you need it to route between two sites,
which is in contradiction of what site-locals do.

However, if Router B is not the SBR and the site extends to what is
labeled "network" on the diagram, I don't see why Router B would not
route packets, because yes these packets would be routed between public
and site-local, but would stay within the site.

There have been several posts that suggest that the wording "site-local"
is terrible, which is also my opinion. There also have been posts that
suggest that a "site" is more or less the same size as the
organization's IGP or the organization's administrative boundary, which
is a little blurry but is one of the possible definitions.

Michel.

---

From: [email-masked]
Date: Mon, 4 Nov 2002 11:24:20 +0200

Hi all,

I must say that I have not been keeping up with all of the discussions,
so if I repeat something that has been discussed already & solved /
debunked, I apologize.

> However, I don't see that it offers any special security benefits
> over putting the control devices on a separate subnet of the global
> prefix and filtering that subnet in router A and the left-most
> firewall.

I understand the concept that Site Locals don't really provide additional
security, but there seems to still be some possible advantages with
respect to privacy & management that site locals bring.  For example,
may service providers do wish to provide some sort of 'network-hiding' 
- meaning that they would like to limit the visibility of their network
architecture to the outside world.  There is a belief that site-locals
could help with this.  Additionally, some types of signaling may be
completely constrained to a specific site - for example some sort
of control plane signaling for radio access networks.  Some providers
have suggested that site locals could be interesting here.  

Now, I understand that using site-locals for such a mechanism may bring
additional burdens, so going forward with a document listing benefits
and drawbacks of site locals is the way forward in my opinion.

thanks,
John

---

From: "Michel Py" <[email-masked]>
Date: Tue, 5 Nov 2002 15:34:19 -0800

>> Dan Lanciani wrote:
>> Let's say I have an Ethernet segment with 20 workstations
>> and 5 printers. I determine that two of the workstations
>> need access to the Internet so I rent 2 global addresses
>> from my ISP.

> What makes you think that you will "rent" individual
> addresses from your ISP in IPv6?  The idea is that every
> customer site should receive a /48 allocation, and
> individual nodes (at the end of point-to-point links,
> etc.) should receive a /64.
> So far, the ISPs who have deployed IPv6 (there are only a
> few right now), have been allocating a /48 or a /64 to
> every customer. And, we were successful in getting the
> 3GPP folks to change their specs to allocate a /64 to
> every cell phone...

I agree with Margaret, for a change; made the same point three hours
ago. Margaret, have you heard of significant pricing differences between
a /48 and a /64?

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 5 Nov 2002 15:56:02 -0800

>> addresses from your ISP in IPv6?

> David Conrad wrote:
> What makes you think ISPs will be interested in giving
> up revenue streams, particularly given how well they are
> (not) doing?

The revenue stream for IPv6 does not exist yet. Today, most v6 ISPs are
free, and when they finally decide to milk some money out of it,
convincing customers that they need IPv6 begins with offering a large
space.

> Do you think ISPs are charging for address space because
> it is limited?

No, they charge for address space because a) they pay for it and b) they
can bullshit the customer that it is limited.

Michel.