Patrik F�ltstr�m wrote: > On onsdag, aug 6, 2003, at 02:05 Europe/Stockholm, Tony Hain wrote: > > > From the operator perspective, the demand is for address > space that is > > architecturally set aside as private use, locally > controlled. That did > > not initially exist in IPv4, and history shows that people took > > whatever bit > > patterns looked interesting. > > You must talk with different operators than the ones I talk with. > > I have heard operators wanting address space for the following: > > - Private networks which are never routed to the Internet > (management and various things like GPRS things), but > possibly routed to peers, i.e. there might be the need > for local routing > > This can be done by using real addresses which are never > routed to the > Internet. This is something which is possible to do in IPv6 but not > IPv4 due to RIR policies.
Not unless the site is willing to pay an ISP for address space, then probably pay extra to make sure it does not get routed as part of the ISP aggregate. > So, today, the ISP's use RFC 1918 > addresses, > but of course peering then end up being a problem. Because of > this, we > see telcos using 11/8 and such IPv4 space for gprs. Local address space MAY be used by ISPs, but the primary target for local use space is the edge network. I agree that when ISPs use unrouted space, results may not be deterministic. > > In IPv6 world, real addresses can and should be used. Real or imaginary are perspectives of the onlooker. I suspect you intended 'globally routed'. > > - Private networks which they nat customers behind so the > customers can not so easy set up their own servers > > This is a packet filter/security issue and not a NAT issue. The > selection of NAT is a bad thing, and this is exactly what we should > prohibit in IPv6 world. Yes, the ISP can still sell filtered > access of > various kinds and possibly a large portion of the users out > there want > it. But, it should not be part of the architecture. I absolutely agree, and have been working on documenting similar requirements for address space that is known to not be globally routed. > > - Private networks for certain services which is located > close to the customers so the same IP address is reused > at every pop > > The ISP can in IPv6 world take a portion of their (real) > address space > and do the same thing. That ISP's today use RFC 1918 addresses means > the RFC 1918 addresses are (for the customer) not used as > intended, but > as real addresses. In IPv6 world this is not needed. Duplication of addresses is not 'needed', but may be perceived as an operational simplifier (ie: the dhcp servers in every pop are 192.168.255.1, ACL configs at every pop are the same ...). This is not arguing that we need to keep that, just pointing out that there are operational costs to changing the model. One thing that is required is that an ISP have a means to provide private networks to their customers. The address space for these can't be taken out of the same aggregate that is being announced to peers, else the network is not really private. > > - Tons of addresses so they can redesign their internal > network a lot without risking renumbering > > With IPv6 they get many many more addresses than before, so > they don't > have to allocate /29 here and there in IPv4 for small networks which > should only have a few hosts. They can have the same netmask all over > the place. And still limit the size of their broadcast domains. Nice in theory, but when route filtering practice hits the fan, there will be allocations within networks that don't seem to make any sense from the outside. There are many more bits for aggregation, so having different lengths and exposing the topology details should not be as frequent as in IPv4, but there are times that the aggregate policy does not match the longer prefix, so those will still show up. The real problem with restricting access happens when the aggregate policy is more open than the longer prefix wants to be. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
