Przyszłość INTERNETU

Protokół IPv4 vs IPv6

Wykonany przez

Kazimierz Bąchór
kazbac@op.pl

IPv4 kontra IPv6

Wprowadzenie | Zadanie | Proces | Ewaluacja | Konkluzja | Uwagi | Źródła, zasoby


Wprowadzenie

W ciągu kilku najbliższych lat będzie wprowadzany sukcesywnie konnkurencyjny protokół internetowy: IPv6. Obecny protokół internetowy: IPv4 ma ograniczoną "pulę adresów internetowych" ze względu na ilość bitów adresu IP(w wersji 4). Przyszłościowy protokół internetowy: IPv6 jest 4-ro krotnie dłuższy pod względem ilości bitów. Projekt ma przekonać ucznia o nadchodzącej zmianie jakościowej w obsłudze Internetu (i nie tylko) przez wprowadzenie nowego protokołu.

Zadaniem podstawowym dla ucznia jest wyszukanie w Internecie informacji nt. protokołu IPv6. Dodatkowym zadaniem dla ucznia jest poszukanie w Internecie informacji nt. protokołu obecnie używanego (IPv4). Ze względu na duże zainteresowanie uczniów przyszłością Internetu temat projektu dotyczący nowego protokołu IPv6 powinien być realizowany z dużym zaangażowaniem przez uczniów.

 

Wróć do początku


____________________________________________________________

Zadania dla uczniów:

  • Wyszukanie w Internecie kilku stron internetowych (min. 3) opisujących protokół IPv6.
  • Wyszukanie w Internecie kilku stron internetowych (min. 3) opisujących protokół IPv4.
  • Z wybranych stron internetowych wybrać najważniejsze informacje dotyczące postawionych zadań i zredagować w edytorze tekstowym.
  • Dokonać porównania kilku podstawowych parametrów dla tych dwóch protokołów. Wyniki przedstawić w tabeli.
  • Obliczyć ilość adresów internetowych dla protokołu IPv4.
  • Obliczyć ilość adresów internetowych dla protokołu IPv6.
  • Opracować wnioski nt. korzyści wynikających z zastosowania nowego protokołu IPv6.

Produktem końcowym powinien być opracowany tekst dotyczący postawionych zadań i zredagowany w edytorze.

Dodatkowo należy przedstawić w tabeli porównania podstawowych parametrów tych protokołów. Obliczenia przestrzeni adresowej dla tych protokołów (IPv4 i IPv6) zestawić w tabeli.

 

Wróć do początku


Proces

Projekt powinien być realizowany w grupach 3 lub 4 osobowych, albo ewentualnie mieszanych tzn. grupy 3 i 4 osobowe. Taka kombinacja dzielenia grupowego pozwala na efektywniejszą pracę grupową uczniów, gdyż przy podziale jednorodnym może się zdarzyć że pozostanie uczeń bez przydziału grupowego, np. gdy jest 10, 13, 16 uczniów i chcemy mieć grupy 3 osobowe. Jeśli jednak podział jednorodny na grupy 3 lub 4 osobowe daje sensowne rozwiązanie, (tzn. dla grup 3 osobowych nie zostanie uczeń bez przydziału grupowego) - należy go zrealizować. W przypadku takim może być jedna grupa 2 osobowa, która powinna otrzymać zadania specjalne i być rozliczana inaczej niż pozostałe. Nie należy tworzyć tylko grup 2 osobowych, gdyż przy licznej klasie będzie ich dużo i uczniowie bedą pracowali mało efektywnie. Grupy 2 osobowe są ewentualnie "dopuszczalne" dla bardzo prostych projektów. Dla grup mieszanych należy podać 2 warianty zadań: wariant podstawowy dla grup 3 osobowych i rozszerzony dla grup 4 osobowych.

  1. Podział uczniów na grupy: 3 lub 4 osobowe
  2. Przydział zadań dla grup 3 osobowych
  3. Przydział zadań dla grup 4 osobowych

Można dla grup 4 osobowych podać przydział zadań podobnych jak dla grup 3 osobowych, z tym że 4-ty uczeń z grupy może realizować zadanie specjalne tzn. będzie opracowywał zbiorcze "sprawozdanie" na podstawie opracowanych przez 3 pozostałych uczniów materiałów "jednostkowych". Jeśli to zbiorcze "sprawozdanie" będzie nie tylko kopią pracy pozostałych uczniów, ale zawierać będzie "dopiski" merytoryczne; można takiego ucznia wyróżnić na tle klasy i podwyższyć ocenę za pracę grupową. Dodatkowo może wybrać z tych 3 materiałów jeden bazowy (najlepiej opracowany) i uzupełnić go swoimi wnioskami lub "dopiskami" merytorycznymi.

