Aplicatii Ipv6 în Domeniul Automotive

UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE INGINERIE

DEPARTAMENTUL DE CALCULATOARE

PROIECT DE DIPLOMĂ

Conducător științific: Dr. ing. Remus Brad

Absolvent: Dragoș Valentin Ștefan

Specializarea: Calculatoare

– Sibiu, 2016 –

UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE INGINERIE

DEPARTAMENTUL DE CALCULATOARE

Aplicații IPv6 în Domeniul Automotive

Conducător științific: Dr. ing. Remus Brad

Absolvent: Dragoș Valentin Ștefan

Specializarea: Calculatoare

– Sibiu, 2016 –

Planul tematic

INTRODUCERE

Internet Protocol Version 6 este cea mai recentă versiune de protocol implementată. Nevoia acestui protocol este dată in principal de problemele pe care le are predecesorul lui IPv4. În acest context, principala problemă care apare în cazul IPv4 este epuizarea adreselor .

Epuizarea adreselor de IPv4 este o problemă esențială dedusă în anii 90, odată cu creșterea comercializării internetului. Astfel în 1998 Internet Engineering Task Force (IETF) începe lucrul la nou protocol pentru internet, bazat pe predecesorul lui ipv4, pentru a depașii limitările impuse de acesta.

Saltul de la ipv4 direct la ipv6 este dat de faptul că tipul protocolului este specificat undeva la începutul fiecărui mesaj. Până în anul 1998 cifra 5 fusese deja asignată unui protocol de internet stremaming.

Diferența majoră între cele două protocoale este dată de număarul de biți din care este formată adresa de IP. Pe când IPv4 are la dispoziție 32 de biți pentru formarea unei adrese de IP, IPv6 vine cu un spațiu de adrese pe 128 de biți ceea ce permite adresarea mai multor dispozitive.

Din nevoile oamenilor de interconectare si din motive de siguranța se pare că industria automotive prevede că în viitor oamenii vor dorii sa aibă acesta interconectivitate si în mașină. Acest lucru aduce două beneficii majore viitorilor posesori de astfel de mașini.

Un beneficiu este dat de cate confortul personal al utilizatorului, conectarea autoturismului la internet oferindu-i acestuia nenumărate avantaje.

Un alt beneficiu este dat de faptul că, autoturismul fiind conectat la internet acesta își poate trimite locația în timp real către un server specializat în coordonarea traficului fără accidente, ținând cont de pozițiile tuturor autovehiculelor din trafic.

Într-o altă ordine de idei autovehiculul care „se autoconduce” poate fi mai proape de prezent decât de viitor. Astfel de proiecte apar tot mai des, în zilele noastre, în special pentru vhicule de transport marfă.

Astfel se tinde către conectarea metotelor de transport privat și public la internet, acest lucru fiind momentan aproape imposibil ținând cont de numărul de vehicule și numărul de adrese de IP pe IPv4.

Prezentarea temei

Tema de licență are ca scop principal realizarea unei conexiuni între doua componente electronice cu scopul stabilirii unei comunicații între cele două dispozitive.

Prima componentă (Vector VN5610) este un dispozitiv care face posibile câteva „simulări” esențiale realizării proiectului, ca de exemplu:

Bus Simulation care asigură canale independente de Ethernet și CAN

Media Converter care stabilește legături de date între BroadR-Reach și nivelul fizic pe standardul IEEE802.3

Ethernet Monitoring care asigură monitorizarea bus-urilor.

Acestă componentă poate fi controlată cu ajutorul mai multor aplicații, una dintre cele mai importante și cea care se va folosii in acest proiect este CANoe, aplicație dozvoltata deasemni de Vector. CANoe are capacitatea trimiterea oricărui tip de mesaj prin compunerea acestora bit cu bit sau cadru cu cadru a mesajului dorit.

Cea de-a doua componentă va fi un ECU (Electronic Control Unit) care integrează IPv6.

Nevoia de ECU-uri care suportă IPv6 duce la nevoia testării acestor dispozitive, fapt care duce la crearea unei aplicații al cărei scop este stabilirea conexiunii între acestea și ulterior testarea funcționalitațiilor, capabilitațiilor și toleranței la defectări a acestor dispozitive.

Acest proiect este realizat din dorința/nevoia industriei automotive de a face trecerea către asemenea dispozitive de control (IPv6), cu alte cuvinte aceste dispozitive încă nu există, dar acest lucru se datorează și faptului că astfel de dispozitive necesită o testare deosebit de riguroasă, acestea controlând funcții vitale ale autovehiculelor.

