ARGOMENTO:

Salve,
questa immagine e' stata ogetto di disussione in un'aLtro contesto, discussione che copiero' ed incollero' per avere un vostro parere, nella immagine sopra e' rappresentato un tipico messaggio/pacchetto che a mio parere vede una trama ipv6 incapsulata in una ipv4, ed in gergo si dovrebbe dire IPV6 OVER IPV4 anche se tanta gente invece ritiene che sia pu' appropriato dire IPV4 OVER IPV6.
Quale e' il corretto modo di esprimersi?
Qui la conversazione:
io: PER TAGLIARE LA TESTA AL TORO USATE TEREDO PER CHI NON HA IPV6 DIRETTAMENTE ALLORA: IPV6 OVER IPV4
interlocutore: Robé, non mi posso dilungare adesso.. ma proprio con quello 'schema' non é piú corretto parlare di ipv4 over ipv6 ?? da quello che vedo la funzione di tunnelling (di trasporto.. di instradamento vero é proprio) la fa la sezione ipv6..
io:il payload finale (quello terminale) e' ipv6 quindi ipv6 e' veicolata (trasportata) dentro un tunnel ipv4, il payload ipv4 (che non e' esplicitamente indicato) e' costituito dai pacchetti ipv6.
Il problema viene dall'uso dei termini che anche io critico, difatti dire ipv6 over ipv4 in realta' significa che i pacchetti ipv6 sono contenuti nelle payload ipv4 quidi sarebbe corretto dire under e non over, ma sai come sono ste cose io ho imparato leggendo e mi sono accorto che l'uso di over e under e' inteso cosi e cosi lo ho assimilato.
Resta che nella figura il fatto che sia evidente che ipv6 payload sia lo scopo finale di tutta l'estensione delle pile protocollari indica che ipv6 e' trasportata e quindi ipv6 over ipv4 con over sgnificante come ho detto prima (under).
Insomma non solo bisogna capire le cose ma si deve anche parlare come al contrario, se no e' troppo facile .
il tunnel e' tra ipv4 source address (il calcolatore di partenza) e ipv4 destination address (calcolatore dove e' implementata la funzione di gateway ipv6 ed anche l'eventuale server dhcp ipv6), e questi indirizzi ipv4 restano fissi e cosituiscono il tunnel, i dati arrivati a desinazione ipv4 address vengono trattati (ripuliti di tutte le informazioni relative al tunnel ipv4 ed inviati al gateway ipv6 che immettera il pacchetto nella rete ipv6 dove il pacchetto ipv6 verra ruotato ed instradato fino ad ipv6 destination address.

vorrei precisare che dove ho scritto "questi indirizzi ipv4 restano fissi e cosituiscono il tunnel" avrei dovuto aggiungere, per meglio descrivere il portal che definisce il tunnel, anche le informazioni relative al protocollo UDP ed alle PORTE utilizzate alle due terminazioni del tunnel. Forse mi sfugge qualche altro aspetto? che dite voi?

Il trasporto di IPv6 su reti IPv4, come ad esempio all'interno di Tunnel Teredo (protocollo in questo caso applicativo, che riprende l'intero pacchetto IPv6 e lo reincapsula da capo come payload di una conversazione tra un client ed un server Teredo, in ascolto sulla porta UDP 3544), è da intendersi come "OVER". Stessa cosa per il 6in4 o per il 6to4 (sono differenti), che vedono l'IPv4 immediadamente seguito dall'IPv6 (IP protocol number 41).

Ad ogni modo, è assolutamente corretto dire IPv6 over IPv4, in quanto l'IPv6 appunto è "traghettato" attraverso una rete IPv4

Quando ho usato teredo ricordo che non ha avuto bisogno di effettuare nessuna configurazione quindi evidentemente e lui in maniera autonoma con un protocollo suo di "bootstrap" che cerca l'ip adeguato con il quale fare costruire il tunnel, oltre a cio' osservo che il protocol number 41 mi suscita qualche dubbio in quanto io ho rilevato per una generica trama IPV6 che il SAP E' 0X86DD=34525 ma il sap non e' trasmesso nella trama teredo in quanto e' un campo di LLC mentre solo la conferma della versione del protocollo IP e' indicata in figura ed e' 0110=6 ma serve solo come conferma perche detta informazione e' contenuta all'interno del pacchetto ipv6





