Subject: RE: IPv6 site-locals... end of story...

From: "Tony Li" <[email-masked]>
Date: Thu, 20 Mar 2003 12:49:26 -0800

|    Breaking news: I am told that the IPv6 WG with overwhelming
|    consensus decided to deprecate site-local addresses. Appears
|    that I left the room just 20 minutes earlier than I should
|    have ;) More details coming.

There's not that much more to say.  The chairs ARE going to poll the
WG via the mailing list, but assuming that the statistics aren't too
wildly different, it will be hard to overcome the 5:1 ratio that we
saw today.

In any case, IMHO, routing just got a bit easier today.  ;-)

Tony
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Mar 2003 17:55:03 -0500

> wildly different, it will be hard to overcome the 5:1 ratio that we

I'm aware of the headaches that site locals cause, but...
What are we going to do about the equivalent of rfc1918 addresses in ipv6?
As much as we also might find this semantically/architectually
unclean, NATs aren't going to go away, nor is private internal addressing.

(Especially at the rates the RIR's want to charge.)

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Mar 2003 17:55:03 -0500

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Mar 2003 15:38:36 -0800

>> unclean, NATs aren't going to go away, nor is private internal addressing.

    I'd assert that if people wanted to use private addresses they make sure 
    those addresses are not advertised outside of their domain. And if they
    are accidentially, their ISP should have ingress filtering enabled. Those
    addresses could be from anywhere in the address space.

    So using an FEC0::/16 prefix is not bad or should be banned, it's the 
    special treatment by routers that shouldn't be required. To a router, any
    prefix is just a longest match lookup (and this should be the case for
    anycast addresses too).

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Mar 2003 15:38:36 -0800

Dino

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 Mar 2003 17:53:00 -0800

> In any case, IMHO, routing just got a bit easier today.  ;-)

how often does that happen?

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 Mar 2003 17:53:00 -0800

---

From: Geoff Huston <[email-masked]>
Date: Sun, 23 Mar 2003 09:34:07 +1100

>unclean, NATs aren't going to go away, nor is private internal addressing.

Do what we did before private addresses were declared - use public
ones and not announce them to the routing system was a common
solution in the late 80's. It appeared to work at the time.

---

From: Geoff Huston <[email-masked]>
Date: Sun, 23 Mar 2003 09:34:07 +1100

---

From: Daniel Senie <[email-masked]>
Date: Sat, 22 Mar 2003 21:47:33 -0500

>solution in the late 80's. It appeared to work at the time.

And resulted in a major mess for many folk when networks were linked to the 
public network. How many folks had to renumber large networks out of Sun 
Microsystems' IP address space (after all, the addresses in the examples in 
the manuals used that space!).

Private address space is useful with out NAT, folks. There are network 
nodes in many places that do not need to consume public address space. 
Whether that's a back-side network between web servers and a database 
server, a network segment containing nothing but storage devices accessed 
only locally, or a network segment containing only printers, there's a good 
argument for NOT wasting public address space. In none of these cases is 
NAT employed.

Site local address space, in some fashion, has a place in this world. 
Announcements of such space to the rest of the world should not occur, and 
can be blocked by border routers, just as it should be today with the use 
of RFC1918 space.

In the zeal to deploy IPv6 and its "boundless" address space let us not 
presume to dictate the implementation strategies for private network segments.

---

From: Daniel Senie <[email-masked]>
Date: Sat, 22 Mar 2003 21:47:33 -0500

---

From: Eliot Lear <[email-masked]>
Date: Sun, 23 Mar 2003 10:26:15 -0800

Daniel Senie wrote:
> server, a network segment containing nothing but storage devices 
> accessed only locally, or a network segment containing only printers, 
> there's a good argument for NOT wasting public address space. In none of 
> these cases is NAT employed.

This belies the notion of an engineering trade-off.  There is no reason 
to create an architectural mess by saving an address here or there.  We 
have 2^128 of them to use.  Registries should see that this is the case.

