Subject: RE: Why people by NATs

From: "Peter Ford" <[email-masked]>
Date: Mon, 22 Nov 2004 11:42:17 -0800

Eric,

I suspent that none of us on this list qualify as the nominal consumer.

I do vehemently agree with your last paragraph.  In some sense, you are
saying that NAT is an intrinsic part of the nominal "residential
gateway" (could be expanded for soho and small/medium business).  As
such, what is the nominal IPv6 based "residential gateway", and its
feature set?

Perhaps the IETF needs to do for "residential gateways" what it did for
routers in the old router requirements days.

Regards, peterf

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

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 22 Nov 2004 15:08:18 -0500

Peter Ford <[email-masked]>:
> gateway" (could be expanded for soho and small/medium business).

Indeed.  I think this is true.  Several people on this list have tried to tell
me that I don't really want the IP address space on my local net to be 
decoupled from the server address.  

They are wrong.  I want to be able to change ISPs by fixing *one* IP
address in *one* place, and I want to control the mapping from global
IP addresses to local ones.  This desire has nothing to do with IPv4
vs. IPv6 and everything to do with wanting to be able to make only
small, conservative changes in my network configuration rather than
having to completely disrupt it.

Once again, I don't think my situation is unique.  I only have five machines
on my net -- my desktop box, my wife's desktop box, my laptop by WiFi, an
Apple PowerMac we watch streaming video on, and the mail/web server downstairs.
For somebody administering a network of 100 machines, the hassle cost of
IP renumbering would be twenty times larger.  Given this, how could
anyone wonder why NAT is popular?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Chris Palmer <[email-masked]>
Date: Mon, 22 Nov 2004 12:10:52 -0800

Eric S. Raymond writes:

> For somebody administering a network of 100 machines, the hassle cost
> of IP renumbering would be twenty times larger.  Given this, how could

There's another feature of NAT that is desirable that has not yet been
mentioned, and which at least some customers may be cognizant of: the
fact that NAT is a pretty restrictive firewall.

I'm as big a fan of the end-to-end principle as anybody, but until the
ends are trustworthy, we can't get there. Whether by IPv6 or IPv4,
less-than-fanatically-administered Windows and Unix systems simply
cannot be directly connected to the Internet.

:(

-- 
Chris Palmer
Staff Technologist, Electronic Frontier Foundation
415 436 9333 x124 (desk), 415 305 5842 (cell)

81C0 E11D CE73 4390 B6C7  3415 B286 CD8F 68E4 09CD

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 22 Nov 2004 16:18:38 -0500

> cannot be directly connected to the Internet.

I wouldn't go that far.  I wouldn't describe myself as a fanatical admin;
"lazy" and "barely competent" would be closer to the mark :-).   Despite
this, I've never had a breakin in more than a decade.  I'm comfortable 
connecting a Linux system directly to the Internet, as long as the 
internal software firewall is on, 

It's nice to have my firewalling done by a box that is too stupid to
be cracked, but what I need from the Linksys is really the address
multiplexing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 22 Nov 2004 22:17:21 +0100

Eric,
this is a sine qua non requirement.

With plug, play, testing and document of every appliance but also of every 
competing network connection I can grab (wi-fi, ISPs, cable, ISDN, 
satellite, etc. ). So when I a move around nothing is changed, and I know 
to use the my environment in hotels with the same low cost e-control panel. 
Linksys is good but their panel is not that good. Change ISP and look at 
the time you waste in calling their support to know the parameters. There 
should be a default address at each ISP were to load the current configuration.

This is not only true for home or business, but for cars, ships, mobile, 
etc. This must be protected by insurances : what if a disabled is hurt 
because an address was ill entered (as you know IPv6 addresses are very 
simple to enter and memorize), what if my hospital cannot reach an ill 
person control station home, what if my car ... what if somebody got 
injured because he used a default address on his own control pad and a 
unexpected appliance reacted, how can I set-up kid protections programs 
blocking some appliances, or dangerous equipments, etc. This will call for 
rules and strict address formatting. How could we have protection services 
checking our home situation every minute and authorized to call the Police 
or the firemen if there are no address format standard, warranted by law ?