Acest proiect realizează conexiunea dintre viitoarele ECU-uri atribuindu-le acestora o adresă de IP prin care să poată fi accesate de către instrumentul de testare (Vector VN5610 și Vector CANoe) realizând astfel un mic pas către implementarea și utilizarea acestor dispozitive în industria automotive.

Aplicația de proiect are capacitatea de a aloca adrese de IPv6 prin Stateless Address Autoconfiguration (SLAAC) și de a testa stabilitatea conexiunii cu ajutorul unui protocol numit Internet Control Message Protocol (ICMPv6). Pentru ca ascet lucru să fie posibil apicația are nevoie de un algoritm care să trimită/raspundă la diferite mesaje către/de la dispozitiv.

Obiective principale

Obiectivul primar proiectului este reprezentat de simularea comportamentului unui router IPv6, în vederea conectării unor ECU-uri pentru testarea ulterioară acestor dispozitive.

Principalele obiective în implementarea proiectului sunt date de către

următoarele:

Configurarea aplicației în care se va dezvolta proiectul

Implementarea unui algoritm care să trimită diferite tipuri de mesaje către dispozitivul conectat la rețea

Crearea de funcții care compună mesaje specifice IPv6

Salvarea datelor importante pentru refolosirea ulterioară a acestora

Folosirea unui client pentru verificarea funcționalității proiectului

Posibibilitatea folosirii adreselor IPv6 alocate

Implementarea unui mecanism de verificare a conexiunii (ICMP)

Posibilitatea schimbării prefix-urilor folosite pentru alocarea adreselor de IPv6

Motivația alegerii temei

Ideea proiectului de licență vine în principal de la tendința actuală de tranziție de la IPv4 către Ipv6 și cerșterea continuă a automatizării autovehiculelor .

Motivul alegerii acestei teme se datorează dorinței de progres tehnologic și fascinației față de automobile cât și posibilității ca prin acest proiect să se realizeze un pas mic, dar esențial în dezvoltarea de automobile autonome. Proiectul poate duce la dezvoltarea unor dispozitive de control mai rapide, astfel, îmbunatațind vitezele de comunicație se pot dezvolta dispozitive mai avansate care să poată gestiona cu ușurință sistemele existente într-un autovehicul.

Un al motiv este și întelegerea protocoalelor ce urmează să fie lansate în viitorul apropiat.

CONSIDERAȚII TEORETICE

În această parte, secțiunea teoretică a licenței, voi descrie elementele care au luat parte la realizarea aplicației. Acestea elemente sunt in mare parte componentele funcționale ale protocolului de internet versiunea 6. IPv6 este un protocol de nivel TCP/IP din modelul OSI.

Adresele IPv6

O adresă IPv6 are 128 de biți, reprezentați ca 8 grupuri de 4 cifre hexazecimale separate prin două puncte (:)

128 biți sunt reprezentați ca 8 câmpuri în sistemul hexazecimal:

2031:0000:130F:0000:0000:09C0:876A:130B

Ca o abreviere, câmpurile egale cu 0 pot fi reprezentate printr-o singură cifră în loc de 4:

2031:0:130F:0:0:9C0:876A:130B

De asemenea, domeniile succesive de 0 pot fi reprezentate ca două separatoare de câmp consecutive:

2031:0:130F::9C0:876A:130B

Numărul total de adrese = 1015 = 340.282.366.920.938.463.463.374.607.431.768.211.456

[1]

Modelul OSI

Modelul de Referință OSI ( Open Systems Interconnection) este o stiva de protocoale  de comunicație  foarte des folosite pentru a realiza o rețea de calculatoare. OSI este un standard al Organizației internaționale de standardizare, emis în 1984.

Modelul de Referință OSI oferă metode generale pentru realizarea comunicației,  sistemelor de calcul pentru ca acestea să poată schimba informații, indiferent de particularitățile constructive ale sistemelor (fabricant, sistem de operare, țară, etc). Modelul de Referință are aplicații în toate domeniile comunicațiilor de date, nu doar în cazul rețelelor de calculatoare.

Modelul OSI divizează problema complexă a comunicării între două sau mai multe sisteme în 7 straturi numite și niveluri (layers) distincte, într-o arhitectură ierarhică. Fiecare strat (nivel) are funcții bine determinate și comunică doar cu straturile adiacente. Cele 7 niveluri ale Modelului de Referință se numesc: Aplicație (nivelul 7, superior) , Prezentare, Sesiune, Transport, Rețea, Legătură de date, Fizic (nivelul 1, inferior). [2]