> Announcements of such space to the rest of the world should not occur, 
> and can be blocked by border routers, just as it should be today with 
> the use of RFC1918 space.

The only potential legitimate use of site locals is a completely 
disconnected network and those networks tend to be quite small.

> presume to dictate the implementation strategies for private network 

Let's not engineer for corner cases, please.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 23 Mar 2003 10:26:15 -0800

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 23 Mar 2003 14:08:01 -0800

David,

You're right- the law's of physics haven't changed.  But we also don't 
live in the '80s.  Anyone doing work to convert to IPv6 should not make 
the same mistakes of the 80s by splattering IP addresses everywhere. 
Let's not make our decisions based on bad design and operational choices.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 23 Mar 2003 14:08:01 -0800

David,

Eliot

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Sun, 23 Mar 2003 18:20:30 -0800

Hi Eliot,

> Let's not make our decisions based on bad design and operational choices.

Yep. Agree with your point. But to extend on the point Daniel makes..
if we do away with the site-locals, people may come around to making
the same mistakes were done in the past, unless they are educated
about the issues that occured back in the 80s (and not all people 
associated with designing networks were around in the 80s ;-) 

Would it be useful if someone, with experience of the issues, puts a
small document ("Potential pitfalls in the absence of private address 
space"??) about the issues with no private address space and possible 
ways to work around them (or does such a document already exist??). 
This may/would help the network designers in avoiding same issues. 
IMHO, dropping the ball here and as is may result in re-opening past 
wounds!!

My 2 cents..

-Rajiv.

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Sun, 23 Mar 2003 18:20:30 -0800

Hi Eliot,

My 2 cents..

-Rajiv.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 23 Mar 2003 22:49:31 -0800

Rajiv,

Maybe some guidance is deserved.  What do you think of RFC 1627?

;-)

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 23 Mar 2003 22:49:31 -0800

Rajiv,

;-)

Eliot

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Mar 2003 09:55:02 +0100 (CET)

> the manuals used that space!).

But what's the difference between this and renumbering from site-local space
to global space when the site gets connected? I don't know of a scheme that
doesn't require renumbering the addresses/locators when a never-connected 
site gets connected.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Mar 2003 09:55:02 +0100 (CET)

Erik

---

From: "Fredrik Nyman" <[email-masked]>
Date: Mon, 24 Mar 2003 10:41:02 +0100

> Let's not make our decisions based on bad design and operational choices.

If people *use* the protocols in a way not intended by its designers, the 
designers were wrong.... You can have the best idea in the world, but 
unless people adapt to it, it is worthless. 

If it turns out that the operational people will use NAT for IPv6, then 
there is a reason for it and then it was wrong by us not to take that into 
consideration when designing the specs.

-- 
Fredrik Nyman
PacketFront Sweden AB
http://www.packetfront.com/

---

From: "Fredrik Nyman" <[email-masked]>
Date: Mon, 24 Mar 2003 10:41:02 +0100

---

From: David Conrad <[email-masked]>
Date: Sat, 22 Mar 2003 22:55:43 -0800

Daniel,

On Saturday, March 22, 2003, at 06:47  PM, Daniel Senie wrote:
> And resulted in a major mess for many folk when networks were linked 
> to the public network.

The people who used _registered_ public address space, of course, did 
not run into a mess.

Of course, these were the bogs that became the IPv4 swamp, but there 
was plenty of address space at the time...

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Sat, 22 Mar 2003 22:55:43 -0800

Daniel,

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Sun, 23 Mar 2003 11:48:50 -0800

Elliot,

On Sunday, March 23, 2003, at 10:26  AM, Eliot Lear wrote:
> This belies the notion of an engineering trade-off.  There is no 
> reason to create an architectural mess by saving an address here or 
> there.

Who cares about individual addresses?  It is the prefixes entering (and 
exiting) the routing system that matter.

> We have 2^128 of them to use.