e non (come il SAP) all'esterno in un campo specifico per teredo (se cosi fosse allora teredo potrebbe veicolare piu' di un protocollo di livello 3), a meno che analogamente all'interpretazine del campo lenght di LLC esso assuma significati differenti a seconda del valore ....... ma mi pare troppo difficile sia vero, e comunque io dell'IP protocol number 41 da te citato prima non vedo traccia e non capisco a cosa possa servire, cosa intendevi dire?
L'assunzione che il contenuto sia IPV& viene dal fatto che il tunnel usa come dici tu la porta 3544 che e' una WELL KNOW PORT ad uso ESCLUSIVO di teredo.
Cosa intendevi dire in questo contesto IP protocolnumber 41?

ho tentato ad inserire anche nelpost precedente una immagine .png di pochi kbyte come ho fatto altre volte ma non so come non la riesco a vedere.

Ciao Roberto,
quando parlavo di IP protocol 41 non mi riferivo al Teredo, ma solo al 6in4 e 6to4

Nel caso del Teredo infatti, seguirebbe IP protocol 17, ovvero UDP (come del resto mostrato in figura). Il campo IP protocol indica infatti ciò che segue (IPv6 nei primi due casi, UDP nel Teredo).

I png dovrebbero essere abilitati in upload, vedo di controllare appena posso

quindi il 41 si riferisce ad un contesto differente dal teredo che tu chiami 6to4, e dimmi Che contesto e'?
Ho qualche dubbio sul fatto che ho inteso (forse non ho capito oppure hai risposto in fretta) dal tuo ultimo post e cioe che la discriminante sia l'indicazione 17=UDP, mentre puoi verificare che la e' la porta 3544 sia UDP che anche TCP quella classificata come WELL KNOW PORT che indica a mio parere la qualita' del contenuto del payload del pacchetto IPV4 e che evidentemente la onnessione di tunnel puo' avvenire sia su udp che su tcp.

Ciao Roberto, non ho risposto in fretta. Il 6to4 è un'altra tecnica di trasporto IPv6 su IPv4 identificata dal relativo numero di protocollo (41) all'interno dell'header IP. L'ho nominata, assieme al 6in4 tanto per spiegare il concetto di "OVER" (ovvero se vogliamo "dentro").

Se invece vuoi capire meglio i dettagli dell'incapsulamento UDP (3544) del Teredo puoi dare un'occhiata qui

Per capirci meglio, dentro l'header IP:
protocol number 41 = Segue IPv6
protocol number 17 = Segue UDP

[Post modificato per aggiungere anche]
Dentro UDP invece
Port 3544 = Segue Teredo

PS Ripristinato l'upload dei png

leggo nel documento dell'ietf www.ietf.org/rfc/rfc4380.txt :
Teredo: Tunneling IPv6 over UDP
quindi se teredo usa solo UDP perche' anche la TCP 3544 e' associata a TEREDO?
il documento dice anche a giustificazione dell'uso di un tunnel UDP che:
Tunneling packets over TCP would be possible, but would result in a
poor quality of service; encapsulation over UDP is a better choice.
Al conrario di quanto leggo qui sopra scritto io ritengo che l'affidabiita' sia notoriamente maggiore in TCP oltretutto un eventuale fuori sequenza in ricezione dei pacchetti UDP deve comunque essere risolta dal teredo client o server e non piu' sul piano trasporto (TCP di ipv4) ma sul piano applicativo teredo mentre tilizzando porte TCP detta incombenza veniva risolta gratis e lasciava a teredo solo i suoi compiti che magari vedono anche la segmentazione ed il riassemblaggio di pacchetti ipv6 molto lunghi.
Fatto sta che esiste sta porta tcp well know 3544, mah

ho provato adesso il reinserimento dela figurama non funziona, bohh

Il tuo dubbio è più che lecito Roberto, così come le tue considerazioni.
Tuttavia, rispondendo in ordine:

roberto ulisse ha scritto: leggo nel documento dell'ietf www.ietf.org/rfc/rfc4380.txt :
Teredo: Tunneling IPv6 over UDP
quindi se teredo usa solo UDP perche' anche la TCP 3544 e' associata a TEREDO?