Można wyznaczyć w każdej grupie lidera, którego dodatkowym zadaniem będzie zebranie prac poszczególnych uczniów (z grupy) i takim ich przeredagowaniu, aby powstała praca zbiorcza dla każdej grupy; która w pełni oddaje efekt pracy grupowej. Nauczyciel może wybierać liderów grup (i raczej powinien to robić), gdyż właœciwy lider podoła temu zadaniu - polegajšcemu na "przefiltrowaniu" prac uczniów (z grupy) i zredagowanie na podstawie tych prac uczniowskich pracy zbiorczej, która powinna być pozbawiona błędów merytorycznych.

Należy tworzyć grupy w których uczniowie mają podobne osiągniecia w informatyce, gdyż przy skrajnościach (1 uczeń bardzo zdolny a pozostali słabo radzący sobie z pracą przy komputerze) praca grupowa będzie mało efektywna. Jeśli jednak taka grupa musi być utworzona to nauczyciel powinien dla niej podać zadania specjalne, aby dostosować ich wykonanie do zdolności uczniów.

 

Wróć do początku


Ewaluacja

Lider grupy podlega innej ocenie, gdyż jego praca jest bardziej odpowiedzialna i wymaga większego wysiłku przy tworzeniu sprawozdania zbiorczego.

Wymagania

Podstawowe

1

Rozszerzające

2

Dopełniające

3

Wykraczające

4

Punkty

 

Jakość opracowanego tekstu w edytorze

 

Brak błędów ortograficznych. Poprawne formatowanie znakowe. Brak odstępów przed znakami interpunkcyjnymi.
To co dla wymagań podst. i dod. Poprawne zdania gramatycznie. Poprawne formatowanie akapitowe. Odstępy po znakach interpunkcyjnych.
To co dla wym. roz. i dod. Poprawne zdania stylistycznie. Poprawne formatowanie tabeli.
To co dla wyma. dop. i dod. Formatowanie znakowe w oparciu o style. Formatowanie akapitowe z użyciem stulu akapitowego.
15

 

Wyszukanie stron w Internecie zaw. opis IPv4 i zredagowanie informacji nt. protokołu IPv4 w edytorze.

 

 

Znalezienie 3 stron w Internecie opisujących protokół IPv4. Opracowanie tekstu ( w edytorze) nt. podstawowych cech protokołu IPv4. Podanie zakresów adresów internetowych dla klas: A, B i C. Podanie ogólnego wzoru (w notacji "kropkowej") adresu IP.
To co dla wymagań podst. i dod. Podanie zakresów prywatnych adresów internetowych dla klas: A, B i C. Podanie adresów masek standardowych dla klas: A, B i C.
To co dla wymagań roz. i dodatkowo Podanie zakresów adresów ID (adres IP zakończony "0" w ostatnim oktecie) sieci dla klasy A. Podanie adresów masek standardowych dla klas: A, B i C w notacji CIDR. Przykłady ważnych adresów w Internecie: pętli zwrotnej i rozgłoszeniowego.
To co dla wymagań dop. i dodatkowo Podanie zakresów adresów ID sieci dla klasy B i C. Podanie metody tworzenia podsieci komputerowych w oparciu o adresy ID sieci w klasach internetowych: A, B i C
30

 

Wyszukanie stron w Internecie zaw. opis IPv6 (protokół nowej generacji - IPng) i zredagowanie informacji nt. protokołu IPv6 w edytorze.

 

 

Znalezienie 3 stron w Internecie opisujących protokół IPv6. Opracowanie tekstu ( w edytorze) nt. podstawowych cech protokołu IPv6. Przykłady kilku (min. 3) adresów internetowych (nowej generacji) IPv6 w preferowanej postaci,tzn. zapisanej jako 32 "liczby heksalne".
To co dla wymagań podst. i dod. Przykłady kilku (min. 3) adresów internetowych (nowej generacji) IPv6 w skompresowanej postaci, tzw. postaci skróconej. Adres pętli zwrotnej zapisany w preferowanej i w skompresowanej postaci.
To co dla wymagań roz. i dodatkowo Przykłady kilku (min. 3) adresów internetowych (nowej generacji) IPv6 w mieszanej postaci, tzn. adres IPv6 z "osadzonym" adresem IPv4. Adres rozgłoszeniowy przedstawiony w postaci preferowanej i skompresowanej.
To co dla wymagań dop. i dodatkowo Zasady podziału podsieci komputerowe dla IPv6. Lokalne adresy "węzła" sieciowego dla IPv6. Adresy grupowe.
25

 

