Tim Hartrick [mailto:[EMAIL PROTECTED] wrote: > > Enduser ISP's will always charge for extra IP space as it's > > currently not customary to give an enduser more than 1 IP. > > Also IPv4 is a becoming a 'scarce' resource. > > > > And what precisely will change this custom for IPv6? Quoting RFCs > is silly in the face of MBAs motivated by profit. It is folly.
Then I would suggest that you either educate them that IPv4 != Ipv6. This is one thing one will have to do anyways. Just like the fact that IPX != TCP/IP. Also if one doesn't want to follow RFC's then don't expect to be able to communicate properly with the rest of the world. But ofcourse that is my point of view and I don't like taking into account money in technical matters. > > > Absent some regulation, there is no reason to believe that > > > they will stop charging for IPv6 address space no matter > > > how freely the bits are made available to them. > > > It would be great if ISPs would charge for bandwidth > > > only but that simply isn't the way the world currently works > > > and there is absolutely nothing about IPv6 that will change that. > > > More bits in the address don't mean diddly if the only way to > > > get the bits is through an oligarchy of ISPs. > > > > If the ISP doesn't provide /48's to an endsite, other ISP's > > will have the advantage that they do. Also if the ISP doesn't > > they are going against RFC's. > > > > RFCs fall regularly in the face of the profit motive. Like above, if you opt not to follow RFC's, STD's etc don't expect to be able to communicate. > > You might also realize that the current TLA policy for RIR's > > demands that you have 200 prospect clients. That is 200x /48. > > Aka 200 endusers on DSL will suffice for them. > > > > Currently even most tunnelbroker system endusers get > > a /48 and in some cases even more. And they are not even > > paying for bandwidth nor for ipspace. Go figure ;) > > > > I have little faith that the current state of affairs will > resemble the eventual state of affairs. No one currently > expects to make money from IPv6. Once they do, address > space will become a profit center. MBAs don't care about RFCs. I think you meant: s/no one/apparently no one in the US/ Welcome to the global Internet where Asia is leading the developments. > Don't get me wrong I don't mind ISPs making a profit. If they don't I > won't have service but that doesn't mean that every small and medium > size business that can't pass itself off as an ISP should have their > internal topology held hostage by the local oligopoly of ISP. I agree indeed, this is what is the _current_ practice in the IPv4 world is. But if we, the people deploying IPv6, clue in the ISP's enough that they should not and I haven't heared of any ISP who is asking money because 'the customer wants a /48 and we don't have much address space' If you have other versions of this story please show them. > ISPs. Small and medium sized businesses simply won't accept > that cost risk and will promptly move to using NAT to protect > themselves from renumbering and/or cost uncertainty. > They can't really be expected to do anything else given IPv4's > history of real and manufactured address scarcity. If they are out to use NATs any way they can, I see absolutely no reason for them to use IPv6 at all. Either clue them in that they should follow the RFC's and spread /48's or let them keep their NATs which will break Again, this talk is about 'uncertainty', quite possibly because of the 'fear' that they are going to change upstreams etc. IMHO that can be fixed by Multihoming solutions, not by using NAT's. And therefor I still see no need for link-locals. To sum up, the only reasons I have seen so far and please add to list if I miss a couple, which is quite probable and very much related to NATs, which are being discussed for deprecation also... - Impact of site-local addressing -- Margaret Wasserman http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.tx t The appendix has a part about limitting usage to single sites. But that has their own implications when the site does get global connectivity or merge with another company and we are at NAT again. And on this list have been named: - Merging networks, then using NATs because the address space is not unique. -> Use public IP space from your upstream. If you are not big enough for your own TLA you apparently haven't got a big or own network so renumbering should not be much of a pain. Another option: Multihoming. - My printer can be reached from the internet. -> Use a firewall; NAT won't 'protect' you. Any others? BTW: let me note that I know of a certain hospital with a /16 IPv4 and all their heartmonitoring and other surveilance apparatus are using IP's out of that /16. With one big, good configured, firewall at the gate and ofcourse nice VLAN's which don't even allow packets from those VLAN's to come even close to the internet. Now I quickly hear a "why do they have a public /16", because it's globally unique and they can easily merge with another hospital or organization and don't have to 'fear/uncertainty/doubt' that their address spaces will ever collide. Oh and for the question of how much v6 they would need: a single /48 would suffice as it would allow 65535 networks or quite possibly VLAN's. And yes they could receive that from their current upstream which also delivers the /16 to their doorstep. It's kinda cheating because it's internet from an NREN but even then it's a reallife version of what is done with IPv4 and how it can be done with IPv6. Problem in IPv4 is simply that you can't get the space, but it will simply have to change otherwise expanding the address space to 128 bits is futile and we can stay at the non-e2e NATted IPv4. With all the problems which come along with that... Greets, Jeroen -------------------------------------------------------------------- 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] --------------------------------------------------------------------
