Block traffic sourced from 1918 space at the borders like all good providers should do and it looks more like this: 11 transit1-pos10-3.ilford.ukcore.bt.net (194.74.16.245) 105.436 ms 104.467 ms 110.371 ms 12 core2-gig3-0.ilford.ukcore.bt.net (194.74.16.111) 109.295 ms 105.359 ms 107.466 ms 13 core2-pos10-0.bletchley.ukcore.bt.net (62.6.196.221) 107.255 ms 107.344 ms 109.345 ms 14 vhsaccess1-pos8-0.bletchley.fixed.bt.net (62.6.197.138) 107.308 ms 105.954 ms 111.282 ms 15 213.120.207.222 (213.120.207.222) 107.333 ms 106.454 ms 105.460 ms 16 * * * 17 * * * 18 213.120.62.61 (213.120.62.61) 106.933 ms 109.007 ms 111.363 ms 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * --- John Fraizer EnterZone, Inc On Fri, 29 Dec 2000, Andrew Brown wrote:

speaking of rfc1918 addresses...one of my machines at home got poked at, so i did the usual thing which was perhaps waste about five minutes poking back from some place else if i feel like it. what i saw piqued my interest:

% traceroute -f12 213.123.76.29 traceroute to 213.123.76.29 (213.123.76.29), 30 hops max, 40 byte packets 12 core1-pos10-0.bletchley.ukcore.bt.net (62.6.196.217) 349.804 ms 391.793 ms 354.819 ms 13 vhsaccess1-pos7-0.bletchley.fixed.bt.net (62.6.197.134) 472.775 ms 413.810 ms 429.770 ms 14 213.120.207.218 (213.120.207.218) 288.801 ms 285.806 ms 376.831 ms 15 172.16.93.125 (172.16.93.125) 348.788 ms 383.831 ms 274.826 ms 16 172.16.93.49 (172.16.93.49) 284.805 ms 426.828 ms 869.717 ms 17 172.16.93.37 (172.16.93.37) 243.793 ms 386.818 ms 394.838 ms 18 172.16.93.1 (172.16.93.1) 399.757 ms 281.851 ms 324.813 ms 19 192.168.250.17 (192.168.250.17) 279.814 ms 315.717 ms 241.842 ms 20 213.123.76.29 (213.123.76.29) 241.812 ms 247.859 ms 193.838 ms

now i've seen people using 10.x.x.x addresses for the endpoints of the occasional serial link, but this makes it look like most of british telecom's backbone uses private addressing. i wonder what would happen to them if someone were to leak a route into them for those addresses?

-- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."

Oh, you're quite right. So, the moral of this story is: If you want your network to look right and act right, don't use 1918 space on your routers. --- John Fraizer EnterZone, Inc On Fri, 29 Dec 2000, Andrew Brown wrote:

imho, that just makes bt look even worse. now, instead of using things they shouldn't, they've got a large "broken" network.

On Fri, Dec 29, 2000 at 12:50:43PM -0500, John Fraizer wrote:

...

Block traffic sourced from 1918 space at the borders like all good providers should do and it looks more like this:

11 transit1-pos10-3.ilford.ukcore.bt.net (194.74.16.245) 105.436 ms 104.467 ms 110.371 ms 12 core2-gig3-0.ilford.ukcore.bt.net (194.74.16.111) 109.295 ms 105.359 ms 107.466 ms 13 core2-pos10-0.bletchley.ukcore.bt.net (62.6.196.221) 107.255 ms 107.344 ms 109.345 ms 14 vhsaccess1-pos8-0.bletchley.fixed.bt.net (62.6.197.138) 107.308 ms 105.954 ms 111.282 ms 15 213.120.207.222 (213.120.207.222) 107.333 ms 106.454 ms 105.460 ms 16 * * * 17 * * * 18 213.120.62.61 (213.120.62.61) 106.933 ms 109.007 ms 111.363 ms 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

--- John Fraizer EnterZone, Inc

On Fri, 29 Dec 2000, Andrew Brown wrote:

...

Oh, you're quite right. So, the moral of this story is:

If you want your network to look right and act right, don't use 1918 space on your routers.

it's not my network i'm whining about...it's bt. oh well. whatever. grr...grumble...mumble...