This is equivalent to saying IPv4 has 2^32 addresses to use.  While 
arguably true, it is irrelevant   From a routing perspective, we have 
at best 2^64 individually routable objects.  In reality, we have less 
as we have been eating from both sides of the routing prefix space 
(e.g., format specifier, local site routing goop, etc).

> Registries should see that this is the case.

Last I heard, using the current allocation approach we theoretically 
have 281,474,976,710,656 potential routing prefixes.  Given we have so 
many, there are some who believe we should go back to the "get a public 
prefix from the registries even if you don't plan on connecting that 
prefix to the Internet" approach used back in the early days.  Solves 
the private address space problem of merging companies nicely.

Unfortunately, of course, without a revolutionary advance in 
renumbering or routing, this approach _guarantees_ IPv6 NAT when ISPs 
start worrying about their IPv6 routing tables.

 From a routing perspective, folks should get their v6 prefix from their 
upstream service provider(s).  However, again without a revolutionary 
advance in renumbering or routing, this approach also guarantees IPv6 
NAT as very few companies like to be held hostage by their address 
space.

Seems to me the choice is whether or not we want to consume some of the 
281,474,976,710,656 prefixes for networks that will, in the end, be 
NAT'ed.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Sun, 23 Mar 2003 11:48:50 -0800

Elliot,

Rgds,
-drc

---

From: Jing Shen <[email-masked]>
Date: Tue, 25 Mar 2003 11:01:54 +0800

Hi,

> disconnected network and those networks tend to be quite small.

I do not agree with this at all. As an example, our university use
10.0.0.0/8 as campus network address spac. The network convers four
campus located in 6 places in HangZhou city. We have more than
40,000 students, and every student domitory room has been or is being 
connected to the campus network; there are also hundreds of labs and
public
service computers ( our lab is not a big one, but we have more than 150
computers)
; besides this, in order to enable resource sharing, this campus network
 also covers some residential areas where staffs of the university live. 

The network connects to CERNET and ChinaNet by proxy servers and NAT.

-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Jing Shen <[email-masked]>
Date: Tue, 25 Mar 2003 11:01:54 +0800

Hi,

-- 
Jing Shen

State Key Lab of CAD&CG

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Mar 2003 22:06:33 -0500

In message <[email-masked]>, David Conrad wri
> start worrying about their IPv6 routing tables.

I remember renumbering 140.222, a fairly well known prefix in its day
into a subnet of a /13 (I think it was 204.148/13).  140.222 had an
enterprise with 3 main locations, two network operation centers, and a
national backbone.  This was entirely voluntary since the same
organization had the old class B and the /13.

Another way of thinking of this is IPv6 renumbering has to be at least
as good as 1996 technology where you didn't do anything incredibly
stupid when you set up the network in the first place (like security
based on IP addresses or numeric addresses in various configuration
files, except machine generated router configuration files).

It helps if all your host support address aliasing on their interfaces
for smooth transition with two sets of numbers on all of the
interfaces at some point.  I understand some IPv4 devices still don't
support this and therefore are below 1996 standards of competence.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Mar 2003 22:06:33 -0500

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Mar 2003 22:29:34 -0500

> The network connects to CERNET and ChinaNet by proxy servers and NAT.

I think University of Michigan in Ann Arbor was larger in terms of
campus size and network size and geographic dispersion a decade ago
and if you count all of Michnet, was much larger in terms of
geographic dispersion.  They didn't need NAT (NAT hadn't even been
invented yet).

The fact that you have a large network and used a NAT does not prove
that you needed a NAT.

If you have a NAT you are not a completely disconnected network, you
are connected to the rest of the world via the NAT (just in case that
was the point you were trying to make).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Mar 2003 22:29:34 -0500

Curtis

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Mon, 24 Mar 2003 19:40:41 -0800

Hi Eliot,

> Maybe some guidance is deserved.  What do you think of RFC 1627?