I have difficulties enough in finding a plumber, I do not want to have to 
find an IPv6 specialist every time I buy a new PC or the IETF writes a new 
RFC. Let be reasonable: if IPv6 is to work we must not spend more than 5 
minutes a year caring about our 1000 addresses or more. And do not tell me 
that domain names will help - most probably all of these addresses will 
have awfully long manufacturer formed named to call and maintain them for 
you. ... in various languages. This is not to be a joke, this must work, be 
documented, tested, controlled, paid, sure, secure, protected, updated, 
compatible, etc. etc. with lawyers suing manufacturers for millions if a 50 
euro box worked wrong and created harm. So in addition you want logger, 
paper copy, phone alarms, etc. which will ring at the proper police 
station, not on the other side of the world, you want no spam and immediate 
call back for micro payment authentication.  And all that for a corebox 
purchased at the super-market.

It calls for some thinking outside of the IETF. The IETF carried the small 
part of IPv6 deployment and delays the big part in keeping discussing it.

Harald is absolutely right:
"In IPv6, I see our job as standardizers to make sure the thing we have 
defined is well-defined enough to let it work, and then get the hell out of 
the way. At this time, it's the users and the network builders who will 
decide whether we've succeeded or failed. Not us standardizers. We can do 
minor maintenance and "hey, we didn't mean it that way", but the best we 
can do for IPv6 is to point out all the stuff that is done, stable, and is 
NOT going to change any time soon.
"

jfc

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Nov 2004 22:31:56 +0100

> having to completely disrupt it.

You wouldn't care about touch points if even a large number were 
reliable and secure, and that is the key.  At the consumer level I think 
it's VERY important that most people not care about the IP address they 
are assigned.  In fact it's important that they not have to know 
anything about what they're addressed!  And you're right: it doesn't 
matter whether it's v4 or v6.  So.  Where are the gaps?

Eliot

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 22 Nov 2004 17:22:25 -0500

Eliot Lear <[email-masked]>:
> reliable and secure, and that is the key.

I'm not sure I understand that sentence.  What's a "touch point"?  
And what does security have to do with any of this?  My issue is with how
much administrative overhead my network interface imposes on me over its
entire lifecycle, potentially including multiple changes iof ISP.

>                                         At the consumer level I think 

Well.  Ideally, when I plug my router into the ISP's cable, it should
invisibly negotiate an IP address range with the ISP as DHCP does now.
Thereafter, whenever a machine initializes its network access, it
should

(1) grab an IP address from the range

Ideally, the address allocations should be stable even as machines are
inserted and deleted onm my local net, so other peoples' DNS caches
don't become invalid every time I have to reboot a server.  Perhaps
base them on a hash of the requesting machine's MAC address, with
backoff in the (rare) collision cases?

(2) propagate updates to my DNS servers so lookup-by-name works.

This is important.  As long as this isn't true, DHCP is useless for servers.

I should be able to declare my firewall and redirection rules by local
host name and have everything work,  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Nov 2004 15:00:36 -0800

>fact that NAT is a pretty restrictive firewall.

would that it were true. In fact, it is pretty easy to breech. All one has 
to do is ddos with a the right port prefix, observe a response of any kind, 
and you can ddos right through it.

An actual stateful firewall is a good thing. NAT mostly has the effect of 
deluding the person behind it into thinking they have a security solution.

Screen doors are a good thing. They should be confused neither with storm 
doors nor effective insect inhibitions in the home...

---

From: Paul Vixie <[email-masked]>
Date: 23 Nov 2004 01:26:23 +0000

i've lost track of this conversation, but i want to add some raw data.

> This is important.  As long as this isn't true, DHCP is useless for servers.

