R: Allocations for "always-on" ISPs
- Date: Thu, 14 Dec 2000 08:47:21 +0100
Ciao
I read with a lot of interest the quantity of email regarding this problem.
I think that we must avoid to generalize this problem. In most cases NAT or
PAT are good solutions both to save waste of Ip addresses (v4 or v6)and to
security. In many other cases there is the need to have public IP addresses
both for clients and for servers, depends which applications run on these
machine and how technology evolves.
fortunately we are reducing the waste of ip addresses with new protocols and
new features (http 1.1 teaches).
Now we are assisting to the birth of many new services that need public ip
addresses such as GPRS, video streaming, web controlled machines and so on.
I think that in the lounch period of these services there will be a great
deal of use of them simply because this is the simplest way to start and
debug. I fund a little circuit that works like a web server and can be used
to web remote control any kind of device, startink from the washing machine
to the coffee distributor etc...
http://world.std.com/~fwhite/ace/index.html
http://world.std.com/~fwhite/ace/ace2.html
To summarize I thing that we should allow to use public ip addresses to
those who need and use them (home users, isp, companies and so...), with a
little more control about the effective need and usage.
Ing. Alessandro Pelosi
Network Engineer
SWISSCOM SpA Milano
+39.02.40.934.312
-----Messaggio originale-----
Da: Bruno Ciscato [
]
Inviato: mercoledì 13 dicembre 2000 9.53
A: lir-wg@localhost
Oggetto: Re: Allocations for "always-on" ISPs
I'm very glad my mail sparkled such an interesting discussion.
I see three main threads developing:
1) NAT or not to NAT
2) prohibit /29 for residential users
3) where is IPv6
First of all let me try to put these problems in the context I was referring
to in my mail. The service providers I was thinking about are those who want
to offer an always on connection to customers that wont' simply surf the
net. Once you have always on connectivity to the Internet you may end up
buying an Internet washing machine (
http://www.margherita2000.com) and an
Internet camera (
http://www.axis.com/products/camera_servers/index.htm).
These are servers, not clients. Chances are that most devices like these
will be manageable by a web browser,so they simply don't work behind a
NAT/PAT.
So, in this context, these are my opinions regarding the three threads :
1) NAT is bad for users that want to connect to the Internet, see
http://www.ietf.org/rfc/rfc2993.txt and PAT is much worse. NAT/PAT is not an
option in the scenario above.
2) how many addresses should RIPE allow a LIR to give to always home
customers? /32, /30, /29 ? IF we want to couple a customer with a subnet, I
agree with people that are thinking about a /29 at least, because a /30
leaves only one address for your PC. So you cannot use your camera to watch
your washing machine doing its job ;-) An alternative would be not to couple
a customer with a subnet and give each customer as many address as they
need. This would work but would make security, multicast, and probably a few
other thins harder to manage.
3) IPv6 is good, see
http://search.ietf.org/internet-drafts/draft-iab-case-for-ipv6-06.txt and
the service I'm describing would be much easier to deploy if we had it. Why
don't we have it yet? Because we make a fundamental mistake in assessing
IPv4 addresses exhaustion rate: we count how many addresses are actually
allocated/assigned, not how many addresses people would actually need to
access the Internet in a decent way. I've personally worked with two very
big companies, one that offers always on Internet access, and the other
GPRS. They have not even tried to contact the RIPE to request the public
IPv4 addresses they would need to offer an architecturally sound service
(see:
http://www.ietf.org/rfc/rfc1958.txt) because they feel they will never
get the number of addresses they anticipate to need!! So they try to get
away with NAT, and fail. In this way we get the wrong picture and don't
realize how much we need IPv6 today, and neither do the network equipment
vendors. So I agree with Lars and Oystein: let's run out of IPv4 addresses
once for ever, so we can move on to the next stage. And for that matter,
let's stop being restrictive about allocations and assignment: let's give
plentiful of addresses so we run out faster!! And I'm not kidding.
Cheers
bruno