Przedstawienie przestrzeni adresowej dla tych 2 protokołów: IPv4 i IPv6; oraz wnioski porównawcze tych protokołów.

 

 

Policzenie ilości adresów IPv4 ogólnie. Obliczenie ilości adresów hostów w klasie A. Podanie przestrzeni adresowej dla IPv6. Zalety protokołu IPv6.
To co dla wymagań podst. i dod. Obliczenie ilości adresów hostów w klasie B. Policzenie ilości sieci komputerowych w klasie A i B. Podobieństwa i różnice protokołów: Pv4 i IPv6.
To co dla wymagań roz. i dodatkowo Obliczenie ilości adresów hostów i sieci w klasie C. Obliczenia iloœci hostów w podsieciach 1-no, 2 i 3 bitowych w klasie C. Porównanie struktur obu protokołów: IPv4 i IPv6.
To co dla wymagań dop. i dodatkowo Obliczenia iloœci hostów w podsieciach 1-no, 2 i 3 bitowych w klasach:A i B. Architektura protokołów: Pv4 i IPv6.
30

 

Wróć do początku


Konkluzja

Co nas czeka w nieodległej przyszłości?.....
Może to być nowa rewolucja informatyczna na skalę tej z roku 1981 (zbudowanie 1-szego PC przez IBM) !!!!!!
Oto kilka faktów o tym przemawiających:
1. Według opracowań firm zajmujących się rozwojem Internetu do roku 2011 wyczerpie się pula adresowa oparta o protokół obecny (IPv4).
2. W 1992r. organizacja IETF(Internet Engineering Task Force) przedstawiła nowy protokoł IP nazwany "next generation" i oznaczany skrótem: IPng - i tak powstał IPv6.
3. W 1996r. powstała w Anglii sieś szkieletowa 6bone (oparta na nowym protokole IPng (nazywanym też IPv6.

Odnośnie ostatniej informacji w tej sieci szkieletowej 6bone uczestniczy 57 krajów - jest w niej ponad 1000 "lokaliacji". Dane nt. krajów uczestniczšcych w sieci "6bone" udostepniane są na stronie Uniwersytetu Lancaster.






















 

Wróć do początku


Uwagi

W projekcie uwzględniono zadania dotyczące podsieci komputerowych w oparciu o protokół IPv4.
Zadania te są objęte wymaganiami dopełniającymi i Wykraczającymi. Z tego względu najlepiej je zrealizować w grupach 4 osobowych.
Bardzo ważne sš dokumenty typu RFC(Request for Comment). Pierwszy powstał w 1969.
Oto pierwszy RFC:
Network Working Group Steve Crocker
Request for Comments: 1 UCLA
7 April 1969
Title: Host Software
Author: Steve Crocker
Installation: UCLA
Date: 7 April 1969
Network Working Group Request for Comment: 1
CONTENTS
INTRODUCTION
I. A Summary of the IMP Software
Messages
Links
IMP Transmission and Error Checking
Open Questions on the IMP Software
II. Some Requirements Upon the Host-to-Host Software
Simple Use
Deep Use
Error Checking
III. The Host Software
Establishment of a Connection
High Volume Transmission
A Summary of Primitives
Error Checking
Closer Interaction
Open Questions
RFC 1 Host Software 7 April 1969
IV. Initial Experiments
Experiment One
Experiment Two
Introduction
The software for the ARPA Network exists partly in the IMPs and partly in the respective HOSTs. BB&N has specified the software of the IMPs and it is the responsibility of the HOST groups to agree on HOST software. During the summer of 1968, representatives from the initial four sites met several times to discuss the HOST software and initial experiments on the network. There emerged from these meetings a working group of three, Steve Carr from Utah, Jeff Rulifson from SRI, and Steve Crocker of UCLA, who met during the fall and winter. The most recent meeting was in the last week of March in Utah. Also present was Bill Duvall of SRI who has recently started working with Jeff Rulifson. Somewhat independently, Gerard DeLoche of UCLA has been working on the HOST-IMP interface. I present here some of the tentative agreements reached and some of the open questions encountered. Very little of what is here is firm and reactions are expected. I. A Summary of the IMP Software
Messages
Information is transmitted from HOST to HOST in bundles called messages. A message is any stream of not more than 8080 bits, together with its header. The header is 16 bits and contains the following information: Destination 5 bits
Link 8 bits
Trace 1 bit
Spare 2 bits
The destination is the numerical code for the HOST to which the message should be sent. The trace bit signals the IMPs to record status information about the message and send the information back to the NMC (Network Measurement Center, i.e., UCLA). The spare bits are unused. RFC 1 Host Software 7 April 1969
The link field is a special device used by the IMPs to limit certain kinds of congestion. They function as follows. Between every pair of HOSTs there are 32 logical full-duplex connections over which messages may be passed in either direction. The IMPs place the restriction on these links that no HOST can send two successive messages over the same link before the IMP at the destination has sent back a special message called an RFNM (Request for Next Message). This arrangement limits the congestion one HOST can cause another if the sending HOST is attempting to send too much over one link. We note, however, that since the IMP at the destination does not have enough capacity to handle all 32 links simultaneously, the links serve their purpose only if the overload is coming from one or two links. It is necessary for the HOSTs to cooperate in this respect.
The links have the following primitive characteristics. They are always functioning and there are always 32 of them.
By "always functioning," we mean that the IMPs are always prepared to transmit another message over them. No notion of beginning or ending a conversation is contained in the IMP software. It is thus not possible to query an IMP about the state of a link (although it might be possible to query an IMP about the recent history of a link -- quite a different matter!).
The other primitive characteristic of the links is that there are always 32 of them, whether they are in use or not. This means that each IMP must maintain 18 tables, each with 32 entries, regardless of the actual traffic.
The objections to the link structure notwithstanding, the links are easily programmed within the IMPs and are probably a better alternative to more complex arrangements just because of their simplicity.
IMP Transmission and Error Checking
After receiving a message from a HOST, an IMP partitions the message into one or more packets. Packets are not more than 1010 bits long and are the unit of data transmission from IMP to IMP. A 24 bit cyclic checksum is computed by the transmission hardware and is appended to an outgoing packet. The checksum is recomputed by the receiving hardware and is checked against the transmitted checksum. Packets are reassembled into messages at the destination IMP.
Open Questions on the IMP Software
RFC 1 Host Software 7 April 1969
1. An 8 bit field is provided for link specification, but only 32 links are provided, why?
2. The HOST is supposed to be able to send messages to its IMP. How does it do this?
3. Can a HOST, as opposed to its IMP, control RFNMs?
4. Will the IMPs perform code conversion? How is it to be controlled?
II. Some Requirements Upon the Host-to-Host Software
Simple Use
As with any new facility, there will be a period of very light usage until the community of users experiments with the network and begins to depend upon it. One of our goals must be to stimulate the immediate and easy use by a wide class of users. With this goal, it seems natural to provide the ability to use any remote HOST as if it had been dialed up from a TTY (teletype) terminal. Additionally, we would like some ability to transmit a file in a somewhat different manner perhaps than simulating a teletype. Deep Use
One of the inherent problems in the network is the fact that all responses from a remote HOST will require on the order of a half-second or so, no matter how simple. For teletype use, we could shift to a half-duplex local-echo arrangement, but this would destroy some of the usefulness of the network. The 940 Systems, for example, have a very specialized echo.
When we consider using graphics stations or other sophisticated terminals under the control of a remote HOST, the problem becomes more severe. We must look for some method which allows us to use our most sophisticated equipment as much as possible as if we were connected directly to the remote computer.
Error Checking
The point is made by Jeff Rulifson at SRI that error checking at major software interfaces is always a good thing. He points to some experience at SRI where it has saved much dispute and wasted effort. On these grounds, we would like to see some HOST to HOST checking. Besides checking the software interface, it would also check the HOST-IMP transmission hardware. (BB&N claims the HOST-IMP hardware will be as reliable as the internal registers of the HOST. We believe
RFC 1 Host Software 7 April 1969
them, but we still want the error checking.)
III. The Host Software
Establishment of a Connection
The simplest connection we can imagine is where the local HOST acts as if it is a TTY and has dialed up the remote HOST. After some consideration of the problems of initiating and terminating such a connection , it has been decided to reserve link 0 for communication between HOST operating systems. The remaining 31 links are thus to be used as dial-up lines.
Each HOST operating system must provide to its user level programs a primitive to establish a connection with a remote HOST and a primitive to break the connection. When these primitives are invoked, the operating system must select a free link and send a message over link 0 to the remote HOST requesting a connection on the selected link. The operating system in the remote HOST must agree and send back an accepting message over link 0. In the event both HOSTs select the same link to initiate a connection and both send request messages at essentially the same time, a simple priority scheme will be invoked in which the HOST of lower priority gives way and selects another free link. One usable priority scheme is simply the ranking of HOSTS by their identification numbers. Note that both HOSTs are aware that simultaneous requests have been made, but they take complementary actions: The higher priority HOST disregards the request while the lower priority HOST sends both an acceptance and another request.
The connection so established is a TTY-like connection in the pre-log-in state. This means the remote HOST operating system will initially treat the link as if a TTY had just called up. The remote HOST will generate the same echos, expect the same log-in sequence and look for the same interrupt characters.
High Volume Transmission
Teletypes acting as terminals have two special drawbacks when we consider the transmission of a large file. The first is that some characters are special interrupt characters. The second is that special buffering techniques are often employed, and these are appropriate only for low-speed character at time transmission.
We therefore define another class of connection to be used for the transmission of files or other large volumes of data. To initiate this class of link, user level programs at both ends of an established TTY-like link must request the establishment of a file-like connection parallel to the TTY-like link. Again the priority scheme comes into play, for the higher priority HOST sends a message over link 0 while the lower priority HOST waits for it. The user level programs are, of course, not concerned with this. Selection of the free link is done by the higher priority HOST.
File-like links are distinguished by the fact that no searching for interrupt characters takes place and buffering techniques appropriate for the higher data rates takes place.
A Summary of Primitives
Each HOST operating systems must provide at least the following primitives to its users. This list knows not to be necessary but not sufficient.
a) Initiate TTY-like connection with HOST x.
b) Terminate connection.
c) Send/Receive character(s) over TTY-like connection.
d) Initiate file-like connection parallel to TTY-like connection.
e) Terminate file-like connection.
f) Send/Receive over file-like connection.
Error Checking
We propose that each message carry a message number, bit count, and a checksum in its body, that is transparent to the IMP. For a checksum we suggest a 16-bit end-around-carry sum computed on 1152 bits and then circularly shifted right one bit. The right circular shift every 1152 bits is designed to catch errors in message reassembly by the IMPs.
Closer Interaction
The above described primitives suggest how a user can make simple use of a remote facility. They shed no light on how much more intricate use of the network is to be carried out. Specifically, we are concerned with the fact that as some sites a great deal of work has gone into making the computer highly responsive to a sophisticated console. Culler's consoles at UCSB and Englebart's at SRI are at least two examples. It is clear that delays of a half-second or so for trivial echo-like responses degrade the interaction to the point of making the sophistication of the console irrelevant. We believe that most console interaction can be divided into two parts, an essentially local, immediate and trivial part and a remote, more lengthy and significant part. As a simple example, consider a user at a console consisting of a keyboard and refreshing display screen. The program the user is talking typing into accumulates a string of characters until a carriage return is encountered and then it processes the string. While characters are being typed, it displays the characters on the screen. When a rubout character is typed, it deletes the previous non-rubout character. If the user types H E L L O <- <- P where <- is rubout and is carriage-return, he has made nine keystrokes. If each of these keystrokes causes a message to be sent which in return invokes instructions to our display station we will quickly become bored.
A better solution would be to have the front-end of the remote program -- that is the part scanning for <- and -- be resident in our computer. In that case, only one five character message would be sent, i.e., H E L P , and the screen would be managed locally.
We propose to implement this solution by creating a language for console control. This language, current named DEL, would be used by subsystem designers to specify what components are needed in a terminal and how the terminal is to respond to inputs from its keyboard, Lincoln Wand, etc. Then, as a part of the initial protocol, the remote HOST would send to the local HOST, the source language text of the program which controls the console. This program would have been by the subsystem designer in DEL, but will be compiled locally.
The specifications of DEL are under discussion. The following diagrams show the sequence of actions.






















 

