On Mon, Jan 29, 2007 at 04:07:17PM +0000, Jeroen Massar wrote: > Claudio Jeker wrote: > > 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. > > A 6 years old RFC is new? Adding to it that it usually takes 2-4 years > for it to become an RFC as it is a draft before that, minimum of 8 years > is new in the Internet, wow ;) Some people didn't even have Internet 8 > years ago. >
New as in yet another one of those 150+ RFCs that cover IPv6. ... > [..] > >> The first three bits (2000::/3 ;)... > [..] > > Good that we still have a few bits left in the IP version header... > > Those 3 bits are in the IP address. The version header has 4 bits and > only 50% is left of the combinations it makes up: > http://www.iana.org/assignments/version-numbers > Do I need to use irony tags? > >> 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. > > Did you make a formal proposal!? Did you even contribute to the threads > about it with reasoning and structured arguments? If you didn't then > indeed, they can't listen, as you are not saying anything. > In 1995 I was a student and so mostly looking at it but I know some other people how spoke up and got slammed down by fanatic IPv6 believers. Many of the issues like PI space, multi-homing, routing table explosion, header stacking, etc were brought up but nobody listened. > [..] > > The /64 boundery is the most supid thing ever invented. In the end of > > those 128-bit only half of them are usable. > > Quite true, but you can ignore the boundary for global unicast > addresses. Link-locals will still use them but that doesn't hurt much. > DHCPv6 or static can be used for the rest. > > [..] > >>> 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. > > So lets assume that we give everybody who wants a IPv6 "PI" block, sized > /32 so that everybody has shiteloads of address space. > > That means 2^(32-3) = 2^29 routing entries. > Ouch. Enjoy building your TCAM tables, go buy memory first ;) > Oh come on, you know that your example is flawed. Have you ever tried to load 2^29 routes into your router? That's what you are calculating here. Btw. you only need a CAM and not a TCAM for perfect matches. > Also note that one will be effectively routing IPv6 with IPv4, guess why > Juniper doesn't provide 6to4, ah as they can't do that in hardware. > > > Ever wondered why a cheapo switch works at wirespeed while most router > > fail to do that... > > Ever wondered why a cheapo switch doesn't switch more than 2048 MAC > addresses and when it's CAM table is full it goes into 'hub' mode? > I don't expect a 1$ 5/8 port Switching Chip to include a 64k CAM table, do you? > >>> 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". > > They tried and failed indeed. As renumbering was a goal back then and > they found along the way when companies started to merge RFC1918 > networks which required renumbering that it is mostly impossible due to > external parties having your numbers. > > Locally renumbering goes fine as long as it is in your own hands it > works all quite fine. The cases that really need it though have external > places where their numbers are stored. No way around it. > > >> 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. > > That network address is a part of the routing topology, not of the > endpoint address of the host. It's more analogous to changing AS numbers > than anything else. > > >> 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. > > You only address networks and not hosts? There are vendors that only > look at the first 48 bits actually of any IPv6 address. If the match is > longer they offload it to a second chip. Design issues, nothing else. > > [..] > >>> 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. > > Why will it never work and why will it be a major cause for routing > instabilities? > > The only factor in it getting to work is like IPv6: if the gross of the > providers check it, it will work. Fortunately there are already a couple > of ISP's testing this out and it will come sooner or later. > SBGP is like DNS-SEC both look nice on the paper but in real life it fails appart because it is unusable in large systems. > >>> 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. > > If your DNS is down people can't type www.google.com anyway. See the > picture? :) > If people can't type www.google.com and reach the site they call the ISP 20 seconds later to yell at the 1st level support. I hope you will never work at a NOC with that attitude. -- :wq Claudio
