Patrik Fältström wrote: > I have now checked the document in the subject line _again_, and I > think the basic problem is that (a) I don't agree with all of the > problems listed being problems
The point is the guy on the street deploying a network sees these as problems. Yes the IETF members can usually figure out work-arounds, but that is done in the absense of knowledge about the cost constraints of the guy deploying the network. Unless the IETF acknowledges the problems as problems, then documents cost-effective work-arounds, the guy on the street will figure out his own solutions. That said, the document needs to reach WG consensus, so if there are issues, send text. > and (b) I definitely see the > solution to > many of these (as you see below in my mail earlier today) being to > "just" use real IP addresses. Aggregatable PI space would solve many, if not most of these issues. The lack of aggregation in PI is why the draft says local use and a PI with some minimal aggregation should be worked on in parallel. > > For example, that administration and registration of addresses is a > pain and should be easier (not needed even) is a RIR issue, > and should > definitely not be an argument for using scoped addresses. The RIR's are not the bad guys here, they are doing nothing wrong. It costs money to run a registry, and those costs need to be recovered. At the same time, many edge network managers will refuse to be locked into a provider, but can't see any value in paying an RIR to maintain a database. Particularly when there is so much space that picking random numbers is unlikely to create a problem for quite awhile. Tony > > Now I am going back to Application Layer issues for a while. > > paf > > On onsdag, aug 6, 2003, at 11:04 Europe/Stockholm, 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. 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. > > > > In IPv6 world, real addresses can and should be used. > > > > - 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. > > > > - 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. > > > > - 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. > > > > > > paf > > > > -------------------------------------------------------------------- > > 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] > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