Figura 1.

Nivelul Fizic

Nivelul fizic definește specificații electrice, mecanice, procedurale și functionale pentru activarea, menținerea și dezactivarea legăturilor fizice între sisteme.

Nivelul fizic are rolul de a transmite un șir de biți pe un canal de comunicații.

Se precizează modulații, codări, sincronizări la nivel de bit. Un standard de nivel fizic definește 4 tipuri de caracteristici:

Mecanice (forma și dimensiunile conectorilor, numărul de pini)

Electrice (modulația, debite binare, codări, lungimi maxime ale canalelor de comunicație)

Funcționale (funcția fiecărui pin)

Procedurale (succesiunea procedurilor pentru activarea unui serviciu)

Unitatea de date: bitul [2]

2.2. Nivelul Legătură de Date

Nivelul legatură de date se ocupă cu adresarea fizica, topologia rețelei, accesul la rețea, detecția și anunțarea erorilor și controlul fluxului fizic (flow control).

Nivelul legatură de date are rolul de a furniza un transport sigur, fiabil, al datelor de-a lungul unei legături fizice, realizând:

Controlul erorilor de comunicație

Controlul fluxului de date

Controlul legăturii

Sincronizarea la nivel de cadru

Unitatea de date: cadrul [2]

Nivelul Rețea

Nivelu de rețea are rolul de a determinarea căi optime pentru realizarea transferului de informații într-o rețea constituită din mai multe segmente, prin fragmentarea și reasamblarea  informației.
Unitatea de date: pachetul [2]

Nivelul Transport

Nivelul de trasport are rolul transferului fiabil al informației între două sisteme terminale (end points) ale unei comunicații. Furnizează controlul erorilor și controlul fluxului de date între două puncte terminale, asigurând ordinea corectă a pachetelor de date. Oferă un serviciu de transport de date care izolează nivelurile superioare de orice specificitații legate de modul în care este executat transportul datelor.

Unitatea de date: segmentul, datagrama [2]

2.2.1. Cadrul Ethernet

Cadrul Ethernet este un pahet de date la nivelui legaturii de date din modelul OSI compus din adresele de MAC ale sursei și destinației și tipul cadrului următor. Pe langă datele prezentate anterior, acesta mai conține și un preamblu de 7 biți care ajută la sincronizarea conexiunii împreună cu 1 bit de start al mesajului propriuzis, numit SFD. Cu toate astea, preamblul și bitul de sfd țin mai mult de nivelul fizic deoarece sincronizează/pregatesc legătura de date pentru traficul care urmeză. Cadrul se poate observa în figura următoare.

Figura 2 – Ethernet frame

Câmpurile din cadrul Ethernet:

Destination MAC Adresă MAC destinație (poate fi multicast), 6 octeți

Source MAC Adresa de MAC a sursei/expeditorului, 6 octeți

Type Specifică tipul mesajului următor (0x86DDh -> IPv6), 4 octeți

2.3.1. Cadrul IPv6

Un pachet IPv6 este unul dintre cele mai mici mesaje care se trimite prin Internet Protocol. Pachetul este format din header și payload. Headerul este partea fixă a mesajului în care se specifică informatii pentru adresarea routerului cât si dimensiunea payload. Headerul IPv6 are următoarea strucură:

Figura 3 – Ipv6 Frame.

Câmpurile din cadrul IPv6:

Version Acest câmp trebuie să conțină valoarea 6 (0110 în binar)

Traffic Class Biții acestui câmp conțin două valori; primii 6 biți folosiți pentru diferențierea serviciilor și ceilalți doi pentru ECN (decongestionarea traficului)

Flow Label Câmp care specifică numărul curent al pachetului

Payload Length Câmpul specifică dimensiunea „încărcăturii” în octeți

Next Header Specifică tipul cadrului conținut în payload

Hop Limit Acest câmp specifică numărul maxim de routere prin care poate să trecă mesajul până a ajunge la destinație

Source Address Specifică adresa de IP a expeditorului

Destination Address Specifică adresa de IP a destinatarului

2.4.1. Neighbour Discovery Protocol

