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 PROTECTED] --------------------------------------------------------------------
