Subject: RE: Consensus on Site-Local Addressing

From: "Michel Py" <[email-masked]>
Date: Wed, 9 Apr 2003 20:23:09 -0700

Andrew,

>> Greg Daley wrote:
>> I'm just thinking that Ambiguity is more
>> important to get rid of than scoping.

> Andrew White wrote:
> I suppose what I'm saying is that the idea of multiple ambiguous
> overlapping 'sites' identified by some additional scoping
> mechanism (the 'full' model) was generally seen as bad.

Correct.

> If your identifiers (NRPI or otherwise) are unique enough, you
> don't need additional scope information to disambiguate them.

No, but you need additional scope (or some other kind of architectural
limitation) as a guarantee/odds lowering that these NRPI would not be
routed on the global routing table.

Michel.

--------------------------------------------------------------------
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: Greg Daley <[email-masked]>
Date: Thu, 10 Apr 2003 14:15:57 +1000

Hi Andrew,

I was actually thinking that choosing between
routable and non-routable addresses would be the
main application for scoping rules, is all.

I'm not really interested in finding out which
site is which, just that my address choice is the
right one for the job at hand.

Greg

Andrew White wrote:
 > Greg,
overlapping
 > 'sites' identified by some additional scoping mechanism (the 'full' 
model)
 > was generally seen as bad.  If your identifiers (NRPI or otherwise) are
 > unique enough, you don't need additional scope information to 
disambiguate
 > them.
 >
 > Is that clearer, or am I getting messed up in terminology again?
 >

---

From: Dan Lanciani <[email-masked]>
Date: Thu, 10 Apr 2003 18:31:33 -0400 (EDT)

Robert Elz <[email-masked]> wrote:

|For the direction of work, I have no problem, as I said.   But there's
|no need to go ripping anything out of the docs that are currently
|published RFCs until there is something ready to replace it.
|
|There's no need for that - unless there's some background assumption
|that nothing will ever be produced to replace it, but SL addresses still
|have to go anyway.

I think it is pretty clear that that is exactly the assumption made by some
"YES" voters.  Some have stated it explicitly on the grounds that the problems
solved by site-locals are not sufficiently important to require solutions in
the first place.  Others have taken a more subtle approach by claiming that
site-locals never actually solved the problems.

				Dan Lanciani
				ddl@danlan.*com

---

From: "Michel Py" <[email-masked]>
Date: Thu, 10 Apr 2003 16:07:16 -0700

Tony,

>> Michel Py wrote:
>> Or use 2002:RFC:1918, best pick after FEC0::/10

> Tony Hain wrote:
> Depends on the implementation. Some recognize that space as
> invalid since the 2002 points to the tunnel interface,

As pointed out a few days ago in a discussion with Brian Zill it is not
a good idea to automatically enable the pseudo-interface on hosts as it
breaks things.

> but 1918 is not valid on that interface.

This is a feature, not a bug.

> It would be much easier to use 2001:0DB8::/32 as site controlled
> space since implementations wouldn't know the difference between
> it and other 2001 space. Of course since everyone would be using
> the same /32, it would be just as ambiguous as the FEC0::/10
> space people are trying to get rid of. The 2001:0DB8::/32 space
> is actually worse for the purpose since it only allows 16 bits
> for local /48 coordination rather than 38.

That's why 2002:0A00::/24 is better, collision chances are one out of
16M which I can leave with opposed to 1 out of 64k.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 10 Apr 2003 18:26:23 -0700

Fred,

>>> Fred L. Templin wrote:
>>> A fundamental question here is whether the disconnected/
>>> intermittently connected networks will require subnetting
>>> internally. When subnetting is not required, link-local
>>> addressing (i.e., FE80::/10) may be enough.

>> Michel Py wrote:
>> There are many cases where these sites would indeed require
>> local subnetting.

> Is your statement based on proven fact or best current
> practices and/or

On current practices (I would not go as far as calling them best) and on
customer demands/RFPs.

There are situations like Tony's ship and more generally large habited
mobile objects, and situations such as utility companies that have
extremely large numbers of discrete (read: no human glued to the
keyboard) devices for monitoring and control of the business
(electricity, water, sewer system, etc). These sites can be extremely
large and are either intermittently connected or partially connected
(meaning only a small part of the site) to the public Internet.

> I am not trying to be critical/sarcastic; just pointing out that
> we may need to examine long-held beliefs as we find a way forward.

It is clear that _some_ of the motives behind these demands are based on
not-that-long-held beliefs, namely two of them:

1. Renumbering is a pain in the kazoo.
2. Private addresses are more secure.

Before analyzing how true these beliefs are, let me tell you that
discussing this in here is irrelevant. I am not the one writing the RFPs
and I am not going to waste time and potentially lose customers by
explaining them that they are stupid. I'll do what I can, but in the end
the customers pay and get what they want because I want them to be happy
and give me more of their business. If they want routers to be painted
pink I will paint them myself and if they want RFC1918 addresses even if
they actually own a portable class A they will get them too. You can
lead the horse to the water, but can't make it drink. Still with me?