Andrew, It wasn't my intention to insult you. I was aware of the fact that it was BT's network (or a client of theirs). It was just a general comment. --- John Fraizer EnterZone, Inc

This is one of the benchmarks of cluelessness. The other is that the addresses don't have reverse DNS. As has been said here, many times, using RFC1918 addresses on interfaces, breaks Path MTU discovery, due to martians filters on network boundaries. Daniel Golding NetRail,Inc. "Better to light a candle than to curse the darkness" On Fri, 29 Dec 2000, Andrew Brown wrote:

speaking of rfc1918 addresses...one of my machines at home got poked at, so i did the usual thing which was perhaps waste about five minutes poking back from some place else if i feel like it. what i saw piqued my interest:

% traceroute -f12 213.123.76.29 traceroute to 213.123.76.29 (213.123.76.29), 30 hops max, 40 byte packets 12 core1-pos10-0.bletchley.ukcore.bt.net (62.6.196.217) 349.804 ms 391.793 ms 354.819 ms 13 vhsaccess1-pos7-0.bletchley.fixed.bt.net (62.6.197.134) 472.775 ms 413.810 ms 429.770 ms 14 213.120.207.218 (213.120.207.218) 288.801 ms 285.806 ms 376.831 ms 15 172.16.93.125 (172.16.93.125) 348.788 ms 383.831 ms 274.826 ms 16 172.16.93.49 (172.16.93.49) 284.805 ms 426.828 ms 869.717 ms 17 172.16.93.37 (172.16.93.37) 243.793 ms 386.818 ms 394.838 ms 18 172.16.93.1 (172.16.93.1) 399.757 ms 281.851 ms 324.813 ms 19 192.168.250.17 (192.168.250.17) 279.814 ms 315.717 ms 241.842 ms 20 213.123.76.29 (213.123.76.29) 241.812 ms 247.859 ms 193.838 ms

now i've seen people using 10.x.x.x addresses for the endpoints of the occasional serial link, but this makes it look like most of british telecom's backbone uses private addressing. i wonder what would happen to them if someone were to leak a route into them for those addresses?

-- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."

On Fri, 29 Dec 2000, Andrew Brown wrote:

they might actually have reverse dns set up for those addresses, but i, of course, have no idea what server to ask about it. :)

Perhaps IANA could set up reverses for those networks to discourage people from using them? I would guess that a few reverses with names like 192-168-1-1.danger.stupid.idiot.network.admin in a traceroute would quickly sort things out. One of the companies we work with has 192.168 address for some of the radius servers we have to talk to, we are directly connected to them so it's not a big pain but it's just so ugly. -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz Senior Network/System Admin | | Home: simon@darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

On Fri, 29 Dec 2000, Deron J. Ringen wrote:

...

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Simon Lyall Sent: Friday, December 29, 2000 3:03 PM To: nanog@merit.edu Subject: Re: RFC1918 addresses to permit in for VPN? . . One of the companies we work with has 192.168 address for some of the radius servers we have to talk to, we are directly connected to them so it's not a big pain but it's just so ugly. . . That makes perfect sense to me...there is not a better way to protect a box from a DOS/hack than to only give it a private address. Why expose a box to the outside world if there is not a need???

Deron, Ever heard of an access list? Didn't think so.

Deron J. Ringen Sr. Network Architect BellSouth Internet Services

Typical. --- John Fraizer EnterZone, Inc

On Fri, Dec 29, 2000 at 04:19:23PM -0500, Deron J. Ringen wrote:

That makes perfect sense to me...there is not a better way to protect a box from a DOS/hack than to only give it a private address. Why expose a box to the outside world if there is not a need???

For exactly this reason, people start to use the reserved address space as a security feature and think "welp, its safe now!". -- Bill Fumerola / billf@FreeBSD.org

...

That makes perfect sense to me...there is not a better way to protect a box from a DOS/hack than to only give it a private address.

this is a common fantasy. changing the its license place does not change the vulnerability of your car to an accident.

No, but putting your car on a private road that you need to circumvent several roadblocks to reach IS a pretty good deterrent to its being in an accident. D -- +---------------------+-----------------------------------------+ | dredd@megacity.org | "Conan! What is best in life?" | | Derek J. Balling | "To crush your enemies, see them | | | driven before you, and to hear the | | | lamentation of their women!" | +---------------------+-----------------------------------------+