Nodurile (host-uri, routere) se folosesc de acest protocol pentru a determina adresele de link-layer ale vecinilor si pentru a scoate adresele devenite invalide din memoria cache a dispozitivului (nodului). In același timp host-urile folosesc acest protocol pentru a găsii routerele invecinate care doresc a trimite mai departe pachetele (mesajele). In cele din urmă, nodurile folosesc protocolul pentru a putea determina care dintre vecini sunt disponibili sau nu, si pentru a detecta eventualele schimbări ale adreselor. Atunci când un router, sau o rută către un router cedeaza, host-ul trebuie să caute după rutealternative.

Tipuri de Link-uri

Orice tip de Link are proprietăți diferite. Cele mai importante pentru acest protocol sunt următoarele:

Link capabil de multicast

Este un mecanism de trimitere a pachetelor către toți, respectiv către un grup de vecini.

Link punct la punct

Este o legatură intre exact 2 vecini, însă se asumă că acestia sa aibă capabilitatea de multicast.

Link Non-Broadcast Multi-Access

Shared Media

Variable MTU

Asymetric reachability [3]

Tipuri de Adrese

Neighbor Discovery se folosește de adrese diferite inclusiv:

Adresele multicast ale tuturor nodurilor (Node Multicast)

Adresele multicast ale tuturor routerelor (Router Multicast)

Adresele multicast ale nodurilor solicitate (Solicited Multicast)

Adresele locale de link (Link-Local)

Adresele nespecificate (Unspecified) [3]

Protocol Overview

Acest protocol rezolvă un set de probleme ce pot apărea in urma interacționării între nodurii atașate la aceeași legatură. Acesta definește mecanismul de rezolvare a fiecăreia dintre problemele următoare:

Router Discovery

Prefix discovery

Parameter Discovery

Address Autoconfiguration

Address Resolution

Next-Hop determination

Neighbour Unreachability Detection

Duplicate Address Detection

Redirect

Router Solicitation

Router Advertisement

Neighbor Solicitation

Neighbor Advertisement

Link-Layer Address Change

Inbound Load Balancing

Anycast Addresses

Proxy Advertisements [3]

Formatul mesajelor

Această secțiune ne arată formatele mesajelor folosite din punctul de vedere al NDP.

Formatul Mesajului de Solicitare a Router-ului

Host-ul generează mesaje pentru a solicita router-ului generarea cât mai rapida a unui mesaj de Router Advertisement.

Structura meajului :

Figura 4 – Router Solicitation Frame.

Câmpurile din cadrul ICMP:

Type 133

Code 0

Checksum ICMP Checksum

Reserved Câmp nefolosit, rezervat pentru dezvoltări viitoare

Opțiuni Valide:

Adresa de link-layer a sursei.

Formatul Mesajului de Advertisement a Router-ului

Routerele generează mesaje de advertisement (reclamare, notificare, avertizare) la o anumita perioadă de timp, cât și ca răspuns la mesaje de Solicitare a Router-ului.

Figura 5 – Router Advettisement Frame.

Câmpurile din cadrul ICMP:

Type 134

Code 0

Checksum ICMP Checksum

Cur Hop Limit Număr intreg pe 8 biți care specifică vecinilor numărul implicit din câmpul Hop Count in cadrul de IP.

M Flag pe 1 bit “Managed Address Configuration”, odată setat, acesta indică că adresele sunt disponibile prin DHCPv6 și, forteaza ca bitul de O este redundant.

O Flag pe 1 bit “Other Configuration” care semnifică faptul că alte tipuri de informații sunt disponibile prin DHCPv6, ca de exemplu informații referitoare la DNS.

Dacă nici unul dintre cei doi biți nu este setat inseamnă ca nu există informații de la DHCPv6.

Reserved Câmp nefolosit, rezervat pentru dezvoltări viitoare, in acest caz câmpul are o dimensiune de 6 biți, ceilalți doi fiind folosiți pentru flagulrile “M”și”O”.

Router Lifetime Câmp de 16 biți folosit pentru specificarea duratei de viață a router-ului în secunde cu un maxim de 65535. Dacă valoarea este 0, atunci router-ul nu trebuie sa apară în lista de Default Router.

Reachable Timer Câmp de 32 de biți măsurat in milisecunde care specifică durata în care acesta poate fi contactat, numarătoarea inversă începand după ultima confirmare de disponibilitate. Valoarea 0 semnifică faptul că acest detaliu este nespecificat.

Retrans Timer Câmp de 32 de biți măsurat in milisecunde care reprezintă timpul între trimiteri succesive de mesaje de Neighbour Solicitation, folosite de către algoritmul de Neighbour Unreachability Detection.

Opțiuni Valide:

Adresa de link-layer a sursei.

MTU (Maximal Transmission Unit)