isc dhcpd and isc bind cooperate in the way you're describing, and as far
as i know there's an RFC that describes this cooperation.  in any case it's
in general use in enterprise networks, but less so in isp's and soho's.
-- 
Paul Vixie

---

From: Hans Kruse <[email-masked]>
Date: Mon, 22 Nov 2004 21:12:41 -0500

Technically true, of course.

However, most SOHO sites look for a zero-order level of protection 
against the random worm trying to connect to an open TCP port on the 
average windows machine (especially one set up for file/print sharing 
on the SOHO network), and NAT does that just fine.

IPv6 marketing has to take this into account, with a deliberate "here 
is why the IPv6 gateway provides the same default protection as NAT..." 
FAQ entry.

On Nov 22, 2004, at 18:00, Fred Baker wrote:

> would that it were true. In fact, it is pretty easy to breech. All one 
> has to do is ddos with a the right port prefix, observe a response of 
> any kind, and you can ddos right through it.
>
> An actual stateful firewall is a good thing. NAT mostly has the effect 
> of deluding the person behind it into thinking they have a security 
> solution.
>
> Screen doors are a good thing. They should be confused neither with 
> storm doors nor effective insect inhibitions in the home...
>
>
Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer 
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 23 Nov 2004 07:03:22 -0500

Hi All,

It will probably come as no surprise to many of you that I have spent 
quite a bit of time over the last few years trying to understand why 
people use NATs and how they could be replaced with more 
architecturally harmonious mechanisms.  I have been completely 
convinced for several years that IPv6 will not eliminate the (real or 
perceived) need for NATs, at least not without significant follow-on 
work from the IETF.

We won't be able to eliminate or substantially reduce the use of NAT 
in the Internet architecture unless we come up with better ways to 
address the problems that NAT is being used to solve, where better is 
defined from the user's perspective not from an architectural 
perspective.

The average Internet user (home user or enterprise administrator) 
does not care about the end-to-end principle or the architectural 
purity of the Internet.  These users care about ease of deployment, 
cost and avoiding unscheduled outages (whether due to security issues 
or ISP changes).  Home users primarily care about client access to 
the Web, and enterprise administrators primarily care about keeping 
internal network connectivity as stable as possible.

IMO, Internet users are primarily using NATs to solve four problems 
that the IETF has not reasonably addressed:  (1) free IP address 
space for use on VPNs or other private networks, (2) stable, 
provider-independent IP addressing, (3) one-way connectivity to 
provide protection for "client-only" nodes, and (4) 
zero-configuration home and small office networking.

Let me consider each of these problems separately:

(1) Current ISP business models are tied to IP address allocation, 
and that will need to change to remove the economic/business 
incentives for enterprises to limit their use of IP addresses.  There 
might be similar changes needed to registry policies and business 
models.  Given that there are some rather large political and 
financial forces involved, I don't have any idea how/if these changes 
will come about.  In the meantime, the only alternative for the IETF 
is define portions of the address space that can be used for private 
addressing on VPNs and other private networks.

(2) One-way connectivity could be provided via stateful firewalls 
instead of via NAT.  Since these firewalls wouldn't involve 
translation, they would avoid some (but not all) of the problems with 
NAT.  However, they would still involve storing per-connection state 
in the middle of the network, so they will have some of the 
brittleness and reachability problems associated with NATs.  AFAIK, 
the IETF doesn't need to do anything to make these stateful firewalls 
possible, and they may replace this aspect of NAT in home/small 
office gateways if ISPs actually do offer /48 prefixes to 
subscribers.  Is there a better way to replace the security 
properties of NAT?  Is there work that the IETF should be doing in 
this area?

There does seem to be some fundamental disconnect between the idea of 
a selectively reachable Internet and the DNS system.  In an 
enterprise situation, this is typically resolved using split DNS or 
an independent enterprise-level naming system, and in home networks 
this is typically avoided by not assigning DNS names to home nodes. 
Is there a better way for an Internet with multiple levels of 
reachability to be reflected in the DNS?