No, but putting your car on a private road that you need to circumvent several roadblocks to reach IS a pretty good deterrent to its being in an accident.

I doubt the roadblocks are anything serious in most cases; if all you're doing is RFC1918 addressing, then source-routing on the attacker's side can probably make your box theirs in short order. Most people of this ilk I've encountered think so highly of RFC1918 addressing as a security measure that they blindly assume no other precautions are necessary. I would hope that no-one on this list would stoop to *that* level of stupidity. Presenting a "security by obscurity" argument is bad enough. Stephen

...

...

No, but putting your car on a private road that you need to circumvent several roadblocks to reach IS a pretty good deterrent to its being in an accident.

I doubt the roadblocks are anything serious in most cases; if all you're doing is RFC1918 addressing, then source-routing on the attacker's side can probably make your box theirs in short order. Most people of this ilk I've encountered think so highly of RFC1918 addressing as a security measure that they blindly assume no other precautions are necessary. I would hope that no-one on this list would stoop to *that* level of stupidity. Presenting a "security by obscurity" argument is bad enough.

Blocking source-routed packets at the borders will stop this in short order, except for those of you who peer with people who require "loose source routing". (Randy, I believe it was Verio that required this, am I mistaken?)

yes, but the sub-discussion is quite bogus. lsr is not required to get through a nat. the nat presents an outer address that maps directly to the inner address. attack the outer address directly and you have attacked the inner address. life is simple. that's all a nat does, translate addresses. again, changing your car's license plates does not make it less vulnerable to accidents. people commonly confuse nats with packet filters, stateful filters, algs, etc. of course the readers of this list would not be so easily confused. randy

Your points are valid, but when did we begin discussing NATs in this thread?

From: Randy Bush <randy@psg.com> To: "Deron J. Ringen" <djr@eng.bellsouth.net> Cc: "Simon Lyall" <simon.lyall@ihug.co.nz>, <nanog@merit.edu> Subject: RE: RFC1918 addresses to permit in for VPN? Date: Sun, 31 Dec 2000 11:29:20 -0800 > That makes perfect sense to me...there is not a better way to protect > a box from a DOS/hack than to only give it a private address. this is a common fantasy. changing the its license place does not change the vulnerability of your car to an accident. randy i figured that "protect a box from a DOS attack than to give it a private address" was natted. but you're right, my assumption could have been incorrect. apologies.

I thought that this was another discussion about using RFC 1918 address space on publicly visible interfaces.

we seem to have taken a couple of derived threads from that. and i have trouble staying polite about that disease. it seems to usually start with two delusions: o the inter-router links will take a lot of space, which /30s (and soon /31s) do not. o they are 'inside' the network so will not affect outsiders. i.e. section 3 of 1918 clearly states Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. so any isp which lets the outside world see a packet with a source in 1918 space is in direct violation of 1918.

People are afraid, without reason, of ARIN and the other RIRs

i would not say without reason. we have an entire sub-department to deal with address space acquition and assignment. the small new isp may find the process daunting, and the traditional attitude of some rirs has not always been customer friendly (this is changing at last). randy

> so any isp which lets the outside world see a packet with a source in 1918
> space is in direct violation of 1918.
...
Nevertheless, the operational reality is that having a traceroute that
shows RFC1918 addresses is more useful than a traceroute that shows
* * *, and therefore I suspect most operators will continue to permit
RFC1918 addresses into their networks as long as a few questionable
individuals use them to source traffic.

(If they even bother to think about it.)

--jhawk

Implementation at the border with a peer is another matter. On cisco one would love to use ip verify unicast reverse path but that's not going to work because of asymmetric routes.

Have you looked at "ip verify unicast source reachable-via any"? YMMV traffic-wise, but technology-wise it's supposed to address the asymmetry issue. Stephen

>> so any isp which lets the outside world see a packet with a source in 1918
>> space is in direct violation of 1918.
>...
>Nevertheless, the operational reality is that having a traceroute that
>shows RFC1918 addresses is more useful than a traceroute that shows
>* * *, and therefore I suspect most operators will continue to permit
>RFC1918 addresses into their networks as long as a few questionable
>individuals use them to source traffic.