Informații de Prefix. [3]

Formatul Mesajului de Solicitare a Vecinuluiului

Nodurile trimit mesaje de solicitare a vecinilor pentru a cere adresa de legătură a nodurilor țintă cât si pentru a trimite adresa proprie de legătură vecinilor. Mesajul de advertisement al vecinilor este multicast atunci când nodul trebuie să rezolve o adresă, si unicast atunci când nodul vrea să verifice disponibilitatea unui vecin.

Figura 6 – Neighbour Solicitation Frame.

Câmpurile din cadrul ICMP:

Type 135

Code 0

Checksum ICMP Checksum

Reserved Câmp nefolosit, rezervat pentru dezvoltări viitoare

Target Address Câmpul conține adresa de IP a destinatarului

Opțiuni Valide:

Adresa de link-layer a sursei. [3]

Formatul Mesajului de Advertisement a Vecinuluiului

Un nod trimite mesaje de advertising in răspuns la solicitarea unui vecin, dar si pentru a propaga noi informații rapid.

Câmpurile din cadrul ICMP: Figura 7 – Neighbour Advertisement Frame.

Type 134

Code 0

Checksum ICMP Checksum

R Flag pe 1 bit “Router”, odată setat, acesta indică faptul că expeditorul este un router.

S Flag pe 1 bit “Solicited” care semnifică faptul că acest mesaj este trimis ca răspuns la un mesaj de Neighbour Solicitation folosit de către algoritmul de Neighbour Unreachability Detection.

O Flag pe 1 bit “Override” care semnifică nevoia de înlocuire a unor adrese salvate in cache-urile destinatarului.

Reserved Câmp nefolosit, rezervat pentru dezvoltări viitoare, in acest caz câmpul are o dimensiune de 29 biți, ceilalți trei fiind folosiți pentru flagulrile “R”,”S”și”O”.

Target Address Câmpul conține adresa de IP a destinatarului. În cazul în care acest mesaj a fost solicitat se copiază adresa din câmpul de Target Address din cadrul ICMP al mesajului de solicitare a vecinului. Adresa nu poate fi una multicast.

Opțiuni Valide: Adresa de link-layer a destinației. [3]

Formatul Mesajului de Redirecționare

Routerele trimit pachete de Redirecționare pentru a informa un host despre un nod mai bun de prim salt (First HOP) in drumul către destinație. Host-urile pot fi redirecționate către un router de prim salt mai bun si pot fi informate si că destinația este de fapt un vecin. Putem raliza aceasta dacă setăm Adresa de Target la fel cu cea de Destinatie.

Câmpurile din cadrul ICMP: Figura 8 – Redirect Frame.

Type 137

Code 0

Checksum ICMP Checksum

Reserved Câmp nefolosit, rezervat pentru dezvoltări viitoare

Target Address Câmpul conține adresa de IP a următorului salt. În cazul în care adresa din câmpul Destination Address, cadrul ICMP, este aceeași cu aceasta, înseamnă că pachetul a ajuns la destinație. În caz contrar acest câmp trebuie sa conțina adresa link-locala a celui mai apropiat router de prim salt.

Destination Address Câmpul conține adresa de IP a destinației finale.

Opțiuni Valide:

Adresa de link-layer a sursei.

Redirected Header [3]

Formatul Opțiunilor mesajelor

Formatul mesajelor din protocolul ND include 0 sau mai multe opțiuni, unele dintre ele, care pot apărea de mai multe ori in aceelasi mesaj. Opțiunile ar trebuii să fie „shiftate” atunci când e nevoie pentru a păstra o forma de 64 de biti.

Figura 9 – Option Frame.

Câmpuri:

Type Identificator pe 8 biți pentru tipul opțiunii

Source Link-Layer Address

Target Link-Layer Address

Prefix Information

Redirected Header

MTU

Length lungimea câmpului de opțiuni în unitați de 8 octeți [3]

Formatul Adreselor de Link-Layer a mesajelor

Câmpuri: Figura 10 – Link Layer Option Frame.

Type 1 pentru adtresa link-locală a sursei

pentru adresa link-locală a destinației

Length lungimea câmpului de opțiuni în unitați de 8 octeți (1)

Link-Layer Address adresa link-locală a sursei/destinației [3]

Formatul mesajelor de Informații a Prefixului

Figura 11 – Prefix Option Frame.

Câmpuri:

Type 3

Length lungimea câmpului de opțiuni în unitați de 8 octeți (4)