(3) There is work ongoing in the multi6 and hip WGs to address one of 
the reasons why enterprises want provider-independent address space 
-- enterprise-level multihoming.  However, the solutions being 
considered there will not eliminate the other primary reason why 
enterprises want provider-independence -- avoiding dependence on a 
particular ISP, which can lead to lock-in, higher prices and/or 
unplanned renumbering events due to provider network changes, 
failures, mergers, etc.

To offer true provider-independence, we would need to offer 
long-term, renewable assignments of IP address prefixes directly to 
enterprises, similar to the "swamp space" in IPv4, but perhaps with 
an annual fee required to allow recapturing unused prefixes. 
Although this appears ont he surface to be a policy issue, the reason 
that we don't do this today is that it would cause unchecked growth 
of the global routing tables and the eventual collapse of the 
Internet.  To avoid this technical problem, we would need to find a 
way to individually route a very large number of prefixes.  At the 
moment, though, we don't have a generally accepted solution to this 
problem.  So, enterprises are forced to use NAT to gain provider 
independence -- a trait that they obviously (based on the wide-spread 
deployment of NAT for this purpose) value above end-to-end 
connectivity for their internal nodes.

(4) NATs are also currently used as an element of zero-configuration 
home networking solutions.  While it is probably possible to build a 
low-cost, zero configuration home gateway without using NATs or 
scoped addressing (which I consider to be almost as bad as NAT), we 
don't seem to be working on this problem in the IETF.  Should we be?

Without solutions to these four problems on the horizon, I can't 
voice any enthusiasm that the larger address space in IPv6 will 
eliminate NAT in home or enterprise networks.

Margaret

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Nov 2004 07:58:52 -0500

Margaret,

I agree completely with your analysis -- it turns out that the
two of us have been saying much the same thing for some time
now.  But I suggest that the situation with one of your four
points is even a bit worse, IMO, than the way you describe it...

--On Tuesday, 23 November, 2004 07:03 -0500 Margaret Wasserman
<[email-masked]> wrote:

>...
 
> (3) There is work ongoing in the multi6 and hip WGs to address
> one of the reasons why enterprises want provider-independent
> address space -- enterprise-level multihoming.  However, the
> solutions being considered there will not eliminate the other
> primary reason why enterprises want provider-independence --
> avoiding dependence on a particular ISP, which can lead to
> lock-in, higher prices and/or unplanned renumbering events due
> to provider network changes, failures, mergers, etc.
>...

I think we are going to see (and have already started to see in
the more technical part of the community) demand for multihoming
at the SOHO and even home level, not just the enterprise level.
The reason for this is that, if a small office or home user
views the Internet as a critical resource, and providers to that
scale of operation offer only a "best efforts" service level in
which time-to-repair measured in days is not atypical, the most
efficient choices involve two (or more) providers, rather than
the "business" service those providers are willing to sell (with
more addresses, but, typically, the same lack of credible
guarantees).  The thing that makes this problem different from
the enterprise ones is that it imposes the essentially the same
constraints on the knowledge and effort required for
configuration (i.e., just about zero) that we now see for home
networks (as you point out).  It is not clear to me that the
multi6 and hip efforts are effectively addressing that point,
even if solutions could be built on top of them.

And, of course, if such a requirement originates from the home
and SOHO markets, and the solution requires public address
space, the demand for long-term, renewable, direct-allocation
prefixes will be much greater than one would predict from
assuming enterprise use only.

     john

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 23 Nov 2004 14:11:19 +0100

> perceived) need for NATs, at least not without significant follow-on 

Did you ever think of the fact that many participants in the IETF earned
a lot of money selling:
 - NAT "solutions"
 - VPN "solutions" to overcome the NAT problem
 - Consulting in many ways
 - Services to 'merge multiple enterprise networks'
 - ...

Maybe some people do not want to solve the problem...
Remember that people still need to have food on the plate the next day.

> defined from the user's perspective not from an architectural 