Wróć do początku


Źródła, zasoby

Po uruchomieniu linku do strony Uniwersytetu w LAncaster otrzymuje się informację:
"Strona ta jest widoczna, ponieważ administrator serwera WWW zmienił jego konfigurację. Proszę skontaktować się z osobą odpowiedzialną za zarządzanie tym serwerem. Apache Software Foundation, producent oprogramowania serwerowego Apache, nie administruje tą witrynš i nie jest w stanie pomóc w sprawach związanych z jej konfiguracją".
Pozostałe pomocne strony nt. protokołu IPv6:
1. http://www.ipv6.org/
2. http://www.pl.ipv6tf.org/
3. http://www.ipv6forum.com/
4. http://playground.sun.com/ipv6/: tutaj jest też informacja o sieci 6bone
5. http://www.ipv6tf.org/: portal
6. http://www.ipv6.com/
7. http://www.faqs.org/: informacje o RFC. 8. http://di.com.pl/news/21043,1,0,Dzieki_IPv6_tyle_adresow_co_gwiazd_na_niebie.html

Ostatnia strona omawia w bardzo prosty sposób ideę wprowadzenia nowego protokołu.

Przykład artykułu z ostatnich dni nt. IPv6:
Komisja Europejska przymusi do IPv6 Autor: Piotr Waszczuk, IDG News Service 27 maja 2008 19:34
W opublikowanym dzisiaj komunikacie Komisja Europejska zachęca rządy poszczególnych krajów UE do rozpoczęcia działań mających na celu popularyzację wykorzystania adresów IPv6. Plany KE zakładają, że przed 2010 rokiem infrastruktura IT sektora publicznego państw członkowskich będzie oparta na nowej wersji protokołu IP. Przedstawiciele KE mają nadzieję, że za niecałe dwa lata na terenie za poœrednictwem protokołu IPv6 realizowana będzie przynajmniej czwarta częœć ruchu online. Według nich szybkie przeniesienie infrastruktury IT na młodszą odmianę protokołu IP może stworzyć przewagę konkurencyjną europejskich firm na arenie międzynarodowej. Z kolei zwlekanie z implementacją nowego standardu może, zdaniem władz UE, doprowadzić do poważnego kryzysu gospodarczego. "Przedsiębiorstwa i organizacje publiczne mogą skłaniać się ku próbom ponownego wykorzystania już przydzielonych adresów IPv4. Byłoby to jednak podejœcie krótkowzroczne i stawiałoby Europę w obliczu potencjalnego kryzysu spowodowanego wyczerpaniem się puli adresów IPv4" - czytamy w komunikacie KE. Na tle największych krajów świata dotychczasowe działania podejmowane przez państwa UE wypadajš raczej mizernie. Przykładowo cała sieć szkieletowa wykorzystywana przez japońskiego operatora telekomunikacyjnego NTT funkcjonuje w oparciu o IPv6. Z kolei chiński rząd planuje dostosowanie państwowej infrastruktury informatycznej do młodszego standardu IP na potrzeby najbliższych Igrzysk Olimpijskich. W przyszłym miesiącu upływa również termin przystosowania do IPv6 wszystkich sieci komputerowych wykorzystywanych w amerykańskiej administracji. Dotychczas KE zainwestowała ponad 90 mln euro w rozwój standardu i infrastruktury IPv6. Pierwsze działania podjęto jeszcze pięć lat temu. Niezależnie od tego w krajach Unii Europejskiej sieci stworzone w oparciu o protokół IPv6 należą głównie do instytucji naukowych i akademickich. "Jeżeli Europejczycy i europejskie firmy zechcą korzystać z najnowszych urządzeń internetowych, aktywnych metek w sklepach, fabrykach i na lotniskach oraz z nowoczesnych sieciach nawigacyjnych i inteligentnych systemów elektroniki użytkowej, to czeka nas znaczny wzrost popytu na adresy IP" - uważa Viviane Reding, unijna komisarz ds. społeczeństwa informacyjnego i mediów. Większoœć nowoczesnych komputerów, urzšdzeń elektrycznych i sprzętu sieciowego jest kompatybilna zarówno ze specyfikacjš protokołu IPv4, jak i jego młodszš odsłonš. Niektóre sieci mają przydzielone oba adresy, jednak dla większoœci terminali sš niedostępne za pośrednictwem IPv6. Pula IPv4 składa się z ok. 4,3 mld adresów. W chwili obecnej nieprzydzielonych pozostało ok. 700 mln (16%) z nich. Eksperci Organizacji Współpracy Gospodarczej i Rozwoju (OECD) prognozują, że przy obecnym wzroœcie zapotrzebowania na urządzenia sieciowe pula IPv4 wyczerpie się w 2011 roku.

Na koniec podaję bezcenną pozycję książkową wyd. Mikom z serii: Cisco System - R. Desmeules, IPv6: Sieci oparte na protokole w wersji 6.











>





 

Wróć do początku

Data ostatniej aktualizacji. Wykonano na podstawie szablonu