Prefix Length câmp pe 8 biți pentru valori întregi nesemnate (0-128) care specifică lungimea prefix-ului

L flag pe 1 bit care specifică dacă prefix-ul poate fi folosit pentru determinare on-link/off-link

A flag pe 1 bit care specifică daca prefix-ul poate fi folosit sau nu pentru Stateless Address Autoconfiguration (SLAAC)

Reserved1 Câmp nefolosit de 6 biți, rezervat pentru dezvoltări viitoare

Valid Lifetime Acest câmp specifică durata de valabilitate în secunde a prefix-ului

Preferred Lifetime Câmpul specifică durata „sigură” în secunde a prefixului

Reserved1 Câmp nefolosit, rezervat pentru dezvoltări viitoare

Prefix Prefix-ul ce va fi atașat adresei [3]

Formatul mesajelor de MTU

Figura 12 – MTU Option Frame.

Câmpuri:

Type 5

Length 1 (octeți)

Reserved Câmp nefolosit, rezervat pentru dezvoltări viitoare

IP Header+Data Câmp pe 32 de biți nesemnat, folosit pentru descrierea maximului de unitați de transmisie (Maximal Transmission Unit)

Formatul mesajelor de Header Redirecționat

Figura 13 – Redirect Option Frame.

Câmpuri:

Type 4

Length lungimea câmpului de opțiuni în unitați de 8 octeți

Reserved Câmp nefolosit, rezervat pentru dezvoltări viitoare

IP Header+Data Pachetul original, înainte de redirecționare [3]

Modelul Conceptual al Structurilor de Date

Gazda(host) va trebuii să mențină următoarele informații pentru fiecare interfată:

Neighbour cache

Destination cache

Prefix List

Default Router List

Neighbour cache reprezintă un set de intrări despre vecini individuali pentru care s-au trimis date recent. Aceste intrări sunt legate de de link-ul unicast al adresei de IP si conțin informații ca adresa de link-layer, un flag care indică dacă vecinul este router sau host (IsRouter), un pointer pentru pachetele de date care asteptă ca address rezolution(::) să completeze datele, etc. O intrare de neighbour cache contine deasemeni informații despre algoritmul de detecție a vecinilor indisponibili incluzând și starea de disponibilitate, numărul de probe nerăspunse, si timpul până când următorul eveniment de „Unreachability Detection” va avea loc.

Destination Cache reprezintă un set de intrări despre destinațiile la care s-a trimis recent. Cache-ul de Destinație conține atât destinațiile on-link cât si pe cele off-link. Aceasta este actualizată cu informații primite de la mesajele de Redirecționare.

Prefix List reprezintă o listă de prefixe care definesc un set de adrese on-link. Intrările in lista de prefixe sunt create din informații primite de la mesajele de Router Advertisement. Fiecărei intrări îi este asociat un timp de invalidare folosit pentru a invalida prefixele ce au depășit o anumită perioadă de timp. Există totuși si timer special a cărui valoare este infinita, ceea ce face ca prefixul să nu expire până când se primește o altă valoare a acestuia de la un mesaj de Advertisement subsecvent. Prefixul Link-Local este considerat a fi o listă de prefixe fără timp de expirare chiar dacă routerele spun altceva. Mesajele de Router Advertisement primite nu trebuie să modifice timpul de invalidare pentru prefixul Link-Local.

Default Router List este o listă de routere către care pachetele se pot trimite. Intrările din lista de routere pointează către intrările in Neighbour cache; algoritmul de selectare a routerului alege un router cunoscut ca fiind disponibil in favoarea unuia care este suspectat a fi indisponibil. Fiecare intrare are deasemenea un timp de invalidare extras din mesajle primite de Router Advertisement folosit pentru a șterge intrările expirate. [3]

Algoritmul de Trimitere

La trimiterea unui pachet către o destinație, un nod se foloseste de Cache-ul de Destinatie, Lista de Prefix si Lista de Router pentru a determina adresa de IP corespunzătoare pentru următorul salt, operație cunoscută sub numele de „Next Hop Determination”. Odata cunoscută adresa de IP a următorului salt este consultat Neighbour Cache in vederea selectării adresei de MAC.

Următorul salt pentru o destinație unicast este determinat prin selectarea celui mai asemănător pefix, din Lista de Prefix, cu cel al destinației.