For IPv4 you can totally forget the removal/elimination of NAT. For IPv6
there is still a chance that people are educated properly to not even
think about it.

> purity of the Internet.

Never heard that gamer complaining that his friends could not join that
game server she setup on her computer behind that NAT box? Also any P2P
application loves end-2-end because then you don't have to use a 3rd
party host to relay the traffic. They care but they don't realize what
the problem is especially with the plethora of hacks that allow a NAT to
somewhat work like a real end to end address. The problem though is that
you have to hack around the NAT every single time. Which IMHO is more
costly than getting some extra IP's.

> These users care about ease of deployment, 
> or ISP changes).

They only want three things:
 - that it works without problems
 - with low latency so they can aim correctly in that 3d shoot-em-up.
 - with high download speeds to get their newest movies and other warez.

>   Home users primarily care about client access to 

Web? That is only a _fraction_ of the traffic they are generating. Also
web is due to the simplicity of the protocol one of the few generally
used protocols that doesn't have any problems with NAT's.
Peer-2-Peer (read: end-to-end) is what they are using it for.
MSN (and many other similar setups) for instance has this cam addon so
that you can view the others person face and chat with the other person.
Doesn't work when behind a NAT when you want to broadcast, unless you
use the many tricks (eg uPNP) to avoid the NAT.

> that the IETF has not reasonably addressed:
>   (1) free IP address space for use on VPNs or other private networks,

The world relies on money, nothing is free. RFC1918 came nicely with the
problems that we see today with it's usage in combination with NAT's.
RFC1918 isn't bad actually, but the thing called NAT is.

For IPv6 ULA's should solve this spot quite well.

>   (2) stable provider-independent IP addressing

For global or local connectivity? Local see ULA/RFC1918. For Global this
cannot be done unless you want 128bit ASN's and 2^128 routing entries.
See HIP for instance for one of the solutions to this problem.

IP is a routing protocol, not an addressing protocol (DNS is the current
addressing protocol in that respect).

>   (3) one-way connectivity to provide protection for
>       "client-only" nodes

You mean firewalls?

Could somebody at Cisco wake up and _release_ a working version of Cisco
PIX's that support IPv6 please!? They said they had one 3 years ago by
now, currently it is 'next release'...

>   (4) zero-configuration home and small office networking.

I guess you forgot DHCP for both IPv4 and IPv6 and Router Advertisement
for IPv6.

Did you read the excellent NAP draft?
(Currently draft-vandevelde-v6ops-nap-00 soon, I understood a -01)

> addressing on VPNs and other private networks.

RIR's currently allocate IPv6 space with the following assumption on
behalve of the LIR: The LIR will provide at least 200 /48's to endsites
in the coming n years.

When a LIR thus gives /128's or silly things like /64 to endsites they
are thus violating the reasons why the requested the /32 (or larger in
the first place).

For IPv4 it is really a money business, want more IP's : pay for it.
That is how they earn their money even though they basically get IP
addresses for free (minus some administration costs, which really is not
that much when you earn millions).

ISP's should charge for _bandwidth_ just like they get charged by their
upstreams/transits etc.

But that isn't an effective finanicial situation as when you charge for
that you can't be sure of a $large income.

<SNIP (2), see comment above>

> unplanned renumbering events due to provider network changes, 

With HIP you can swap addresses when you want, there is no dependence.
The ISP is then doing where you pay her for: shoving bits.

> an annual fee required to allow recapturing unused prefixes. 

You are inventing extra work for the RIR's here, they have enough to do.
Again IP is for routing, not addressing...

<SNIP>
> connectivity for their internal nodes.

Why are they forced to use NAT?

The problem is that IPv4 usually doesn't allow multiple addresses on the
same interface, IPv6 allows this, you can use thus ULA prefix for local
communication and one or more globals from one or more upstream ISP's.

Nevertheless, forget about IPv4, that problem is unsolvable.

> don't seem to be working on this problem in the IETF.  Should we be?

