Olli Arnberg
Postipuuntie 3B30
02600 Espoo
Finland
oar@leka.hut.fi
1. Introduction
The following lectures (and papers) deal with some of the interesting features
of IP6; this lecture (and paper) is meant to give a "glimpse" of everything.
2. IP4
The IP4 explanations are from the book by Comer [2].
Refer to it if you have any questions, I try to explain every
field in an extremely short way...
The basic structure of all packets (in IP4, but not in IP6) is the same - obviously a very good one at that time. Now the problem is in RISC-processors: an "if" might totally empty the pipeline. One could argue that the IP6 extension structure is very similar:
The "Header" and "Data" are quite clear, but "Optional fields" contains arguments that are really optional: not every host has any use for those! Most options are used for maintenance purposes.
The header structure is the following:
The VERS field is quite clear: it contains 4. Every other number is considered as an indication of a maltuned packet and thus those packets are discarded.
Field LEN contains the length of the header measured in 32-bit words.
Then there is the field TYPE OF SERVICE. It contains the following things:
PREC contains the presendence for the packet (0=normal packet, 7=network control). Bits D, T, and R contain some information on how the packet should be handled (D=low delay, T=high throughput, R=high reliability). (And NOP=No OPeration, as in assembler.)
The field TOTAL LENGTH gives the total length of the packet in octets. The problem in IP4 seems to be the multitude of different measuring systems (octets and 32-bit words).
The fields IDENT, FLAGS, and FRAGMENT OFFSET control fragmentation. The field IDENT contains a unique integer (it is used for collecting all the separate parts of a fragmented packet). Then the FLAGS-field:
N = Do not fragment and M = More fragments. The field FRAGMENT OFFSET contains just that - it is quite hard to explain such an obvious thing.
TIME (or very often it is called TIME TO LIVE) contains the packet lifetime in seconds (or hops).
Field PROTO contains information of the upper-level protocol, i.e. what the packet contains.
HEADER CHECKSUM is a way to ensure the correctness of the header. All header fields (or, in fact, their 16-bit equivalents) are added together (the field HEADER CHECKSUM contains 0 in this phase) with 1 complement arithmetic. And then one's complement of the results is taken. When this operation has to be done in every router, it means quite an operation!
SOURCE IP ADDRESS and DESTINATION IP ADDRESS. Both addresses are 32-bit units.
The fields OPTIONS and PADDING are used mostly for network configuration.
Depending on the OPTION NUMBER the length might vary.
DATA. Finally, that is the real packet!
2.1 Why these are no good?
The biggest problem in IP4 is clearly the lack of a big enough address field.
Ok, 2^32 is 4.294.967.296, a number that is extremely big.
But the addressing capability wasn't used very efficiently.
| Address class | Bits | Number of nets | Bits | Addresses |
|---|---|---|---|---|
| A | 7 | 128 | 24 | 16 777 216 |
| B | 14 | 16 384 | 16 | 65 536 |
| C | 22 | 4 194 304 | 8 | 256 |
The class B is going to be "empty". One solution is very easy: one B class net is replaced by three C class nets. Pretty good help in a desperate situation.
But another problem aroused from that solution. When one
address is replaced by three , the routers have quite a
problem. The router's memory becomes quite "full" in this way.
3. IP6
3.1 Technical considerations in IP6
The technical considerations are from [2].
In case of any - just any - misunderstandings, it has the truth.
Very often the IP6 is called IPng.
3.2 The actual IP6
There were a great amount of requirements. Now, it's very interesting,
how they've been realized. One really unbelievable thing is that
the number of protocol fields has been decreased! Usually,
technical progress means more fields, but not in this case.
One, very big explanation for that is very practical. Every bit of effort has been the usual processor architecture of today. Processors have a pipeline today. It's a very primitive form of parallel processing. And an "if" might flush the pipeline (which gives very poor performance). So, as few ifs as possible.
But the reasons for that are quite straighforward: Packets aren't fragmented, but they are discarded in that case (and of course error message to sender). Three fields gone!
And then no checksums are calculated. Calculating those takes a lot of time. And if there's an error, the packet probably goes to the wrong place. And a new one is sent away (would happen in the checksum case) And (final and) the higher protocol has it's own checksums.
Now every field in IP6 has to be explained.
| Field | Length of field (in Bits) |
|---|---|
| Ver | 4 |
| Prio | 4 |
| Flow label | 24 |
| Payload length | 16 |
| Next hdr | 8 |
| Hop limit | 8 |
| Source address | 128 |
| Destination address | 128 |
Of course those theoretical figures aren't "true". But one can waste addresses quite much and it's just so possible. There are enough addresses (but "never say never").
Options in IP4 are called extensions in IP6. They are placed in a separate header after the actual header. In fact, just the same thing as in IP4! Ok, every router hasn't to decode every option, but...
| Extension name | What it does |
|---|---|
| Routing | Extended routing (like IP4 source route) |
| Fragmentation | Fragmentation and reassembly |
| Authentication | Integrity and authentication |
| Security encapsulation | Confidentiality |
| Hop-by-Hop Option | Special options which requires processing at every node |
| Destination options | Optional information to be examined by destination node only |
Most extensions have their own presentation (and paper, too).
This is the most simple case. In this case, the "next hdr"-fields say, that a TCP packet follows.
This is a little bit more complicated thing. In the first header the "next hdr"-field says that the routing packet follows. And one must look at that packet (the router should look at routing). If some "don't care"-packet would be here, it could be skipped over easily. And in that header, the "next hdr"-fields say that a TCP packet follows.
3.3 The process of making IP6
(In the checkpoint I said that no-one cares about history as long as
thing works well. The history is interesting things aren't working so
smoothly (who done it?). And that view was received extremely well
(at least everyone laughed - including the professor!).)
The IP4 addressing capability seemed quite big enough: some study said that it was enough to the year 2000 (or so). But when "normal" personal computers were added to the Internet, a real disaster followed!
First the ROAD (ROuting and ADdressing) group was formed. It's main (and nearly only) task was to get some more time. The group was formed in November -91 and it's report was received March -92. Of course the problem had been seen much before! It formed RFC1519, some kind of a "quick and dirty" fix for problems.
Then next group: IAB (subcommittee of Internet Architecture Board). It worked in the late spring of -92. That group made a proposition: IPv7.
In July -93 a meeting was held in Amsterdamm. In that meeting Phil Gross was chosen as the leader of the "new" internet. There were some, very important, things to discuss in that meeting:
A directorate group was formed in that meeting, too.
Some kind of help was RFC1797, which showed how some class "A" nets can be used in smaller chunks.
RFC1719 shoved the demand of IPng. [2] was much more detailed.
The IP6 installation shall start probably in the end of -96. Because
the "old" IP is supported, too, it's not so vitally
important that every host turns to IP6 simultaneously.
4. Conclusions
The basic problem, addressing in IP, is solved for quite some time now.
At the same time, other things have gone in. So, the purpose of
this reform has been fulfilled.
References