Din motive de eficiență determinarea următorului salt nu se face la trimiterea fiecărui pachet. Rezultatele algoritmului de determinare a următorului salt sunt salvate in Cache-ul de Destinație impreună cu informațiile din mesajele de redirecționare. Când un nod dorește să trimită un pachet, mai întâi verifică Cache-ul de destinație in vederea stabilirii rutei. Dacă nu există nici o informație referitoare la destinația dorită se execută protoculul „Next Hop Determination”.

Imediat după aflarea adresei următorului salt se verifică „Neighbour Cache” in vederea aflării adresei de MAC (link-layer) a destinației. Dacă nu există informații in tabela se execută protocolul de „Address Resolution” pentru aflarea informațiilor necesare. Pentru interfețele compatibile multicast protocolul de „Address Resolution ” constă in trimiterea unui mesaj de „Neighbour Solicitation” la care se așteaptă un răspuns prin „Neighbour Advertisement”. La primirea mesajului de Neighbour Advertisement se introduc adresele de link-layer in tabela de Neighbour Cache.

De fiecare dată când se accesează tabela de Neighbour cache in timpul compunerii unui pachet unicast, sursa verifică informațiile date de algoritmul de Neighbour Unreachability Detection pentru a determina dacă destinația pachetului este incă disponibilă.

Algoritmul de detecție a următorului salt se execută doar la trimiterea primului pachet către o destinație. Atata timp cât comunicația subsecventă se execută cu succes, pe baza informațiilor determinate la trimiterea primului pachet, aceste informații sunt folosite in continuare până când algoritmul de „Neighbour Unreachability Detection” spune altfel. Astfel in cazul in care un vecin nu mai este disponibil in timpul transimisiei pachetelor, pachetele rămase se pot trimite pe altă rută.

Când un nod redetermină adresa următorului salt, acesta trebuie să șteargă informațiile curente despre salt din tabela de Destination Cache.

Pentru dispozitive cu mai multe interfețe fizice, in cazul primirii de date, acestea trebuie să răpundă pe aceeași interfață fizică. [3]

Ștergerea Datelor Nerelevante

Ștergerea datelor nerelevante se referă în general la procesul numit „Garbage Collector” care se aplică de cele mai multe ori la informațiile învechite/degrevate.

Pentru a limita spațiul necesar tabelelor de destinație și vecini, un nod trebuie să șteargă intrările vechi/nefolosite.Trebuie astfel avut grijă ca aceste tabele să asigure spațiul necesar pentru setul de intrări active(folosite in comunicație). Cache-uri de dimensiune mică pot duce la un număr mare de mesaje de Neighbour Discovery atunci când se trimit date către mai multe destinații. O politica Least Recently Used ar putea gestiona cu ușurința aceste date.

Un nod trebuie sa țina informațiile unei intrări în tabele nu mai mult decât durata de viață a acestor informații extrasă din mesajele specifice NDP. Atunci când tablele sunt aproape pline, un nod trebuie să apeleze acest mecanism in vederea eliberării spațiului pentru eventualele conexiuni noi.

La ștergerea unei intrări din tabela de prefix nu este necesară ștergerea intrărilor corespunzătoare din tabela de destinație și tabela de vecini. De acestea se va ocupa algoritmul de Neighbour Unreachability Detection. La ștergerea unei intrări din tabela de Default Router orice intrare care trece prin routerul respectiv din tabela de destinație trebuie actualizată cu ajutorul algoritmului de Next Hop Determination pentru selectarea unui nou router implicit. [3]

Determinarea de Router si Prefix

Aceasta secțiune descrie comportamentul unui Router referitor la protocolul Neighbour Discovery. Acesta se folosește pentru determinarea routerelor apropiate/vecine cât si pentru atribuirea prefixelor si informațiilor referitoare la parametrii de configurație in contextul autoconfigurării adreselor prin metoda stateless (Stateless Address Autoconfiguration).

Prefix Discovery este procesul prin care toate nodurile care nu sunt Routere află raza de adrese de IP care pot fi contactate fară ca traficul sa treacă printr-un router. Routerele trimit mesaje de Router Advertisement in care specifică dacă doresc sau nu să devină router implicit, cât si informații de prefix care ajută la identificarea vecinilor care sunt legați la aceeași rețea fizică.

Stateless Address Autoconfiguration trebuie să obțină de asemenea informații despre prefix-ul subnet-ului, ca parte a configurării adreselor. Același prefix poate fi folosit pentru autoconfigurarea mai multor adrese dintr-o rețea prin setarea flag-urilor corespunzătoare în cadrul opțiunii de Prefix Information. [3]

Validarea Mesajelor

Validarea Mesajelor de Router Solicitation