Hmmm... you're about 10 yrs ahead in time ;-)

Anyway, I did go thru the document, and two main comments I had
are:

1. The document might need to be updated to address current issues.
   For e.g. while it opposes the RFC 1597 request for private
   address space, we do know that RFC 1918 did in fact make private
   addresses a reality, we mention problems in the interconnection
   of two organizations with identical private address space, while
   NAT (with it's known issues) seems to have been the answer to 
   that question.

2. Much as we may dislike the use of private addresses (and a lot of
   debate has focussed on this topic in the last few days, maybe even
   hours), there is nothing in the IP(v6) architecture that disallows
   this. And people may/will continue to use it, for various reasons
   - maybe monetary, maybe (pseudo) security whatever. Or maybe a few
   years down the line we discover that the IPv6 address space isn't
   sufficient!! IMHO, the best we can do (other than mandating 
   otherwise) is to recommend that private addresses not be used, 
   and if they are used (for whatever reasons), the associated 
   issues (which might need to be elucidated) be kept in mind. 

-Rajiv.

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Mon, 24 Mar 2003 19:40:41 -0800

Hi Eliot,

-Rajiv.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 24 Mar 2003 20:57:49 -0800

Rajiv,

I think what I was saying is that this argument is really old.  Even 
back when we wrote 1627 we said then that DHCP was coming down the line, 
although we didn't fully understand IPv6 autoconfig.  Perhaps we would 
do well to delve into this from the directions of prefix delegation and 
identifier/locater split (see recent multi6 discussion).  That would 
*really* put the nail in ANY -- ANY -- argument for site locals...

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 24 Mar 2003 20:57:49 -0800

Rajiv,

Eliot

---

From: Jing Shen <[email-masked]>
Date: Tue, 25 Mar 2003 17:09:03 +0800 (CST)

>The fact that you have a large network and used a NAT does not prove

I do not state that as sample on supporting NAT, but to the fact that private addresses are used in large network, but not small networks.

The reason why I think it's reasonable to reserve a private address block is it's easy to be understanded and those information could be easily filtered out when advertising routing information. ( think about such a situation: we use 13.1.1.23 as internal address, while we try to access 13.1.1.23 from 13.1.1.23 ).

I think NAT is useful when someone tries to protect its internal network while providing good connection ( although there do exist some problems). 

regards

Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China

---------------------------------
Do You Yahoo!?
"雅虎通网络KTV, 随时随地免费卡拉OK~~"

---

From: Jing Shen <[email-masked]>
Date: Tue, 25 Mar 2003 17:09:03 +0800 (CST)

regards

Jing Shen

State Key Lab of CAD&CG

---

From: "Fredrik Nyman" <[email-masked]>
Date: Tue, 25 Mar 2003 10:54:05 +0100

> The fact that you have a large network and used a NAT does not prove

Weather people need or do not need NAT is really not the issue. The issue is if people 
*want* to use NAT. If they do, you'd better accept it.

There is clearly needs for private address space (or similar) and possibly also NAT in an 
IPv6 world. Why? Because people are used to it by now. People have learned to use private 
address space. It will be many years before people unlearn.

I agree that there are many valid arguments how NAT break peer-to-peer, multicast and 
other functionality and I'd prefer a NAT-free world. But I don't get to decide that. The 
users do.

Since the argument is that there is enough IPv6 address space to go around, what is the 
harm of allocating a piece of it and call it private address space?

In time, people will discontinue the use of NATs and private address space if there are 
real reasons for it such as "killer applications" that simply do not work with address 
translation. Perhaps we should focus our efforts on that instead of arguing about a small 
piece of eternity?

---

From: "Fredrik Nyman" <[email-masked]>
Date: Tue, 25 Mar 2003 10:54:05 +0100

---

From: Roland Bless <[email-masked]>
Date: Tue, 25 Mar 2003 11:03:38 +0100

Hi,

[email-masked] said:
> The reason why I think it's reasonable to reserve a private address
> block is it's easy to be understanded and those information could be
> easily filtered out when advertising routing information. ( think
> about such a situation: we use 13.1.1.23 as internal address, while we
> try to access 13.1.1.23 from 13.1.1.23 ).

> I think NAT is useful when someone tries to protect its internal
> network while providing good connection ( although there do exist some
> problems). 

Private adressing does not add any protection or security!!
The ONLY reason to use NAT was the lack of enough addresses.
This reason is thus not applicable for IPv6.
You can achieve the same security with appropriate filter settings
for "normal" addresses.

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked] WWW: http://www.tm.uka.de/~bless
Institute of Telematics, University of Karlsruhe, Germany

