Slashdot Mirror
IANA Deploying IPv6
According to this Wired news article,
IANA has begun to "roll out" IPv6. Though it doesn't go into specifics,
one assumes this means that the three major IP registries will
begin assigning IPv6 addresses. The article mentions another
chicken and the egg problem: no IPv6 software (correct me if I'm wrong,
but doesn't Linux have IPv6 software?), so there is no need for IPv6 addresses, and vice-versa. It
also mentions every traffic light on the planet could have its own IP. Update: 07/16 02:48 by J : Dave Whitinger at LinuxToday sent a
link to a mail which clarifies the situation a bit.
IPv6 has 128-bit addressing - enough for every particle in the universe to have its own subnet. This was deliberate. IPv4 isn't really running out of addresses - it's just that IP addresses can't be given out of the whole pot. The address space must be subdivided in order to allow routers to do their job. The IPv6 address space was therefore made large enough that it can be assigned extremely sparsely, without running out of addresses at the subnet level.
There's plenty of IPv6 software to go around, actually - in fact there are many implementations not only of the IPv6 stack, but of protocol layers to allow IPv6 and IPv4 stacks to interoperate. It's just that they're all in beta, and not very many vendors have announced them as products yet. But you can run Linux or *BSD on an IPv6 net today.
In fact, there's a vigorous "6BONE" (like the MBONE) of IPv6-only hosts existing on the current IPv4 Internet via tunneling arrangements. The 6BONE is the proving ground of IPv6 interoperability and routing stuff.
Microsoft Research has a v6 stack for windows, and so does Trumpet Winsock. Windows users can run v6 any time they like.
See www.ipv6.org if you want to track down versions for your favorite OS.
Some confusion here :)
- Unicast is when a packet goes to exactly one destination and is what IPv4 uses most of the time (e.g. for http etc)
- Multicast is as konstant said, you send out one packet to a 'group address' and it gets replicated only where necessary - generally each link sees only one copy of each packet, so it's an efficient way to send audio, video or even files to a large audience. This is also in IPv4.
- Anycast is new in IPv6 - as I understand it, it lets you specify that any of a set of hosts can get the packet (but not all of them, as in multicast). It's useful for lots of things such as load balancing across servers - not sure if it does topologically-distant load balancing but it would be handy if it does.
One other misconception: IPv6 has two main features for class of service / quality of service, both in the IPv6 header:
- Traffic Class - single byte, equivalent to the IPv4 Type of Service byte, carries the class of service - will be a diffserv codepoint (number) once this is standardised, as is happening quite fast. Same codepoints work over IPv4 and IPv6 networks. Typically you assign different codepoints to VoIP, mission-critical apps, web browsing, etc - many apps share the same CoS.
- Flow Label - this is designed to make RSVP work better, allowing a single flow (e.g. ftp session) to be given a unique ID so that routers downstream of this label assignment can more quickly recognise (classify) packets in this flow (rather than looking at IP addresses, TCP/UDP port numbers, and IP protocol).
For more information on QoS/CoS (though not IPv6 specific) see www.qosforum.org, or the www.orchestream.com links page.
Certainly routing tables should be limited in size with IPv6, which is a good thing but unlikely to make packet forwarding faster.
:)
QoS I think is in the main header (Class byte and Flow Label). As for packet spoofing, IPv6 simply makes IPsec mandatory, whereas it is optional with IPv4 - however, this is an important step. Of course, IPsec means that much traffic is encrypted (potentially) making it harder to do QoS except by letting the host do its own CoS marking and/or RSVP reservations (which let you guarantee bandwidth end to end IF the network has RSVP enabled).
The interesting stuff for Linux here is Linux-Diffserv and the Linux port of RSVPD, which enable the host to do CoS marking and RSVP reservations. However, unlike Win2000, the *nix world does not have a unified QoS API - some work to be done there for *nix to remain competitive IMO.
There is a lot of work going on in the IETF around QoS, CoS, and policy (i.e. rules that govern which apps/users get which QoS/CoS). Werner Almesberger, the Linux Diffserv guy, is at the IETF this week (as I am) and gave a presentation at the Diffserv deployment BOF.
Interestingly, Linux is way ahead of most OSs and routers in its Diffserv implementation, and apparently it can fill an OC-3 (155 Mbps optical) line while doing CBQ queuing (flexible allocation of bandwidth, see www.xedia.com for links), with 12,000 policy rultes. For those who are not in the CoS business, this performance is extremely impressive compared to some commercial routers - just buy a cheap headless PC and you have a $1000 access router with Diffserv CoS, which can also do firewalling, IPsec VPNs, etc.
If anyone's doing trials of Diffserv and wants a tool to manage policy rules for CoS efficiently, email me
According to the allocation draft document, http://www.arin.net/IPv6.txt, the 3 Registries
won't be initially assigning IP addresses to end users or sites. Instead, they'll be making sub-delegations to TLA registries (a sub-continental registry that will make allocations after the 1st 16 bit boundary of an
ipv6 subnet). So, ARIN, APNIC, and RIPE will begin
issuing TLA's to the TLA registries, who in turn,
will begin making allocations at the NLA level level. These NLA assignments will go to large ISP's. Assignments to individual sites and end-users will be carved out of these NLA assignments.
The last 64 bits is a hard boundary reserved for
the host ID (based on the next-generation EUI-64
MAC address).
Glossary:
TLA: Top-Level Aggregator
NLA: Next-Level Aggregator
SLA: Site-Level Aggregator
Yeah, it will be called "Burnt Orifice."
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
IPv0 is reserved v1-3 are unassigned IPv4 is in use now IPv5 is the internet stream protocal. RFC's 1340 and 1700 might help. RFC 1819 covers version 2 of the internet stream protocal which is of course IPv5. Damn im smart.
"As more and more devices connect to the Net -- computers, handhelds, set-top boxes, and, eventually, toasters and microwaves -- all will need unique identifiers."
woohoo! now I can finally telnet to my neighbor's toaster and burn his toast!
What happened to IPv5?
If you're just using normal (stream or datagram) sockets, the interface isn't very different. The main issues are that you're now in the AF_INET6 domain, and sockaddr_* structs for IPv6 have a different address layout. Apart from that, your code should be pretty much the same.
You can avoid having to worry about this by using the POSIX getaddrinfo() function, but sadly it's not available everywhere yet.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
As someone else noted, IPv4 is nowhere near exhausting the supply of IP addresses. The problem is really that the IP#s have been subdivided into hierarchies A-E:
:) So one problem addressed by IPv6 was the expanded IP# values. Lots of room for divisibility.
;) it would know which packets were important and which could be dropped safely. You'd probably have to pay extra for high-priority transmissions, which means as an added benefit that crackers would have a harder time taking down machines they didn't like by packet flooding them or whatever.
Class A: For big monster domains like ARPAnet
2^7 domains*16 million hosts each
Class B: For medium domains like your ISP
2^14 domains*65536 hosts each
Class C: For subnets and labs and stuff
2^22 domains*255 hosts each
Class D: For subnet-only multicast
Class E: nobody ever really used this
Trouble was that everybody wanted something bigger than C, but didn't really need all the addresses in B. So a lot were wasted every time a B class was assigned. There are some kludgy solutions like masking and sewing together lots of C's into one bigger domain, but they all are horribly complicated and a waste of brainpower as anybody who has ever taken a networking course can attest
A second problem was that IPv4 was basically all about sending text from one spot to another, and there was a lack of optimization for high-prio data and multicast data like streaming video. The reason you'll see a lot of patches for IPv6 stuff is not that it isn't backwards compatible with IPv4 so much as that IPv6 has lots of cool features people will want to take advantage of. For example, you can mark the priority of your packets on a scale of (I think?) 1-5, with servers optionally enforcing these values. When a server was in the process of getting slashdotted for example (or some other DoS attack
As another example, the IPv6 packet structure basically lets you chain "extensions" onto your packet, giving you a sort of dynamic packet size.
Another biggie is internet-wide multicasting. A group of people receiving the same streaming video wouldn't have to be sent separate copies from the originating server. It could send one and have intermediate routers spawn copies.
A lot of the pain of setting up a new host is also eliminated. There's some kind of dynamic search-and-allocate thing built in that I don't remember well enough to discuss. Something about new hosts asking their neighbors for a globally unique IP address and eventually getting one.
There's more. Get Tanenbaum's book on networking and find out for yourself.
-konstant
-konstant
Yes! We are all individuals! I'm not!