Sebbene Teredo utilizzi solo l'UDP, quando una porta viene associata ad un servizio viene praticamente associata ad entrambi i protocolli, indipendentemente dalla scelta dello sviluppatore del software di utilizzare il TCP o l'UDP.

roberto ulisse ha scritto: il documento dice anche a giustificazione dell'uso di un tunnel UDP che:
Tunneling packets over TCP would be possible, but would result in a poor quality of service; encapsulation over UDP is a better choice.

Qui la tua considerazione non tiene conto dell'incapsulamento "da capo". E' verissimo che nel caso si dovessero gestire pacchetti fuori sequenza l'UDP non funzionerebbe proprio, ma ciò non costituisce un problema poichè è stata gestita già "a monte": all'intero payload del Teredo c'è già un pacchetto IP, al cui interno è presente il protocollo di trasporto: non è dunque il Teredo a dover gestire la cosa a livello applicativo, ma a farlo sarà eventualmente il TCP chiamato in causa dall'applicazione originaria. Alla luce di questo, dovrebbe risultare chiara l'affermazione che hai citato dalla RFC. Sarebbe oltremodo sconveniente trattare in TCP un'applicazione che originariamente voleva una connessione UDP, e nel caso di doppio TCP si avrebbero tutta una serie di problemi legati alla gestione di una doppia window all'interno del TCP stesso come anche la gestione di doppi ACK (uno per il Teredo ed uno interno). Ho realizzato una figura che spero aiuti nella comprensione del tutto (mi ha richiesto un pò di tempo):



Come puoi vedere, se all'interno del pacchetto originario era stato previsto l'UDP, allora fila tutto liscio. Se invece era stato previsto il TCP, allora sarà proprio il TCP diciamo "interno" a gestire i segmenti fuori sequenza, o la loro ritrasmissione

[EDIT]
PS: Credo sia idoeno spostare la discussione nell'area " Indirizzamento IP " Appena avrai letto la sposto lì

Bene, e' tutto ancora piu' chiaro adesso, mi resta una riflessione: se un pacchetto ipv6 e piu'grande del massimo trasportabile in un'unico slot udp (ma esistono pacchetti ipv6 cosi grossi? se si allora continuo ) sara' necessaria in trasmissione che teredo prima di mandare nel tunnel segmenti il pacchetto stesso e srara' neessaria una analoga funzione di reassemblement in ricezione all'altro capo del tunnel, in questo caso un fuori sequenza tra pacchetti udp, e quindi non un errore, diventa un errore rilevato sull'eventuale tcp(6) e quindi avviene una ritrasmissione che viene recuperata grazie al tcp(6), se invece, come suggerivo io, il teredo implementasse da se almeno un meccanismo di sequenziamento dei pacchetti udp (e chissa non lo faccia) tutto funzionerebbe anche su un fuori sequenza.

reinserisco adesso una immagine che nei giorni scorsi ho inserito ma per qualche ragione non si vede

voglio meglio ancora precisare alcune cose importanti che ho scritto e cioe quando dico nel precedente post: " se un pacchetto ipv6 e piu'grande del massimo trasportabile in un'unico slot udp (ma esistono pacchetti ipv6 cosi grossi? se si allora continuo ) " vorrei dire meglio cosi: " se un pacchetto ipv6 e piu'grande del massimo trasportabile in un'unico slot udp oppure se esistono pacchetti ipv6 cosi piccoli (esisteranno certamente) da rendere conveniente inserirne due o piu' di due ed anche una frazione (quindi intendo un pacchetto e mezzo o due e mezzo ecc..) in un solo datagram udp in una situazione di questo tipo anche l'eventuale tcp(v6) non potra recuperare un fuori sequenza udp (4), ed in questo modo un fuori sequenza diventa errore irrecuperabile.
Domamnda (che faccio anche a me e mi riprometto di verificarlo in futuro) teredo frammenta pacchetti ipv6 oppure ne aggrega piu' di uno e frazioni, se si allora in caso di problemi di connessione dovuti a jitter potrebbe essere conveniente diminuire la velocita' di trasmissione dei datagram udp, teredo prende questa iniziativa in autonomia o no?
Qualcuno ha qualche opnione in proposito?
come posso creare una connessione a jitter controllato in modo da fre le verifiche del caso?