---

From: Roland Bless <[email-masked]>
Date: Tue, 25 Mar 2003 11:03:38 +0100

Hi,

Regards,
 Roland

---

From: Jing Shen <[email-masked]>
Date: Tue, 25 Mar 2003 22:06:09 +0800 (CST)

Hi,

>or "normal" addresses.

why? how could we mask private network strucuture from outside?  

thanks 

regards

Jing Shen

State Key Lab of CAD&CG

---

From: Jing Shen <[email-masked]>
Date: Tue, 25 Mar 2003 22:06:09 +0800 (CST)

Hi,

thanks 

regards

Jing Shen

State Key Lab of CAD&CG

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Mar 2003 11:24:22 -0500

In message <[email-masked]>, Roland Bless wri
> You can achieve the same security with appropriate filter settings

There is clearly widespread ignorance of this fact.  In many contexts
such as discussion of corporate through K-12 school infrastructures,
I've heard NAT mentioned as a security measure.  It adds no real
security at all.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Mar 2003 11:24:22 -0500

Curtis

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Mar 2003 11:03:09 -0800

Roland,

> Private adressing does not add any protection or security!!

Not quite true.  It isn't something that you can rely on, but it does 
raise the barrier somewhat.  When there are hundreds of sites out there 
running unpatched old versions of BIND or IIS or whatever on the public 
Internet, why waste your time breaking through a NAT box?

> The ONLY reason to use NAT was the lack of enough addresses.

No.  Another reason is that companies do not want to be held hostage 
due to the cost of renumbering which many would feel would be the case 
should they want to change providers.

> This reason is thus not applicable for IPv6.

No.  IPv6 uses provider based addressing, thus if you want the routing 
system to scale, you must renumber if you change providers.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Mar 2003 11:03:09 -0800

Roland,

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Mar 2003 11:06:32 -0800

Fredrik,

> harm of allocating a piece of it and call it private address space?

People using the same addresses for private address space (a la 10/8) 
make companies merging painful.  If people aren't concerned about the 
inefficiencies of allocating address space that will not be routed, it 
would be much better for folks to get globally unique addresses.  The 
problem is, people make this assumption that if it is globally unique 
it _will_ (not just _can_) be routed when presented to a service 
provider.  Hence, the swamp.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Mar 2003 11:06:32 -0800

Fredrik,

Rgds,
-drc

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Mar 2003 14:18:57 -0500

In message <[email-masked]>, Jing Shen 
writes:
> --0-539720083-1048601169=:92214
> Content-Type: text/plain; charset=gb2312
> Content-Transfer-Encoding: 8bit
> 
> 
> Hi,

You number all of your servers that you want to have access to the
outside world in a subnet and filter to the rest.  It is more common
to allow only certain services to the rest.  For example, allowing
port 80 but not port 25 if you feel that clients may be using insecure
smtp software that could be attacked.  This particular usage was
common when sendmail still had a high rate of security patches and
individually administered workstations may not be updated as often as
they should be.  Also you could disallow any access to a portion of
the internal address space and use application gateways such as
POP/IMAP or (restricted) mail relay and ftp and web proxy.  Filters
can be confitured to allow specific services such as ssh.

