Subject: RE: apps people?

From: "Michel Py" <[email-masked]>
Date: Thu, 7 Aug 2003 20:29:30 -0700

Eliot,

> Eliot Lear wrote:
> If you look at most of the home "routers", they have more
> of a notion of "inside" and "outside" interfaces.
> Even the HOME router doesn't build an assumption along
> the lines you are discussing.  It doesn't look at the
> bits in the address field, other than to NAT permitted
> stuff through.

I regret to say that you are wrong here as what you say is mostly the
way things appear to be but not the way they really work. In at least
one example that I have seen recently myself, the router does indeed
look at the address only. A DSL/NAT box, whatever/29 on the DSL
interface, 192.168.1.1/24 on the Ethernet interface, NAT enabled, no
RFC1483 bridging. I found a host plugged a host with a public IP from
the /29 on the Ethernet interface, works fine. I agree it's crappy code,
but it does happen.

A Cisco example? here's one:

route-map ROUTE-MAP-CYMRUBOGONS permit 10
 description Filter the bogons from the Cymru.com route-server
 match community STD-COMM-LIST-CYMRU
 set ip next-hop 10.x.y.z
!
ip route 10.x.y.z 255.255.255.255 Null0 name BLACKHOLE

Question: why can't I just do:
route-map ROUTE-MAP-CYMRUBOGONS permit 10
 description Filter the bogons from the Cymru.com route-server
 match community STD-COMM-LIST-CYMRU
 set interface null0

Educated guess: because for a gazillion of reasons including existing
code and the way hardware can assist in processing the traffic, it works
by IP address and not by a more abstract concept like an interface. And
frankly, as a CCIE I prefer having to deal with the way it is today
because at least I understand what the router does, rather than a
"magic" script that would in my back transform the "set interface null0"
into "set ip next-hop 10.x.y.z" + "ip route 10.x.y.z 255.255.255.255
Null0 name BLACKHOLE" without telling me.

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

I'm not quite sure how to parse this. The peril is because there is no
architectural limitation (these addresses have public scope; if they had
restricted scope the peril would be less).

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

Agree here.

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: Eliot Lear <[email-masked]>
Date: Thu, 07 Aug 2003 21:18:59 -0700

Michel,

I was referring to the smaller devices a'la Linksys, DNET, etc.  With 
ciscos you pretty much run sed on the header if you want to- not that I 
think it's a good idea.

Eliot