I guess you missed out on the DHCP-PD documents?

> eliminate NAT in home or enterprise networks.

This really isn't a problem of the IETF. The problems is at the ISP's
who should charge for bandwidth usage and not for IP's.

It is all a financial problem, people earn money this way, and there is
not an easy way you can let them not make money.
Actually, can you blame them? I can't unfortunately...

Greets,
 Jeroen

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Nov 2004 09:52:37 -0500

>  - Services to 'merge multiple enterprise networks'

In a lot of cases, I think, the companies you're talking about
didn't seek to enter the NAT work-around market but ended up doing
so in order to get their NAT products to work with their other
products.  And, unfortunately, in many, many of those cases the
NAT workarounds are a technical solution to a political problem,
which is that organizationally the products that suffer the most
from the presence of NAT in networks (voice and conferencing,
primarily) are at some distance within their own companies from
the people who make NATs.  Rather than seeking to overcome those
organizational problems they go off and make their own workarounds.
Then they bring that technical solution to a political problem to
the IETF and create a more difficult technical problem (for example,
the movement towards work on session border controllers).

The NAT problem is driven by a large (and growing!) number of
factors, ranging from ISP business models to silly corporate
security auditing requirements to user convenience to any number
of other factors.  This train can't be stopped; I think our best
hope is to work towards making it better behaved.

Melinda

---

From: Daniel Senie <[email-masked]>
Date: Tue, 23 Nov 2004 19:02:28 -0500

At 06:00 PM 11/22/2004, Fred Baker wrote:
>to do is ddos with a the right port prefix, observe a response of any 
>kind, and you can ddos right through it.

I take it Cisco NAT implementations are not very well implemented then.

>deluding the person behind it into thinking they have a security solution.

Stop there. Fred, I am sure you've read or written the code to implement:

a) a stateful inspection firewall

b) a NAPT implementation (what most folks think of when they talk about NAT).

The code is NEARLY identical. In fact, the lookup tables used just need an 
extra column to track some additional information.

Please stop with the argument that NAT and stateful inspection firewalls 
are different beasts. The software to implement them is basically 
identical. If you dislike NATs, say so, but this old argument about NAT 
boxes not providing security provided by stateful inspection firewalls is 
just not an honest one.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 24 Nov 2004 08:35:21 +0100

> I take it Cisco NAT implementations are not very well implemented then.

Well, in this case I can't blame Cisco, because NAT's are simply made to
be implemented well.

> extra column to track some additional information.

That two tools both use bubblesort doesn't mean they fulfill the same
function. The same with a lookup table function.

> are different beasts.

They are very different. A tiger and a little pussy cat, which one do
you pet and take into your lap? Two different beast, though they look
the same...

>  The software to implement them is basically 

A NAT does not provide security as a NAT doesn't have any rules.

Also note that there is usually a _seperate_ firewall component in
common NAT boxes (and please don't call them routers as they are not)
this is the thing that gives the machine it's little bit of 'security',
not that anyone tinkers with the rules, thus keeping the box wide open.

Greets,
 Jeroen

---

From: Leif Johansson <[email-masked]>
Date: Fri, 26 Nov 2004 10:11:49 +0100

> anyone wonder why NAT is popular?

Wrong. If you administer 100's or 1000s of machines you build or buy
a system for doing address management. Renumbering is only difficult
if your system is called vi :-)

	MVH leifj

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 26 Nov 2004 17:08:22 +0100

> if your system is called vi :-)

Wrong ;) Well at least, up to 1000 is probably doable.
But what if you are talking about 100s or 1000s of organizations with
each a 100 or 1000 machines.

Organization/Management and actually finding out who is doing what in
such a big environment is the problem. (Of course the people who where
'managing' this network should have seen it coming sooner or later, but
they already left of course).

Greets,
 Jeroen

---

From: Leif Johansson <[email-masked]>
Date: Sat, 27 Nov 2004 11:48:17 +0100