What this (and NAT) doesn't do is allow filtering based control of
internal users.  Clever user have put all sorts of services inside
port 80 and even over HTTP.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Mar 2003 14:18:57 -0500

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Mar 2003 15:21:00 -0500

In message <[email-masked]>, David Conrad wri
> Internet, why waste your time breaking through a NAT box?
<snip>
> -drc

This security subthread is wandering off topic.  Surfice to say that
if someone just want to break into no place in particular, they go for
the easiest targets.  If they want to break into somewhere specific,
they (try to) find a way around whatever is there.  In that latter
case, NAT provides a very ineffective barrier relative to the same
level of packet filtering without NAT, which is also quite ineffective
against many forms of attack.

The most secure networks I've used did not use NAT and had minimal
packet filtering but rather were directly connected to the Internet
and used cryptographic authentication and payload encryption on any
service needing to be secure.  With those measures packet filtering
added little further benefit but was used anyway, mostly to prevent a
few common forms of traffic based DoS attack.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Mar 2003 15:21:00 -0500

<snip>

Curtis

---

From: Jing Shen <[email-masked]>
Date: Wed, 26 Mar 2003 14:56:09 +0800 (CST)

Hi,
>port 80 and even over HTTP.

I have another sample:  if we hire some service from ISP to connect our internnal network to internet, we use NAT at access point which dynamically share IP address pool to the whole subnet. If someone outside want to crack my computer, he must firstly locate my computer's real address. This means the hacker must crack the NAT router at first. I think this improve the difficulty of cracking. Also, round-robin load balancing between server farm is achived by mapping single real address to several private address, this also improves the service reliablity. 
thanks.
regards
Jing Shen

Jing Shen

State Key Lab of CAD&CG

---

From: Jing Shen <[email-masked]>
Date: Wed, 26 Mar 2003 14:56:09 +0800 (CST)

Hi,

Jing Shen

State Key Lab of CAD&CG

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Mar 2003 10:02:58 -0800

As has been said, if you're relying on NAT for security you are getting
very weak security, especially if your ISP is compromised.  They may
well be able to route right through the NAT, depending on your network
configuration.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Mar 2003 10:02:58 -0800

Eliot

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 26 Mar 2003 16:46:29 -0500

In message <[email-masked]>, Jing Shen 
writes:
> I have another sample:  if we hire some service from ISP to connect our inter
> nnal network to internet, we use NAT at access point which dynamically share 
> IP address pool to the whole subnet. If someone outside want to crack my comp
> uter, he must firstly locate my computer's real address. This means the hacke
> r must crack the NAT router at first. I think this improve the difficulty of 
> cracking. Also, round-robin load balancing between server farm is achived by 
> mapping single real address to several private address, this also improves th
> e service reliablity. 
> thanks.
> regards
> Jing Shen

NAT still adds nothing.  If someone want to send an unfriendly UDP
packet to a random SQL server, they only have to scan the 256
addresses of the NAT (or whatever), not the larger address space
behind it.  Any computer that has recently been active is hit by the
scan.

If computers have no reason to access anything outside the local
network except through proxy, then filtering all but the server
addresses solves the problem with or without NAT.

If someone wanted to break into a specific computer, they'd just break
into any old computer behind the NAT and then break into the computer
they were targeting.  For example, Has a PC ever contracted a virus?
If so you have proven to be vulnerable behind the NAT and an attacker
could leverage that vulnerability.

Curtis

ps - ANS used to log 300 attacks a day on the NSFnet infrastructure,
all to no avail and only those not deemed not to be "kiddies" trying
well known trivial attacks were tracked and turned over to the US FBI.
We pointed to Mitnik attacking from university campuses and netcom
long before SDSC got motivated to track him back to his cell phone.
We caught a number of security audits where we were not notified,
including ones from Purdue, BBN, and AT&T (all contracted security
experts asked to audit us, one contracted by a federal agency and in
two of these cases we contacted the FBI).
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 26 Mar 2003 16:46:29 -0500

Curtis