i think it's only useful to show that (a) something's there and (b) it
doesn't slow down the traceroute.  to combat (b), mtr is your friend.

>(If they even bother to think about it.)

there would, at least, be confusion about where the packet came from.
never mind the fact that pmtud would be slightly confused if the icmp
errors came back from an rfc1918 address to a nat that was operating
or a private network that used the same address block, consider two
networks that use the same blocks of rfc1918 space for point to point
addressing on public interfaces (that, of course, don't require global
reachability) that are trying to diagnose a routing problem.  a bit of
creative route flapping and it would become impossible.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."

On Sun, 31 Dec 2000, John Hawkinson wrote:

> 
> > so any isp which lets the outside world see a packet with a source in 1918
> > space is in direct violation of 1918.
> ...
> Nevertheless, the operational reality is that having a traceroute that
> shows RFC1918 addresses is more useful than a traceroute that shows
> * * *, and therefore I suspect most operators will continue to permit
> RFC1918 addresses into their networks as long as a few questionable
> individuals use them to source traffic.
> 
> (If they even bother to think about it.)
> 
> --jhawk
> 

OK.  Poll time:

Who lets 1918 space into and/or out of their borders?  If you are and
won't admit it, I'm sure that someone will point you out.  If you aren't
(and IMHO you're wise for not doing so) please chime in and show your
HIGH level of clue!

I can attest for the following NOT allowing 1918 sourced packets into
or OUT of their networks.

EnterZone (13944)
FNSI (6259)
Completeweb (13706)
GrayBaron (14813)
Cave Network Group (17266)

(Unless someone has changed routing policy since the last time I saw the
border router configs.)


As result of naming companies with whom I am NOT an officer, I feel
obligated to post the folliwing disclaimer:

I can only attest for prefixes seen via AS13944.  I have a very close
professional relationship with the individuals in charge of routing policy
for the networks I have mentioned and as such have knowledge of their
routing policies.  I have the highest confidence that none of the above
mentioned networks have changed their routing policy in so much as to
allow packets sourced from or destined for 1918 space will make it
through.

(I am also intoxicated but not so much that I would allow 1918 space into
our out of our network. -- please check the timestamp)


---
John Fraizer
EnterZone, Inc

Blocking source-routed packets at the borders will stop this in short order, except for those of you who peer with people who require "loose source routing". (Randy, I believe it was Verio that required this, am I mistaken?)

Source-routing has more value to me as a debugging measure than RFC1918 addressing has as a security measure. Perhaps a customer network can derive some security from blocking source-routed packets, though. Stephen

I am a little lost as to what the real argument is..... Don't use RFC1918 addresses on public networks. or Don't use RFC1918 addresses on as a security measure. I don't use RF1918 address on public networks, but I do use them on my backend systems and at some level I consider it a security measure. Those backend machines don't have access to the Internet and the private addressing helps ensure that is true. Is my thinking flawed? jas -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Stephen Stuart Sent: Sunday, December 31, 2000 4:41 PM To: Derek J. Balling Cc: nanog@merit.edu Subject: Re: RFC1918 addresses to permit in for VPN?

No, but putting your car on a private road that you need to circumvent several roadblocks to reach IS a pretty good deterrent to its being in an accident.

I doubt the roadblocks are anything serious in most cases; if all you're doing is RFC1918 addressing, then source-routing on the attacker's side can probably make your box theirs in short order. Most people of this ilk I've encountered think so highly of RFC1918 addressing as a security measure that they blindly assume no other precautions are necessary. I would hope that no-one on this list would stoop to *that* level of stupidity. Presenting a "security by obscurity" argument is bad enough. Stephen

I am a little lost as to what the real argument is.....

Don't use RFC1918 addresses on public networks.

This is bad.

Don't use RFC1918 addresses on as a security measure.

I don't use RF1918 address on public networks, but I do use them on my backend systems and at some level I consider it a security measure. Those backend machines don't have access to the Internet and the private addressing helps ensure that is true. Is my thinking flawed?

Only that private addressing helps ensure that your machines don't have access to the Internet. If you've set up a network where there is truly no packet path to the Internet such that it wouldn't matter if your back-end network was numbered in RFC1918 space or not, then it becomes unlikely that the network in question will be compromised *by an attacker arriving via the Internet*, and your security does not depend on RFC1918 addressing. You will have someone walking up to a switch and plugging in to consider (but that's more a facility security issue). RFC1918 gives you a place to number hosts without conflicting with "public" address space, that's all. If you use RFC1918 addressing on connected hosts, and distribute RFC1918 prefixes in your IGP, then connecting to any part of that network's internals gives to access to its RFC1918 space. There are any number of ways this could be accomplished - attacking facility security, exploiting a poorly-secured dialup, etc. Security, in general, is about *feeling* safe, not about being safe. Some folks get a feeling of safety from RFC1918 addressing, some don't. Stephen

