Newsgroup: it.comp.reti.ip-admin
Titolo: Chi frammenta, chi ricostruisce TCP o IP?

Sto studiando questi protocolli da Tanenbaum - Reti di Computer.
Mi si dice che i router possono frammentare i pacchetti IP di
dimensione maggiore a quella massima prevista dalla rete e a tal fine
sono previsti nel preambolo IP dei campi come Fragment offset. Il
livello rete del ricevente provvede poi a riassemblare il pacchetto
originario e a fornirlo al livello trasporto.
Fin qui tutto bene, solo un dubbio: anche se si perde un frammento va
ritrasmesso l'intero pacchetto IP originario, no?
Al momento di parlare del protocollo TCP è scritto che un router, nel
caso indicato sopra, al momento della frammentazione crea nuovi
preamboli IP  e *nuovi preamboli TCP*. Ma un router (livello 3) non
dovrebbe essere all'oscuro di  TCP (livello 4)? E' chiaro che volendo
può ricostruire il preambolo aggiornando in base alla frammentazione
il numero di sequenza e ricopiando tutti gli altri campi, ma non si
tratta di una cosa *sporca*?
Se le cose stanno effettivamente così , non sarà che il livello rete
del ricevente si limita ad inoltrare il contenuto dei nuovi frammenti
IP  al livello trasporto (visto che ciascuno ha la struttura di un
pacchetto TCP) lasciandogli il compito della ricostruzione? In tal
caso il campo fragment offset servirebbe semplicemente a creare da un
unico pacchetto IP pacchetti IP con differente numerazione. Il livello
trasporto del mittente dovrebbe inoltre essere in grado di  rinviare
pezzi arbitrariamente collocati all'interno dei pacchetti TCP.
Ringrazio fin da adesso quanti risponderanno.
   Ciao,
      Giovanni. 
Giovanni Neglia
gne...@ZZZtiscalinet.it
per rispondere rimuovere ZZZ dall'indirizzo


In effetti il compito di frammentazione e ricomposizione dei dati, con
relativa verifica ed eventuale correzione (ritrasmissione) è affidato al
TCP, non ad IP che si occupa semplicemente dell'indirizzamento dei pacchetti
verso la giusta destinazione.
La tua analisi è quindi corretta, tranne per il fatto che se un pacchetto
TCP viene spezzato in più datagram IP (per motivi di MTU) ed uno di questi
viene perso, IP scarterà l'intero pacchetto che non è riuscito a completare
e TCP, non avendolo mai ricevuto, ne richiederà la ritrasmissione (con tutti
i suoi frammenti).
Ciao,
          Massimo.

 verso la giusta destinazione.
Mi permetto di contraddirti (pardon :) )
L'IP si occupa anche di gestire la frammentazione dei pacchetti. Allego una
parte del RFC 791 che riguarda questo fatto.
Volendo riassumerlo: l'IP gestisce la frammentazione e deframmentazione dei
Datagram se necessario.
Il pacchetto viene spezzato in tanti frammenti, ognuno dei quali coniene anche
il numero di sequenza, tranne l'ultimo che contiene anche un flag di Ultimo
Frammento.
Tutto cio' avviene in maniera trasparente; il contenuto del Datagram non ha
nessuna importanza per l'IP.
- Fragmentation
    Fragmentation of an internet datagram is necessary when it
    originates in a local net that allows a large packet size and must
    traverse a local net that limits packets to a smaller size to reach
    its destination.
    An internet datagram can be marked "don't fragment."  Any internet
    datagram so marked is not to be internet fragmented under any
    circumstances.  If internet datagram marked don't fragment cannot be
    delivered to its destination without fragmenting it, it is to be
    discarded instead.
    Fragmentation, transmission and reassembly across a local network
    which is invisible to the internet protocol module is called
    intranet fragmentation and may be used [6].
    The internet fragmentation and reassembly procedure needs to be able
    to break a datagram into an almost arbitrary number of pieces that
    can be later reassembled.  The receiver of the fragments uses the
    identification field to ensure that fragments of different datagrams
    are not mixed.  The fragment offset field tells the receiver the
    position of a fragment in the original datagram.  The fragment
    offset and length determine the portion of the original datagram
    covered by this fragment.  The more-fragments flag indicates (by
    being reset) the last fragment.  These fields provide sufficient
    information to reassemble datagrams.
    The identification field is used to distinguish the fragments of one
    datagram from those of another.  The originating protocol module of
    an internet datagram sets the identification field to a value that
    must be unique for that source-destination pair and protocol for the
    time the datagram will be active in the internet system.  The
    originating protocol module of a complete datagram sets the
    more-fragments flag to zero and the fragment offset to zero.
    To fragment a long internet datagram, an internet protocol module
    (for example, in a gateway), creates two new internet datagrams and
    copies the contents of the internet header fields from the long
    datagram into both new internet headers.  The data of the long
    datagram is divided into two portions on a 8 octet (64 bit) boundary
    (the second portion might not be an integral multiple of 8 octets,
    but the first must be).  Call the number of 8 octet blocks in the
    first portion NFB (for Number of Fragment Blocks).  The first
    portion of the data is placed in the first new internet datagram,
    and the total length field is set to the length of the first