> each a 100 or 1000 machines.

My site is 10k+ addresses. Seems easy enough to manage to me :-)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 28 Nov 2004 18:29:39 +0100

I'm sorry to reply so long after the fact, but...

> is why the IPv6 gateway provides the same default protection as 
> NAT..." FAQ entry.

Actually in IPv6 you are well-protected against random scanning 
withough the need for any device in the middle: a /64 subnet is so 
large, that scanning it is completely infeasible.

Now of course someone who knows your address doesn't have to scan, so 
this protection isn't complete. But for TCP it's entirely trivial to 
only allow sessions to be set up in one direction. Full stateful 
firewalling is of course also possible. However, both these options 
bring back some of the downsides of NAT: in order to make incoming 
sessions possible, there must be configuration of some sort.

A default filter that rejects packets for services that are generally 
intended for local use only would probably be good enough for a 
residential IPv6 router. Other services are either not enabled and/or 
firewalled in the host anyway, or the user actually wants them to work.

(It would be incredible helpful to have all these local-use services in 
a fixed range of port numbers for easy filtering...)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 28 Nov 2004 19:05:12 +0100

On 23-nov-04, at 13:03, Margaret Wasserman wrote:

> To offer true provider-independence, we would need to offer long-term, 
> renewable assignments of IP address prefixes directly to enterprises, 
> similar to the "swamp space" in IPv4, but perhaps with an annual fee 
> required to allow recapturing unused prefixes. Although this appears 
> ont he surface to be a policy issue, the reason that we don't do this 
> today is that it would cause unchecked growth of the global routing 
> tables and the eventual collapse of the Internet.  To avoid this 
> technical problem, we would need to find a way to individually route a 
> very large number of prefixes.  At the moment, though, we don't have a 
> generally accepted solution to this problem.

Well, if you put it like that, doesn't it make sense to simply 
generally accept a solution to this problem?

I'm starting to be convinced (see recent NANOG discussions) that the 
operator community isn't all that impressed with the multi6 efforts to 
make multihoming possible with provider-derived addresses. It looks 
like the RIR address policy forums will soon face the question of 
whether to (de facto) allow provider independent address space for 
end-users.

So _if_ IPv6 PI space is going to be a reality, we should do what we 
can to limit the damage. The only way to do this is to make it possible 
to filter out the PI prefixes at least in certain parts of the network 
without getting in the way of reachability. The obvious way to do this 
is to have an aggregate that tricks the packets into flowing towards a 
place where the PI routing information is available in full. So the 
solution to this problem is actually quite simple. The only tricky part 
is optimizing things such that the extra distance the packets have to 
travel is minimized.

---

From: [email-masked] (Kai Henningsen)
Date: 28 Nov 2004 15:18:00 +0200

> who should charge for bandwidth usage and not for IP's.

Actually, they do - with some qualifications - at least over here, in  
Germany.

That is, if you still use dialin over the phone network, I believe at  
least some still charge by time as that is what they are charged by other  
phone companies for transport. That's what non-packet networks are like.

Then, private end users - or others who behave like them - can opt for  
flat rates.

Pretty much everything else is by bandwidth.

The unfortunate problem here is that you usually only get static or  
multiple IPs with bandwidth accounting, and full use of a flat rate is  
typically vastly cheaper than the same amount of bandwidth via bandwidth  
accounting.

Which means there's a premium to *enter* the static IP market. Once you're  
there, additional IP space is often free of any cost. (Well, you need to  
fill out the RIPE forms so your ISP has something to point at if they get  
audited.)

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 28 Nov 2004 15:06:00 +0200

> does not care about the end-to-end principle or the architectural

Maybe not the average usr, but a pretty large subset *does* care - because  
it makes it extremely hard to do what they want: to make a connection to  
their small business network (behind a dynamic IP) from somewhere else  
(also behind a dynamic IP).

It's possible (using one of a large number of dynamic DNS providers), but  
it is neither obvious nor trivial - in fact, it is hard for them to  
understand even what the problem is.