Using RFC1918 space also gets you an IP range where the outside world has no route to it -- Sorry, but no packets are not getting there, ergo no way to hack.

Assuming various things that should be standard procedure -- dynamic NAT as opposed to static, blocking source routing, etc.

Blocking source routing should not be standard procedure; as I stated earlier, source routing is much more valuable to me as a debugging tool than RFC1918 addressing is as a "security" tool.

At that point, just by use of simple routing, you've effectively eliminated 100% of attacks from the outside, and you only have to worry about inside. The front door is secure, now work on the back door.

100%, huh? You sure must feel safe, then. Good for you! It's a nice feeling when you have it. Stephen

Using RFC1918 space also gets you an IP range where the outside world has no route to it -- Sorry, but no packets are not getting there, ergo no way to hack. . . At that point, just by use of simple routing, you've effectively eliminated 100% of attacks from the outside, and you only have to worry about inside. The front door is secure, now work on the back door.

I know that this thread as escalated unrestrained, however this is the original point that I attempted to make. ...djr...

On Tue, 2 Jan 2001, Stephen Griffin wrote: <snip>

are trying to make. Security through obscurity is no security at all.

All other points in this monstrous thread aside, this one is wholly incorrect. Security through obscurity is nothing to depend on, but every little bit helps. Please, by all means, use a firewall, preferably several chained in an old-fashioned bastion design. Use access lists - they're your friend! Filter your routes, filter all packets not going to a valid IP/port, hell block ping and traceroute so nobody can map your network, and of course secure your servers. But when all that's done -- still don't advertise. Security through obscurity helps just that tiny extra bit. At the very least there will be less logs to pore over, 'cause script kiddies don't know who you are.

On Sun, 31 Dec 2000, Jason Lewis wrote:

I am a little lost as to what the real argument is.....

Don't use RFC1918 addresses on public networks. or Don't use RFC1918 addresses on as a security measure.

I don't use RF1918 address on public networks, but I do use them on my backend systems and at some level I consider it a security measure. Those backend machines don't have access to the Internet and the private addressing helps ensure that is true. Is my thinking flawed?

jas

Jason, As long as you do it BACK-END, meaning, no need or desire, or possibility of outside access, you're fine (IMHO). 1918 has it's place. But, as Randy has stated, it is NO guarantee of security. We use 1918 space in our network -- It's 100% test environment, unconnected, and secure. If someone breaches physical security, more power to them amd SMAME ON US! (Please, someone try! It's been a while since we've had someone at gunpoint and we're forgetting all of the lines from the Dirty Harry movies.) (Yes, we've had people at gunpoint before. I doubt they'll EVER try again.) People who use 1918 space because "they're running out of address space" or "security" IMHO, are doing themselfs a disservice. #1, have they ever heard of IP UNNUMBERED? Can save a TON of address space. And if they're that anal about their use of world-routable address space and are that tight on available addresses, I'm sure they'll be OK'd for more address space from ARIN or whoever their RIR happens to be. --- John Fraizer EnterZone, Inc

2001-01-02-09:02:37 Deron J. Ringen:

...

...

That makes perfect sense to me...there is not a better way to protect a box from a DOS/hack than to only give it a private address.

...

this is a common fantasy. changing the its license place does not change the vulnerability of your car to an accident.

True...but parking your car in a garage as opposed to on the street does make it less vulnerable to theft.

I think, based on other comments Randy made, that the real root of this particular disagreement is just terminology. Randy made other followups on this thread. One, in response to a remark similar to yours, is quite suggestive: 2000-12-31-15:40:50 Randy Bush:

that's called a firewall, or in the extreme a disconnected network, not nat.

and then a little later, in a thread on Loose Source Routing (lsr): 2000-12-31-17:02:24 Randy Bush:

lsr is not required to get through a nat. the nat presents an outer address that maps directly to the inner address. attack the outer address directly and you have attacked the inner address.

So the picture that emerges is that Randy is very definitely speaking of NAT as Bi-directional or Two-Way NAT (in the terminology of RFC 2663), where no address conservation is practiced, and machines with private addresses are directly reachable via public addresses, through a fixed incoming mapping applied by the NAT device. I'd expect that many participants in this discussion --- possibly including most of those thinking that NAT adds security --- are automatically thinking about the varient of NAT named in that RFC as Network Address Port Translation (NAPT) --- where connections can be established from private->public only, and the NAT device dynamically remaps the private [srcaddr,srcport] onto per-connection-assigned public addr/port pairs, using one (it's own) or a small number of public addresses as the target of its mapping; this is the mode that can conserve public addresses, and also provides stateful packet filtering allowing outbound-only connections. As if this weren't messy enough already, an additional complication arises because at least one NAT implementation is part of a tool frequently used as a firewall (ipchains), does NAPT only, and when doing NAPT turns from a stateless simple packet filter into a stateful packet filter, with an increase in practical security. Especially with his remark "that's called a firewall, not nat", I think it's clear that Randy sharply separates things that are doing routing functions (including NAT) from things that are enforcing security policy constraints at network traffic choke points (firewalls). And there's jargon usage to support his view, ipchains itself doesn't call it's NAPT implementation NAT, but rather Masquerading. Sadly, others of us muddy the water by using the term firewall to designate a function --- policy control and enforcement --- which can sometimes, depending on details of the desired policy and the available functionality, be actually implemented partly or even entirely by a router. Looking past the variations in usage, Randy's remarks stand very plainly and indisputably: Network Address Translation, as a routing function, implies nothing about security; and the use of private addrs which it permits would clearly add no security to the mix given Bi-directional NAT. Packet filtering, as a firewall function, can add security. The fact that one popular style of NAT pretty consistently implies a variety of packet filtering would seem to be the source of the unfortunate confusion. Now all this discussion brings to my mind a fascinating possibility. In the big recurring battle on NANOG, the topic of RFC 1918 addrs comes up because some people like using them for endpoints of point-to-point links between routers within their transit networks, and others condemn that practice, citing the urgent operational necessity to run traceroute, which requires "seeing" each interface on the path through the transit network, and the recommendation in RFC 1918 itself to filter RFC 1918 addrs at the border. The juxtaposition of these two threads, RFC1918+NAT for security and RFC 1918 link addrs, brought to my mind an interesting question. Since some folks get so outspokenly upset if they see RFC 1918 addrs in a traceroute, I wonder if it'd be possible to configure a border router to NAT those RFC 1918 addrs. Obviously this would be something you'd want to be able to switch on and off on a per-customer basis; folks who'd rather see the real assigned addrs in their traceroute output would ask for this to be left off, those who cannot abide the sight of those addrs could have it turned on, and so would see repetitions of the NAT-ting border router addr with the increasing hop count until the far edge of the net was reached. Hmm. If that NAT trick would work, it might also deal with another downside to RFC 1918 link addrs, that limits their usefulness; if a router has interfaces onto nets with different MTUs, assigning any of its interfaces an RFC 1918 addr is liable to be bad, since the RFC 1918 addr is likely to be blocked at someone's border, and that combination would cause the ICMP dest unreachable fragmentation needed packet, required by Path MTU Detection, to be dropped, making TCP connection setup fail. Perhaps NATting those RFC 1918 addrs at the border would address that problem, and so allow more extensive use of RFC 1918 addrs for router interfaces. Hmm. I doubt the brawl over RFC 1918 link addrs will ever really get settled; but at least there will be a possibility for peace soon; network operators will be able to decide whether their internal routers are in fact public servers, and if they decide they aren't, they will be able to run MPLS or something like it, something that propogates transit traffic in tunnels right across their net, and so prevents the existence of the intermediate routers from being visible even to people using custom-forged short TTLs (i.e. traceroute) to try and detect them. -Bennett