On Sun, Jan 28, 2007 at 03:17:14PM +0000, Jeroen Massar wrote: > Brian Candler wrote: > > On Sun, Jan 28, 2007 at 12:36:38AM -0800, Joe wrote: > >> whats sad is how many people will never let go of NAT after they migrate > >> to ipv6. > > > > It's not sad; for many people it would be essential. How would you like > your > > 48-bit MAC address to become a permanent cookie, following you about > > whenever you access the Internet? > > *sigh* read RFC3041 to 'solve' that part and of course dhcpv6 exists and > everything else you have in IPv4. >
Oh glory a new RFC fixing something that should not have been an issue. IPv6 starts to be like VoIP a huge collection of junk RFC. > > And if you need to change ISP, and > > therefore get a new address allocation, many people would rather just put > in > > some NAT at the border than take the pain of network renumbering (which > IPv6 > > doesn't make any easier than IPv4) > > Depends on the size of your network of course. But you can actually get > IPv6 PI space already, you will have to cash out a bit for it, just like > for IPv4 address space, but it is there. Problem for that solved. Same > non-scaling solution as in IPv4. No differences there. > Not in Europe. RIPE will not give away PI space. This is actually a religious problem with the IPv6 belivers that still think that 10'000 IPv6 routes will cover the world. > And otherwise read RFC4193 to get your unique local goo for free. > And another RFC that nobody cares about. > > Stuart Henderson wrote: > >> 128-bit gives you a *lot* of address space. > >> > >> 18 million million million /64's, each of which can hold > >> 65536 x the total number of possible 48-bit MAC addresses. > > > > Nope. One year ago, France Telecom applied for, and was granted, a /19 of > > IPv6 address space. Since the first three bits are fixed in the unicast > > addressing plan, this means that a single ISP has already taken 1/65,536th > > of the total available. > > The first three bits (2000::/3 ;) are used now only that in case this > whole idea of giving people huge chunks of addresses goes bad that there > are 7 (8-1 ;) tries left to do it correctly. So if the 2000::/3 space > runs out, then the world has another 7 tries left to screw it up again. > Thus no issue there. > Good that we still have a few bits left in the IP version header... > Of course if you have better ideas, you can always bring it up on the > various RIR forums. > They did not listen when people mentionend issues about IPv6 while they were working on the initial standard so why should they now. > Also note that FT serves the whole country of France, you might not like > them, but they also have a right to use the Internet ;) Most ISP's get > only a /32 and there are millions of those. Getting a /19 is really > something that only a few ISP's will be able to claim that they will > actually be able to get customers for. > > > This all boils down to dogma on the part of the IPv6 designers - e.g. "thou > > shalt not have server-based address autoconfiguration". If IPv6 had stuck > > with DHCP, which everyone knows and understands, then you could just give > > each customer a /96, rather than a /48 as demanded by IPv6, and we would > > have addresses for aeons. Not so now. > > There is *NO* demand from anyone for giving /48's to customers. It is > only a suggestion. RIR's do allocate address space towards ISP's based > on the fact that they will be providing the /48's to endusers. The > reason btw for doing that is so that the prefix size is always the same. > You can then 'easily' (ahum) renumber by just swapping out the first 48 > bits, the rest you can keep the same. At least the numbering plan will > thus be easy that way. (the editing and getting everything else isn't ;) > > The only sort-of requirement that there is is the /64 boundary, because > of autoconfig, which you can easily avoid too by using static addresses > or DHCPv6. You can perfectly use /126's if you want. > The /64 boundery is the most supid thing ever invented. In the end of those 128-bit only half of them are usable. > BTW: Don't use /127's that will break your IPv6 as the lowest address is > the anycast address. Just like the network address in IPv4. > > > So I argue that IPv6 doesn't solve any of the problems which IPv4 has - not > > even address depletion - and adds plenty of its own. > > Address "depletion" is the only one thing that IPv6 really solves it > perfectly well. > The price for a bit more address space is just not worth it. > > As a result, I don't > > see much commercial reason to roll it out, and certainly no commercial > > reason to switch off the existing IPv4 Internet. Arguments here: > > http://pobox.com/~b.candler/doc/misc/ipv6.txt > > I suggest you start doing some background reading, read a good book or > something as you clearly are missing a LOT of information, as I've > easily shown by the answering the FUD you where trying to spread above. > > Don't read this as rant, it will probably sound like it, but that is > because you have so much wrong in the text ;) > > > To address the points in that document: > > > 1. ROUTING TABLE EXPLOSION > > IPv6 is an ADDRESSING system, it has nothing (not much at least) to do > with routing. BGP/ISIS/OSPF are ROUTING systems. Subscribe to > [EMAIL PROTECTED] if you want to solve that problem. > Routing depends on the addressing system. Getting the addressing system wrong results in increased pain for routing. IPv6 had a chance to fix the current issues with routing table explosion and the fact that longest prefix matches need way more CPU cycles than simple CAM lookup need. Ever wondered why a cheapo switch works at wirespeed while most router fail to do that... > > 2. THE RENUMBERING PROBLEM > > Impossible to solve as well documented by the IETF. The second there is > an external factor (eg a place where you have to put your IP in a remote > firewall or DNS server) this ain't easy any more. > On of the goals of IPv6 was to make renumbering painless. They failed and had to realize that it is not so easy. Renumbering was one central pillar in the IPv6 building. As said before the IPv6 routing table should not grow over 10'000 routes -- at least that was the intention. Because of that no PI space was allowed and renumbering was "invented". > Valid argument, but the same for IPv4 and IPX and any other. > Renumbering of IPX is easy. Just change the 32bit network address on your edge router and your done. > problem there is here > > > 3. THE MULTI-HOMING PROBLEM > > See 1) Same problem in effect. > For multi-homing you need PI space or a working renumbering that is painless. Neither was available for IPv6 until a few month ago when ARIN decided to ignore the IPv6 followers and started handing out PI space. > Btw, phone numbers are analogous to DNS, not to IP addresses. > > > 4. ADDRESS DEPLETION > > Your arguments are bullshit, and you know it. > The biggest part of the IPv6 address space is not usable. Instead of a /24 as smallest routable network for IPv4, IPv6 rised it to /48. The rest of the 128-bits is just waste of memory. > > 5. NETWORK ADDRESS TRANSLATION > "Unfortunately, it does. There are people running NAT for IPv6, right now." > > I have never seen or heared anybody doing it (yet). also again see RFC3041. > AFAIK pf(4) does NAT on IPv6 just fine. An there are other reasons why NAT is a good thing(tm). > > 6. SMALL PROVIDERS, DEVELOPING COUNTRIES > > No problem there, even when you wrote that document. ANY ISP has a plan > for 200 customers, if you don't well, is there use for you then getting > a /32 of address space? > > > 7. FALSE ROUTES AND INSTABILITY > > Again, Routing != Addressing. SBGP is one part of the solution for this > btw. Good monitoring systems like RIS and GRH is the other. > SBGP will never work and will be the major cause for routing instabilities. > > 8. SOURCE ADDRESS SPOOFING > > SBGP + uRPF. Both possible for IPv4 and IPv6. > ... > > 12. ADDITIONAL PROBLEMS CAUSED BY IPV6 > > 12.5 Please ask your granny to remember your telephone number (10 > digits) or the IP address of www.google.com, oh yeah that changes now > and then. Use DNS. Simple. Especially if your DNS is down or unreachable. The NOC will suffer most and the result is longer down times. </ipv6 rant> -- :wq Claudio