I just yesterday talked someone through this - a (small) business net  
admin wanting to access that net from home. This was someone who does  
database programming and at least sometimes creates networks for  
customers. And he *still* had a hard time with the consequences of dynamic  
IP and NAT.

No, it's not the majority - but yes, it *is* a pretty significant subset.  
You don't need to be all that far apart from average to bloody your nose  
on this.

> instead of via NAT.

You don't need all that much state for most of the protection. Just  
looking at TCP SYN does cover about 75% of the problem, I'd say, and  
that's completely stateless. (Not to say that the other 25% aren't  
important.)

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 28 Nov 2004 15:21:00 +0200

> My site is 10k+ addresses. Seems easy enough to manage to me :-)

"If you have servers on your segment, they get addresses from the X..Y  
pool. Otherwise, you use DHCP, or you get fired."

Something like that? Seems a fairly obvious solution.

MfG Kai

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 30 Nov 2004 18:06:01 -0600

Thus spake "Iljitsch van Beijnum" <[email-masked]>
> Actually in IPv6 you are well-protected against random scanning withough 
> the need for any device in the middle: a /64 subnet is so large, that 
> scanning it is completely infeasible.
>
> Now of course someone who knows your address doesn't have to scan, so this 
> protection isn't complete. But for TCP it's entirely trivial to only allow 
> sessions to be set up in one direction. Full stateful firewalling is of 
> course also possible. However, both these options bring back some of the 
> downsides of NAT: in order to make incoming sessions possible, there must 
> be configuration of some sort.

IMHO a firewall function, probably stateful, is necessary in nearly all 
cases.  However, this has gotten so mixed up with NAT that many people (even 
at vendors) don't realize they're different things.

With v6 we have the ability to fix this; through some magic function, users 
should be able to get a PA (at a minimum) subnet behind their local 
router/modem/whatever and have a decent interface to configure inbound 
filters, similar to how they can configure evil NAT port-forwarding today.

> (It would be incredible helpful to have all these local-use services in a 
> fixed range of port numbers for easy filtering...)

Default filters are a pain, because inevitably they end up blocking 
something that's useless today but a critical need tomorrow...  For 
instance, my @#%#^& Linksys not only doesn't understand native IPv6 (hello, 
wake up Cisco!) but it even blocks IP-in-IP packets so I can't use an IPv6 
tunnel.

At a minimum, vendors should document _everything_ the default filter does 
and allow the user to disable it if necessary.  You don't need to load the 
gun for them, but if someone wants to shoot themselves in the foot, it's not 
your duty to prevent them, because they might have a perfectly good reason 
to.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 30 Nov 2004 18:17:28 -0600

> make multihoming possible with provider-derived addresses. It looks like 
> the RIR address policy forums will soon face the question of whether to 
> (de facto) allow provider independent address space for end-users.

It'll be coming up on ARIN PPML this week (sorry).

> So _if_ IPv6 PI space is going to be a reality, we should do what we can 
> to limit the damage. The only way to do this is to make it possible to 
> filter out the PI prefixes at least in certain parts of the network 
> without getting in the way of reachability.

That's not the only solution -- just the most obvious one.  Clearly, if IPv6 
PI space spirals out of control like many operators think will happen, we 
need to find a way to make BGP (and possibly forwarding) performance not 
dependent on the number of prefixes in the table.  There's many ways to skin 
that cat, and maybe it's time we start looking at that in parallel to the 
work on multi6 and HIP.

Worst case is we'll end up eliminating IP addresses as locators and build 
another layer beneath IP (and thus transparent to TCP) that actually handles 
routing, at least in the DFZ.  In some sense we already have a foundation 
for that with MPLS, but we'd need to hack/replace BGP to make the new layer 
scale across ASes.  Or perhaps we'll find a way to route based on ASNs in 
the DFZ, and the mapping from destination IP to ASN will be made only at the 
edge of the DFZ.

S