[Page 8]
September 1981
                                                       Internet Protocol
                                                                Overview
    datagram.  The more-fragments flag is set to one.  The second
    portion of the data is placed in the second new internet datagram,
    and the total length field is set to the length of the second
    datagram.  The more-fragments flag carries the same value as the
    long datagram.  The fragment offset field of the second new internet
    datagram is set to the value of that field in the long datagram plus
    NFB.
    This procedure can be generalized for an n-way split, rather than
    the two-way split described.
    To assemble the fragments of an internet datagram, an internet
    protocol module (for example at a destination host) combines
    internet datagrams that all have the same value for the four fields:
    identification, source, destination, and protocol.  The combination
    is done by placing the data portion of each fragment in the relative
    position indicated by the fragment offset in that fragment's
    internet header.  The first fragment will have the fragment offset
    zero, and the last fragment will have the more-fragments flag reset
    to zero.
--
Ciauz!
   midorichan
////////////////////////////////////
     ... Erroneus Error. Nothing Wrong.


Non mi sembra che tu mi stia contraddicendo, è già stato detto più volte che
IP può frammentare i pacchetti, la differenza è che TCP lo fa di mestiere ed
in maniera affidabile (essendo un protocollo connesso e "reliable") mentre
IP lo fa solo se costretto per motivi di MTU (maximum trasmission unit, per
la cronaca) ed in maniera meno affidabile, essendo un protocollo non
connesso ed "unreliable".
Se nel percorso dei dati non esiste nessun dispositivo con un MTU più
piccolo della dimensione del pacchetto, IP non si sogna nemmeno di
frammentarlo.
Tra l'altro la frammentazione di un pacchetto da parte di IP è frutto spesso
di qualche errore, dato che le recenti implementazioni di IP sfruttano una
prestazione chiamata "mtu discovery" proprio per scoprire qual'è la
dimensione massima dei pacchetti da trasmettere in modo da evirare che IP di
ricorra alla frammentazione, cosa che introduce ritardi, occupa preziose
risorse nei routers e, come detto prima, è meno affidabile di quella operata
dal TCP.
In aggiunta, la frammentazione dei pacchetti da parte di IP può anche avere
degli effetti collaterali, mi spiego meglio:
l'header IP contiene, nel campo flag, un bit chiamato DF (don't fragment)
che se settato ad 1 impedisce la frammentazione del pacchetto (ad esempio
per motivi di QoS); ora, se un pacchetto con il bit DF settato deve
attraversare un dispositivo con una MTU più piccola della dimensione del
pacchetto viene scartato in quanto non passa e non è nemmeno possibile
frammentarlo.
Questa è un'altra ragione di esistere di mtu discovery e del fatto che, se
pur possibile, la frammentazione da parte di IP viene utilizzata solo se
indispensabile.
Ovviamente la soluzione a tutti questi problemi è che TCP "confezioni" per
IP dei pacchetti già adattati alla MTU più piccola tra quelle dei
dispositivi che il pacchetto stesso deve attraversare.
Ciao,
          Massimo.

 modifica).
E' vero, ho preso una svista enorme!
Ai fini dell'IP la porta non serve ad un tubo.
Grazie per la spiegazione.
ciau ciau
   midorichan

          Massimo.


Salve a tutti del NG sono un neofita dell'argomento che sto per descrivervi.
Quando mi connetto, c'è ZoneAlarm che è attivo e durante la connessione mi
sono arrivati una miriade di attacchi e mi spunta il seguente messaggio
ZoneAlarm
The firewall has blocked Internet access to your computer (TCP Port XXX)
from 
a1156.g.akamai.net
 (194.98.93.245) (HTTP).
Scusate la mia ignoranza nell'argomento ma ho capito che ci sono stati una
serie di attacchi e vorrei sapere come si può rimediare a questo e se c'è
pericolo per il mio sistema.
Grazie anticipatamente e a presto!
mailto:
cora...@inwind.it


Il Tanembaum sà senz'altro quello che dice, ma io non vedo nessuna relazione
tra il preambolo TCP e la frammentazione a livello IP, tanto più che il
preambolo TCP rimane all'interno del primo frammento IP, mentre tutti gli
altri frammenti conterranno dei dati incomprensibili per il TCP (sempre che
anche il primo possa essere considerato tale) e quindi i singoli frammenti
non hanno nessun valore per TCP; d'altra parte al termine del processo di
frammentazione/ricomposizione è obbligatorio ri-ottenere lo stesso pacchetto
TCP originale, se ne viene cambiata l'intestazione non sarà più tale.
La frammentazione IP è solo una tecnica, per cause di forza maggiore, che
permette ad IP di aggirare il problema delle diverse dimensioni dei
pacchetti permesse dai protocolli di livello inferiore, quindi rimane
imperativa la trasparenza verso i livelli superiori.
Ciao,
          Massimo.


   Ciao,



Mi sbaglierň (niente di piů facile, dato che non sono certo al livello degli
autori del Tanenbaum) ma mi pare na str....ata !!!
Ciao,
          Massimo.