|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: RFC 1918
| I claim rather that most routers _never_ have an operational need | to talk directly to random strangers, i.e. to have their interface | addresses leak. So sure, honor RFC 1918 strictly and utterly and to | the letter: put egress filters for the addrs that would guarantee | that anyone who tried to traceroute through you would see timeouts | as the replies were blocked. If that makes whingers happier, groove | on it. If your router doesn't have any different-MTU interfaces that | it routes between, then there's no harm in using RFC 1918 addresses | on the endpoints of inter-router links. Exactly. I think Vix settled that a few years back when we had this discussion (I dont remember specifically, but I remember occasions when he chimes in, he's usually the closing argument) :-) - RFC1918 addressing on *endpoint* or leaf links, is fine. - RFC1918 addressing on transit links, isn't the best idea, but except for PMTUD (which arguably shouldn't even be, um, an argument) holds no technical reasoning(correct me if i'm wrong) to abstain. My biggest complaint is that RFC1918 addresses for the most part don't have in-addr (and if they do, it's generic) and debugging a problem based on just an IP address is hard when you're talking to cluebies at someone else's NOC. While I'm not suggesting that in-addr be created for RFC1918 specific to each provider's arbitrary allocation of IPs (this would defeat a lot of 1918) I do think that, in a global or public/enterprise network, 1918 addressing on a transit link is just a bad idea. OARnet is doing it for "security" last I talked to them (which was several years ago), they've been using RFC1918 on transit links for a while now, CIP ohio-dmz.net. -jamie
|