1. Renumbering is a pain in the kazoo.
I hear American organizations telling me that they would prefer hiring
Saddam Hussein as CEO instead of renumbering their production private
network. This is based on multiple way-behind-deadline way-over-budget
catastrophes some of which (especially the kind that included a flag
day) had to be rolled back at extreme costs.

In my experience, IPv6 has not changed anything WRT this. In the cost of
renumbering a large network, the part that is about actually renumbering
devices (read: change the address on all the devices) represents 5% or
10% of the bottom line. Even if the IPv6 part of this was perfect (and
it's not) this still leaves us with 90% or 95% of a pain in the kazoo
which by all practical means is still called a pain.
Renumbering is a major pain, not a belief.

2. Private addresses are more secure.
Note that I did not say "private addresses are secure".
Some of the networks I have to deal with have anywhere from two to six
layers of firewalls between the edge and the inside of the network
(which is not the core). There are multiple access-lists and stateful
inspection all over the place.

Although it is true that private addresses can be routed over a tunnel,
this is also is a know phenomenon and protocols suitable for tunneling
are blocked or monitored. This is one of the things that is part of the
defense in depth: Make the life of the hacker complicated. Attacks are a
lot easier to detect in the inside than at the edge.

It is a well-know phenomenon (often used by security companies sales
droids) that if you plug an intrusion detection device at the edge of
the public network it will immediately scream that a dozen IPs are
trying to hack you. This is network noise; we know it and there are some
types of alarm that everyone deactivates the reason being there are so
many of them that nobody has time to investigate.

However, in the inside of the network, any blip reported by the IDS is
investigated, the reason being that there are almost none. Specifically,
any traffic to port 80 from a regulation valve is highly suspicious.
Regulation valves do not surf the web on their own. So yes, private
addresses are a plus for security because they make suspicious patterns
easier to identify and any attempt to tunnel them out not only requires
skill but will fail and will also trigger alarms all over the place.

Keep in mind: the market does not get what it wants, but it does get
what it has money to pay for and this includes private addresses whether
the IETF likes it or not.

Michel.

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 11 Apr 2003 20:26:47 +0200

Catching up..

  > >See draft-hain-ipv6-sitelocal-00.txt, the research ship 
  > example as one
  > >real case where a multi-subnet network intermittently attaches to
  > >different providers. Other vehicle types (airplanes in particular)
  > >already have multiple subnets, and will attach to 
  > different providers
  > >over time.
  > 
  > This is exactly the type of problem that the nemo working group is
  > chartered to address, so people interested in working on this
  > problem should start following the nemo group.  

=> Nemo is only interested in managing the mobility of
the entire network on the ship/plane ...etc
I believe Tony's scenarios are concerned with getting 
addresses that allow nodes inside the network to communicate
with each other without having to gain access to the Internet.
This is orthogonal to nemo really. Nemo would only kick in
once there is an Internet access and the subsequent
mobility of the network.

Hesham

---

From: Steven Blake <[email-masked]>
Date: 11 Apr 2003 14:55:06 -0400

On Wed, 2003-04-09 at 18:11, Bob Hinden & Margaret Wasserman wrote:
 
> In particular, the IPv6 WG will work to accomplish the following 
> things in parallel:

[snip]

>    (3) Update the IPv6 addressing architecture to indicate that the
>        usage of the FECO::/10 prefix for site-local addressing is
>        deprecated.  To maintain backward compatibility with existing
>        implementations the prefix should be reserved and should not
>        be allocated for other purposes.

I don't know exactly what text you have in mind for addr-arch, but if
FECO::/10 is "deprecated" in the way you describe above, it will still
remain available as a private prefix.

Unless text is added somewhere stating that routers should drop packets
with FEC0::/10 in the destination address, or we come up with another
use for FEC0::/10 (which would contradict the statement above), the
status quo hasn't changed.  So I'm not sure what all the argument is
about.

Regards,
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-9913

---

From: "Michel Py" <[email-masked]>
Date: Tue, 15 Apr 2003 09:41:19 -0700

Christian,

>>> Tony Hain wrote:
>>> Yanking the defined non-PA space will only cause them to
>>> pick random numbers, or turn the documentation space into
>>> a different instance of ambiguous space.

> Christian Schild wrote:
> Well I think actually this is even worse. Especially if people
> start to expect the same things from this 'private' address
> space as from SL.

Why wouldn't they? After all, it's based on the same RFC1918 addresses.

> SLs at least had a scope. With 2002:RFC1918 an application or
> a router has no idea that it should treat this address in a
> special way, it is just 'global aggregatable' (prefix 001).
> Imagine a few of the scenarios we draw, e.g. a disconnected
> network is going online? Using 2002:RFC1918 is much more
> dangerous than ambiguous SL's flying around.

I don't disagree. But do you have a replacement solution and if you
don't what can you do to prevent people from using them?

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 18 Apr 2003 11:38:40 -0700

> Eliot Lear wrote:
> Much of the filtering network managers do has nothing
> whatsoever to do with IP addresses and has to do with
> interfaces and ports.

This is not the reality I see everyday in the trenches.

Michel.