Un Host tebuie să omită orice mesaj de Router Solicitation primit care nu satisface oricare din condițiile de validitate de mai jos:

Câmpul IP Hop Limit trebuie să aibă valoarea de 255, deoarece acesta nu putea fi retrimis de către un router.

Câmpul Checksum al cadrului ICMP este valid

Câmpul Code al cadrului ICMP are valoarea 0

Lungimea cadrului de ICMP, derivată din cadrul de IP, este mai mare sau egala cu 8 octeți

Atunci când câmpul sursă din cadrul de IP este adresa nespecificată (0:0:0:0:0:0:0:0), mesajul nu trebuie să conțina cadrul de „source link-layer address option” [3]

Validarea Mesajelor de Router Advertisemnent

Un Nod tebuie să omită orice mesaj de Router Solicitation primit care nu satisface oricare din condițiile de validitate de mai jos:

Câmpul Sursă din cadrul de IP este adresa Link-Locală.

Câmpul IP Hop Limit trebuie să aibă valoarea de 255, deoarece acesta nu putea fi retrimis de către un router.

Câmpul Checksum al cadrului ICMP este valid

Câmpul Code al cadrului ICMP are valoarea 0

Lungimea cadrului de ICMP, derivată din cadrul de IP, este mai mare sau egala cu 8 octeți

Toate cadrele de opțiuni trebuie sa aibă o lungime mai mare ca 0. [3]

Variabile de configurare a Routerului

Un Router trebuie să permită următoarelor variabile să poată fi configurate. Aceste variabile au un nume demontrativ, si nu este absolut necesară implementarea acestora. Valorile impicite sunt specificate pentru simplificarea configurării. Aceste variabile pot fi rescrise/modificate de alte documente ulteriore cu scopul de a aduce imbunătățiri protocolului.

Fiecare interfată conține:

IsRouter

Un flag care indică oridecâte ori un router este activ pe o interfată. Activarea acestui flag indică capacitatea routerului de a redirecționa pachetele către/de la interfață.

Implicit: FALSE

AdvSendAdvertisements

Un flag care indică oridecâte ori un router trimite mesaje periodice de Router Advertisement si răspunde la Router Solicitation.

Implicit: FALSE

MaxRtrAdvInterval

Timpul maxim admis între trimiteri repetate de Router Advertisement, cu destinație multicast, in secunde. Acesta nu poate fi mai mic de 4 secunde si nu mai mare de 1800 secunde.

Implicit : 600 secunde

MinRtrAdvInterval

Timpul minim admis intre trimiteri repetate de Router Advertisement, cu destinatie multicast, in secunde. Acesta nu poate fi mai mare de 3 secunde si nu mai mic de 0.75 secunde.

Implicit:

1: 0.33 * (MaxRtrAdvInterval Numai dacă acesta este mai mare sau egal cu 9 secunde)

2: MaxRtrAdvInterval

Stateless Address Autoconfiguration conține informații aditionale asociate fiecărui prefix.

AdvPreferredLifetime

Acesta specifică durata de viața a prefix-ului in secunde. O valoare de 0xffffffff specifică o durată de viață infinită; Se poate implementa in doua feluri:

-un timp care se decrementează in timp real, care cândva in viitor va ajunge la 0;

-un timp fix care rămane același in toate mesajele de advertisement.

Implicit: 604800s(7 zile) [3]

STRUCTURA ȘI PROIECTAREA APLICAȚIEI

Deși tema de proiect se referă doar la o aplicație care se pretează la simulare comportamentului unui router, inevitabil vom avea și o parte hardware pentru care aplicația a fost creată; Astfel structura proiectului se împarte în mai multe categorii:

Componentele Hardware

Aplicația în care se va implementa algoritmul proiectului (CANoe)

Aplicatia de Proiect

Din acest motiv, acest capitol va fi împărțit în trei subcapitole poe care le voi explica in detaliu.

Componentele Hardware

Acest subcapitol este dedicat componentelor hardware de care este nevoie pentru a pune în aplicare acest proiect. Printre acestea se numără:

Cablu UTP

Cablu USB

Vector VN5610

ECU compatibil IPv6

PC/Laptop

IMPLEMENTAREA APLICAȚIEI

CONCLUZII

BIBLIOGRAFIE

Links:

[1] https://ro.wikipedia.org/wiki/Modelul_OSI

[2] https://ro.wikipedia.org/wiki/IPv6

[3] https://tools.ietf.org/html/rfc4861

Books: