Slashdot Mirror
Stack-Hacker Itojun Talks About IPv6
Alert reader Sin Yuhara writes: "I've encountered [an interview in which] Jun-ichiro "itojun"
Ogino(KAME Project Core/NetBSD Core/FreeBSD Comitter)
talks about IPv6. The KAME IPv6 [?] stack is very well
known in the BSD world and beyond. I'm sure IPv6 and
related stuff must deploy, and this article may help all
people." It's a really good read -- itojun talks about the IPv6 tools that are already integrated into the various BSD systems, about the need for ever more testing, and about why Japan rocks.
No .. sorry to dissaponit you.
;)
Win2k german does NOT have build-in IPv6 support ! Really ! I DID test it
There's an addon on the micro$oft website, which you can install to have IPv6, but IIRC it was still labeled BETA the last time I did ceck it out ! (it was about 4 months ago !)
So please stop spreading FUD!
Can you still subnet? I mean, I dont really have a use for 2^64 addresses :) LIke, you cant really fit more than a hundred (the spec is something like 1024 isnt it?) on an ethernet network. I mean, what's the point of using addresses frivilously, when we have the technologies to easily manage addresses more efficiently?
Namely, every subscriber, be it a corporation or a household, gets a /48.
/64 "subnet" (which might even be defensible since some broadband equipment is based on bridging) and thus assigns each customer only one address?
That might be how it's supposed to be used, but that has little effect on how ISPs will actually configure their networks. What if an ISP defines all their customers to be part of one
This is probably the biggest myth of IPv6 - it has precisely one feature beyond what IPv4 supports, the 16 bit flow label field in the IPv6 header, that relates to QoS.
Deploying IPv4 QoS is possible today - I work for a company that makes software to enable QoS in routers, amongst other things, and am helping customers do this. The key approaches are DiffServ (easy to deploy, softer QoS), and RSVP (harder to deploy, harder QoS, and I don't know any real networks that have deployed this).
The IPv6 flow label reduces the load on core routers where RSVP has been deployed, by caching the result of an earlier classification decision (i.e. matching packets against IP adddresses, port numbers, etc). However, it's hardly a big step forward for QoS if you are using DiffServ as most networks do.
What's more important for QoS is that IPv6 will (eventually) make NATs much less popular. Trying to classify NATed traffic is a nightmare, of course, and IPv6 should make things easier.
My company also does MPLS stuff - interestingly, this will help IPv6 deployment, because the big fast core routers will NOT need to have their forwarding hardware upgraded to forward IPv6 packets. MPLS labels packets near the edge of the network, and once labelled the packets are forwarded using ONLY the 32 bit MPLS label. Hence the IPv6 headers are only inspected on the edge router for the MPLS network.
The result is that the core routers only need to run IPv6 routing software, not IPv6 forwarding - hence no need to replace those ASICs. The edge routers are typically small enough that they should be able to run IPv6 forwarding in software.
Of course, as someone else already pointed out, there is still a lot of work before the ISPs' routers get fully upgraded with the entire set of add-on protocols - routing, multicast, PPP, RADIUS, IP-over-ATM, and so on.
Many people seem to use NAT for security purposes, because it makes it harder for outsiders to connect to internal machines. Of course, NAT is not meant for this, and has potential holes (e.g. if the NAT software fails it may just forward packets straight through, as has happened on at least some NAT boxes), but that's what a lot of people think.
Until people manage their host and firewall security a lot better, many sites may just stick with NAT because it's what they know, removing a key benefit of using IPv6. So perhaps improved security processes and technology are a prerequisite for IPv6 deployments.
go to www.kame.net there is a list of applications that work with IPv6 there.
First of all, the IPv6 header is actually more regular than the IPv4 header - fewer fields, and only twice the size of IPv6 despite addresses that are four times larger. Also, the routing tables for IPv6 are supposed to be more regular, so the performance impact on software-based routers may not be that much.
The vast majority of IPv6 packets will not have options - yes, they need to be looked at if present, but in that case you just dump the packet into a slow path. Also, MPLS will help here (see below) - the packet should only hit the slow path on lower end routers.
As for core routers that use forwarding ASICs - the answer is to implement MPLS, starting on edge routers that forward IPv6 in software, and attach MPLS labels. The core routers ONLY see the 32 bit MPLS label, so there is no problem about forwarding IPv6 just as efficiently as IPv4, once it is MPLS labelled. The core routers need to run IPv6 routing processes, but that's just on the main CPU.
MPLS is already deployed in ISP and telco IP networks - it is currently used for traffic engineering (balancing traffic loads over the network) and MPLS VPNs, and the same technique will be used to carry ATM, Frame Relay, Ethernet and SONET.
In the longer term, new routers will come on the market with smart enough ASICs and network processors to handle IPv6 with no reduction in forwarding rates, but MPLS will be useful for those ISPs that want its extra features.
What, 65536 networks isn't enough for you, you need to subnet as well? :)
One of the reasons to have 2^64 host addresses is so that you can use globally unique EUI64 host addresses (for example, for Ethernet, based on the hardware MAC address) to allow immediate auto-configuration on any network anywhere in the world without any chance of an IP address conflict or having to do manual assignments. (Manual assignments are also supported, though.)
There's more than one kind of efficiency; part of the idea of IPv6 is to make routing simpler to gain speed and avoid abominations like NAT. Anyway, only 15% of the address space has even been defined so far; 85% is still reserved for future uses! I wish people would bother to learn about things before commenting.
http://www.glasswings.com/
stop whining.
He asks why anyone still uses NAT seeming to say that with ipv6 noone will need to use NAT. I personally use NAT so I don't have to pay my isp 40$ extra every month to have all my machines hooked up. Are ISPs going to just start handing out ipv6 address for free, I don't think so. I can't wait until my isp just hands out subnets, not individual addresses.
Go, Japan!
-- Stanislav Shalunov
- Hubert
I don't see IPv6 taking off any time. IPv6 problem is not just a deadlock between ISPs and router manufacturers. The big roadblock on the way towards TWGD (i.e. total worldwide global domination, let's see if this one sticks ;-) is that IPv6 doesn't fit well in hardware acceleration. IPv6 has huge and variable headers, which are a pain in the bottom end to process in hardware.
... an option. Even core routers must completely walk the header chain of each packet.
... as an exception, using the CPUs. The performances are merely catastrophic. IPv6 is not really practical with current router architecture. May be an IPv7 will come, one day when IPv4 is really breaking at the seams.
... that just my $0.02 on IPv6 ...
IPv4 is much nicer. Only the first few hundreds bits in the packets really matter. Sure, an IPv4 header can be much bigger with options. It's just that nobody expects those options to be implemented. With IPv6, ignoring options is not
The reason is that the IPv6 effort was started in the early 90s at a time when IP routers where basically a bunch of interfaces and DMA engines around a shared packet buffer with a CPU in the middle chopping and tweaking the headers to route the packets. All the decisions were made by software, and, sometime in low cost routers, the CPU even performed the data transfers with the interfaces, no DMA. The IPv6 was built with this architecture in mind and requires the routers to do a lot of smart gee whiz things on the headers. That clean architectural model is alas obsolete.
Nowadays, routers' CPUs nearly never see a packet. All the routing is completely done in hardware. The CPUs just do housekeeping, maintaining the routing tables, collecting and processing statistics, that kind of stuff. The only packets they ever see are those for network maintenance, SNMP, etc, and routing protocols, OSPF, IGRP, BGP, you name it.
In serious routers, the real stuff happens between the switch fabric and the routing processors. The switch fabric, centralized or distributed, handles the bulk of the data transfers, receiving and sending packets between the interfaces and the packet buffers. Here, the unit is the gigabit per seconds (a few tens or hundreds of Gb/s or even Tb/s). When the switch fabric receives a packet, it stores it in a buffer and at the same time extract a few hundred bits of the header and forwards that to routing processors, a huge pipeline of table lookups and processing, 100% hard-coded in silicon.
After a while, the routing processors spit an answer to the switch fabric to flush or forward the packet with updated data for the variable fields (the TTL for instance, or even the whole header on NAT or multicast), or to create new packets. For instance, ISMP packets on TTL timeout can be completely generated in hardware! The unit there is the 100s of millions of packets per second. Go do that with CPUs... Worst of all, the IPv6 headers are highly variable and that completely screws up pipeline design where it's much better to handle bounded amount of data.
So, on current routers, IPv6 is supported
Oh well
Great; now we can all steal the *BSD IP stack again. :)
Thanks, *BSD, for continuing to be the research arm of the software community...
Will the real Bruce Perens Please Stand Up
Well, of course there is the traditional killer app that can tip the balance real quickly. For example, RIPE (the European IP address agency) received a phone call one day from a cellphone operator that they needed two class A address ranges, and when could they get them?
Of course, those guys were sent back to the drawing board. But if one of the bigger handset manufacturers starts deploying IPV6 (and IPV6 is complete enough to do that right now), the balance of power would shift and a lot of folks would be forced to keep up with the Joneses.
As you say, my concern is with the infrastructure more than with client support. Microsoft has been mentioned a lot in this thread, and I would be greatly surprised if they didn't have something in the wings to at least work around lack of native IPV6 support for existing clients (like 6to4 support).
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
Which is not on be default so the OpenBSD page can still retain the "Three years without a remote hole in the default install!"!
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
Unfortunately, you are wrong. Microsoft® WindowsNT® and Windows2000® products can give you a reliability guarantee that no other products, certainly not this supposedly 'free' software, can provide. That's right, the nine fives promise. You heard it correctly. Microsoft will guarantee an uptime of %55.5555555. Yes: More than half of the time, your servers will be up and running, allowing you to take advantage of the new, electronic economy. With that kind of power, you can transform your business. That's the kind of leverage Microsoft provides.
War3 doo u w4nt 2 g0 70d@y!!!1©
And I quote: "ARIN will not collect subscription fees for those current ARIN IPv4 subscribers who request and qualify for IPv6 address space. ... Those IPv4 subscribers who have already paid fees for IPv6 address space are eligible for a refund of those fees."
What you're saying is opposite from this part of The Case for IPv6:
"IPv6 encodes IP header options in a way that streamlines the forwarding process. Optional IPv6 header information is conveyed in independent "extension headers" located after the IPv6 header and before the transport-layer header in each packet. Most IPv6 extension headers are not examined or processed by intermediate nodes (in contrast with IPv4). This enables a big improvement in the deployability of optional IPv6 features, compared to IPv4 where IP options typically cause a major performance loss for the packet at every intermediate router."
ISP's *WILL* hand out ipv6 addresses for free, because that's how it's designed. It will be easy for an ISP to get a /64 (that means half the bits will be available for them to assign) which is a size that is larger than the current internet nowadays times itself (due to address wastage).
It is ENTIRELY possible, and will be commonly done, to assign large blocks to each user, so as many devices as they want can be online, AS IT SHOULD BE.
1) T3's are a lot more than that....
2) Your summary is essentially correct, but the root cause of the way ISP's charge is.... that's their business model. They don't care about charging for bandwidth, because the vast majority of their customers have the same usage habits. Someone who actually uses the bandwidth they pay for is a 'bad net citizen' or an 'abuser'.
That is why ISP's will invariably, eventually, shift to a model where you pay for what you use.
I tell you, if @home would come to me when I use lots of bandwidth and say 'look, you use three times the bandwdith of our averagesubscriber... so we want you to pay 3 times as much' I'd probably say 'Okay.. sounds fair'. But they don't, they just cut you off.
All MS operating systems SINCE 2000 (with the exception of ME) have built-in IPv6 support. Whistler has it, 2000 (all versions) has it.
Its just a matter of what kernel they were working from. 2000's supported it, 98's didnt.
They are already dropping support for 98+98se, I really dont think ME is far behind.
They arent holding ANYTHING up.
GPL'd web-based tradewars themed space game
It's not totally stupid - one of the problems that does need to be solved by any widespread replacement of the current IPv4 stack is routing table size for the Big Internet, as BGP usage continues to multiply. IPv6 has some support for efficiency and consolidation, but there's still a lot of work to be done.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It doesn't work that way -- it has nothing to do with hard drive companies holding out. There are serious technical reasons why this trend can't continue until new, radically different data storage technologies pick up steam.
As data gets more and more tightly packed onto the platters, the energy that holds the magnetic spin on each bit (determining whether it's a 0 or a 1) gets less and less significant, and now it is so close to the ambient thermal energy that bits are randomly flipping and corrupting data.
So they're looking at a lot of different techniques, but instead of my trying to explain them, let me just show you the Scientific American article where this is all coming from.
--------------------------------
It's too bad this article didn't mention that you do not need to wait for your ISP; you can start using IPv6 today with 6to4. Slashdot ran a story about how to configure 6to4 under BSD, and here are the instructions for Linux.
I know someone is going to mention that freenet6 or the 6bone is also easy to use, but they're much less efficient than 6to4.