Subject: RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Sep 2003 15:12:19 +0300 (EEST)

Been busy with other stuff, but I'll respond to a few points briefly.

On Tue, 26 Aug 2003, Michel Py wrote:
> >> Doubly irrelevant to the discussion: first, you can't ask
> >> every network to become a LIR; second, the need for public
> >> addresses and local addresses is totally different, so
> >> even if one enterprise has become a LIR to obtain public
> >> addresses it does not remove the need for private ones.
> 
> > Sure, but there are also other ways to obtain addresses.
> 
> Really? Would you care naming one available today?

a) talk to your ISP (or one of its upstreams), which his hopefully a LIR, 
or 

b) talk to any LIR, and pay him e.g. 100$/mo.  He'll gladly give you
address space even though you don't want physical connectivity at all.

> > My (and others) goal is to show that the use of local
> > addressing is not the right approach in many cases, and show
> > some alternative means to achieve the same ends.
> 
> It does not work that way. First, network administrators for the most
> part don't read this. Second, you have not been an enterprise network
> administrator for any significant time so they're not going to listen to
> you anyway. Third, the reasons enterprise network administrators make
> decisions are for a significant part based on experience; in other words
> the reason to use local addresses is either because some day one did not
> use them and got shot, or because some day one did use then and it saved
> one's butt so one keeps using them. What you have is untested theories
> about network design, what they have is years of experience that built a
> sense of what works and what does not.

Well, I don't know how network managers react, but when I've been a 
network manager here, we've certainly never used private addresses in our 
network except in a few cases (from the top of my head):

 - certain routers peer with each other in access networks (using private
ASN's) using private-space addresses for iBGP sessions (assigned on
additional loopback interfaces).  At first, this was not so, but we had to
implement some visibility restrictions for IP addresses used for iBGP
because of a bug/"feature" in a major router vendor's BGP
implementation *).  We could have very well used routable, filtered at the
edge of the access network instead.

 - one inexperienced admin wanted to set up an out-of-band, privately
addressed management plane for controlling a few firewalls.  A bad idea,
so I disabused him of it.

 - private addresses are being used in our separate backup/restore and NFS
infrastructures (most hosts connected to it use separate network
interfaces etc.).  This has generated some trouble, and could be done
using different addressing model as well.

Trying to summarize what people think they need local addressing for in
enterprise scope (intermittent connectivity etc. is another beast
altogether). Some would like it to have local communications in a shared
infrastructure. A very bad idea.  Some others would like it for separate
infrastructures (like out-of-band management, NFS run on big servers,
backup/restore systems systems run on larger servers etc.).  The latter is
more easily justifiable, but I there are no fundamental gains to be had
from that approach AFAICS.  Quite the contrary.

*)

This is already offtopic, but I'll state it briefly.  Further discussion, 
if any, off-list.

iBGP advertises the loopback address A.B.C.D/32 with next-hop A.B.C.D/32.  
A.B.C.D is directly inaccessible (so there is no IGP route).  However, the
packets go and traverse through the eBGP default route, and when they
learn A.B.C.D/32 through it, start start to use it, but then the route
becomes unavailable and starts oscillating.  Possible fixes?  Enable IGP
synchronization (a non-option for most), make a check that the next-hops
of iBGP routes must exist in IGP (either OSPF/IS-IS or iBGP; eBGP would be
invalid **) -- note that one must disregard A.B.C.D/32 w/ next-hop
A.B.C.D/32 (to avoid recursion) for this process, or disallow going
through eBGP routes to reach an iBGP peer.

**) RFC1771, section 9.1.2, second last paragraph on IGP.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Sep 2003 16:33:54 +0200

Pekka Savola wrote:
...
> address space even though you don't want physical connectivity at all.

This simply doesn't fly. First of all, 100$/mo is far too much for a
small office, school etc or for every Winnebago in the USA. Free, or
$10 one-time fee, is more like it.

Secondly, even if we get past that, it's the wrong answer. If I get a
/48 from ISP A, and want to use it in "private" mode to set up VPNs
to business partners who have their public connectivity from ISPs A, B 
and C, this /48 is going to cause various forms of head scratching
for the operations people at all those business partners, and if it 
leaks, at all those ISPs. What is this /48 from ISP A doing on a site
connected to B or C, or to a different part of A? Yes, this can all 
be configured to work, but it will be a much greater source of 
operational confusion than a /48 which by inspection can be seen to
be private (not globally routeable) space.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 8 Sep 2003 12:18:28 -0400

> If I get a

well, if advertising routes to your network's PA prefixes over your own
private links is going to cause trouble, we need to fix that problem,
rather than expect those private links to use PI addresses.  because
expecting every host to use the "right" prefix based on what links 
the traffic will use simply won't work.  
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Sep 2003 19:28:36 +0300 (EEST)

> $10 one-time fee, is more like it.

It was just an example, I don't know how it would go in reality.

One time fees don't fly in this context.  They don't have the business 
model.  See the thread with Michel.

> be private (not globally routeable) space.

I don't see anything problematic that didn't happen already here.

Let's see.  Let's say the non-routed address ia "Enterprise A" /48.

ISP B or C doesn't know about Enterprise A.  They don't see it unless it 
leaks.  They only know the ISP A's aggregate.  If they try to traceroute 
to the address, it goes to ISP A, and returns ICMP network unreachable (or 
something like that).  Nothing peculiar there.

ISP A, on the other hand, knows that the prefix is non-routed.  If someone 
asks, they can tell as much.  Or even register it in RIR DB as "an 
unnumbered non-routed customer" (if they don't want to reveal more 
information on that) .. no big deal there.

The possible leakage could happen e.g. in the form of source addresses
from Enterprise A coming to any of ISPs through the business partners.  
If ingress filtering is done, this is nothing paranormal.  Packets just
get dropped, or might trigger an alarm.  If ingress filtering is not done,
nothing special will be detected anyway.  On the other hand, the business
partners would never advertise w/ BGP Enterprise A's (private) address
space; or if they tried, it would most likely be blocked by the ISP's BGP 
filtering.  But even if it wasn't, this is no weirder than advertising 
more specifics today.

The bottom line is, I don't see anything particularly disturbing here, 
especially if the special non-routable blocks are registered (at least 
anonymously or similar to domain names) in a database, like ones used 
today every day.

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 8 Sep 2003 18:43:02 +0200

-----BEGIN PGP SIGNED MESSAGE-----

> information on that) .. no big deal there.

And I bet you will get to that "prospective 200 customers" quite
easily this way, making the RIR's happy too.

Then again, just deploy a small GPRS service and you are applicable
for a /31, because you should route a /48 to an endsite which might
possibly have more than one network behind it.

Greets,
 Jeroen

---

From: Hans Kruse <[email-masked]>
Date: Mon, 08 Sep 2003 14:26:27 -0400

To me, the statement below is the core reason for wanting the non-routable 
global space, aka PUPI and GUPI.  The fact that the "local" addresses can 
be easily identified as such makes them vastly superior to hijacked 
prefixes, or even provider assigned prefixes used for "local" purposes.

> be private (not globally routeable) space.

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------