Passa al contenuto principale

RFC 6864 - Specifica aggiornata del campo ID IPv4

  • Stato: Proposed Standard
  • Pubblicato: February 2013
  • Stream: IETF
  • Aggiorna: RFC791, RFC1122, RFC2003
  • Errata: Nessun errata

Stato di questo Memo​

Questo è un documento Internet Standards Track.

Questo documento è un prodotto dell'Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto una revisione pubblica ed è stato approvato per la pubblicazione dall'Internet Engineering Steering Group (IESG). Ulteriori informazioni sugli standard Internet sono disponibili nella Sezione 2 di RFC 5741.

Le informazioni sullo stato attuale di questo documento, eventuali errata e come fornire feedback possono essere ottenute all'indirizzo http://www.rfc-editor.org/info/rfc6864.

Copyright (c) 2013 IETF Trust e le persone identificate come autori del documento. Tutti i diritti riservati.

Questo documento è soggetto a BCP 78 e alle disposizioni legali dell'IETF Trust relative ai documenti IETF (http://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i vostri diritti e le restrizioni relative a questo documento.

Sommario​

Il campo di identificazione IPv4 (ID) abilita la frammentazione e il riassemblaggio e, come attualmente specificato, deve essere univoco entro la durata massima per tutti i datagrammi con la stessa tupla indirizzo sorgente/indirizzo destinazione/protocollo. Tuttavia, le implementazioni attuali non seguono questa specifica e trattano il campo ID come un valore univoco per ogni datagramma, il che può portare all'esaurimento del campo ID su dispositivi ad alta velocità. Questo documento aggiorna la specifica del campo ID IPv4 in RFC 791, RFC 1122 e RFC 2003 per avvicinarla alla pratica attuale e discute le implicazioni di questi cambiamenti per i progettisti di datagrammi.

Indice​

1. Introduzione​

2. Il campo ID IPv4​

3. Aggiornamenti alla specifica ID IPv4​

4. Impatto dei cambiamenti proposti​

5. Aggiornamenti agli standard esistenti​

6. Considerazioni sulla sicurezza​

7. Riferimenti​

Appendice A. Rilevabilità dei duplicati​

Appendice B. Ringraziamenti​

Fonte ufficiale: IETF RFC 6864

1. Introduzione​

In IPv4, il campo di identificazione (ID) è un valore a 16 bit utilizzato per supportare la frammentazione e il riassemblaggio dei datagrammi. Secondo la specifica attuale, il campo ID deve essere univoco entro la durata di vita massima del segmento (MSL) per i datagrammi con la stessa tupla indirizzo sorgente/indirizzo destinazione/protocollo. Tuttavia, le implementazioni attuali non seguono rigorosamente questa specifica e trattano il campo ID come un identificatore univoco per ogni datagramma, indipendentemente dal fatto che sia frammentato o meno.

In IPv4, i protocolli di trasporto e di livello superiore utilizzano generalmente campi a 16 o 32 bit per rilevare datagrammi duplicati, come i numeri di sequenza TCP o i checksum UDP. Tuttavia, il campo ID IPv4 ha solo 16 bit, il che significa che in ambienti di rete ad alta velocità, il campo ID potrebbe esaurirsi rapidamente, rendendo impossibile assegnare valori ID univoci per nuovi datagrammi.

In IPv6, la frammentazione viene eseguita solo dal nodo sorgente e l'intestazione del frammento contiene un campo di identificazione a 32 bit. La specifica IPv6 afferma esplicitamente che questo campo di identificazione deve essere univoco solo quando il datagramma viene frammentato. Al contrario, il campo ID IPv4 è presente in tutti i datagrammi, indipendentemente dalla frammentazione.

Questo documento aggiorna la specifica del campo ID IPv4 in RFC 791, RFC 1122 e RFC 2003 per avvicinarla alla pratica attuale e renderla coerente con l'elaborazione IPv6. In particolare, questo documento chiarisce i seguenti punti:

  1. Datagrammi atomici: Per i datagrammi con il flag DF (Don't Fragment) impostato, il campo ID può essere impostato su qualsiasi valore e il ricevitore deve ignorare il valore del campo.

  2. Datagrammi non atomici: Per i datagrammi senza il flag DF impostato, il campo ID deve essere univoco durante il periodo di timeout di riassemblaggio per garantire un corretto riassemblaggio dei frammenti.

  3. Compatibilità: Questo documento discute gli impatti di questi cambiamenti sui dispositivi e protocolli esistenti e fornisce raccomandazioni per il periodo di transizione.

Navigazione:

2. Il campo ID IPv4​

Il campo di identificazione IPv4 (ID) è stato originariamente progettato per supportare la frammentazione e il riassemblaggio dei datagrammi. Secondo RFC 791, il campo ID deve essere univoco entro la durata massima di vita del segmento (MSL) per i datagrammi con lo stesso indirizzo sorgente, indirizzo destinazione e protocollo.

2.1 IPv4 ID per la frammentazione​

Il campo ID IPv4 viene utilizzato principalmente per supportare la frammentazione e il riassemblaggio. In ambienti ad alta velocità, il campo ID a 16 bit può esaurirsi rapidamente.

2.2 IPv4 ID per il rilevamento duplicati​

Oltre alla frammentazione, il campo ID può essere utilizzato per rilevare datagrammi duplicati. Tuttavia, in ambienti ad alta velocità, il campo ID può ripetersi rapidamente.

2.3 Contesto dei problemi di riassemblaggio​

In ambienti ad alta velocità, la limitazione a 16 bit può causare esaurimento del campo ID, errori di riassemblaggio e degradazione delle prestazioni.

Navigazione:

3. Aggiornamenti alla specifica ID IPv4​

Questo capitolo descrive gli aggiornamenti alla specifica del campo ID IPv4.

3.1 IPv4 ID per datagrammi atomici​

Per i datagrammi atomici (DF=1), il mittente PUÒ (MAY) impostare il campo ID su qualsiasi valore e il ricevitore DEVE (MUST) ignorare il campo ID.

3.2 IPv4 ID per datagrammi non atomici​

Per i datagrammi non atomici (DF=0), il mittente DEVE (MUST) garantire che il campo ID sia univoco durante il periodo di timeout di riassemblaggio.

Navigazione:

4. Impatto dei cambiamenti proposti​

Questo capitolo analizza gli impatti degli aggiornamenti del campo ID IPv4 sui dispositivi esistenti, sulla generazione di datagrammi e sugli schemi di compressione degli header.

4.1 Impatto sui dispositivi Internet legacy​

I dispositivi legacy possono continuare a funzionare senza modifiche, garantendo la retrocompatibilità.

4.2 Impatto sulla generazione di datagrammi​

I nuovi mittenti possono utilizzare algoritmi di generazione ID semplificati per datagrammi atomici, migliorando le prestazioni.

4.3 Impatto sugli schemi di compressione degli header​

Gli schemi di compressione degli header potrebbero richiedere adattamenti per le nuove specifiche.

Navigazione:

5. Aggiornamenti agli standard esistenti​

Questo capitolo descrive gli aggiornamenti specifici a RFC 791, RFC 1122 e RFC 2003.

5.1 Aggiornamenti a RFC 791​

RFC 791 è la specifica IPv4 di base. Questo documento aggiorna la specifica del campo ID per distinguere tra datagrammi atomici e non atomici.

5.2 Aggiornamenti a RFC 1122​

RFC 1122 definisce i requisiti per gli host Internet. Gli aggiornamenti includono nuovi comportamenti per datagrammi atomici e non atomici.

5.3 Aggiornamenti a RFC 2003​

RFC 2003 definisce l'incapsulamento IP-in-IP. Gli aggiornamenti includono regole per header esterni e interni.

Navigazione:

6. Considerazioni sulla sicurezza​

Questo capitolo discute le implicazioni di sicurezza degli aggiornamenti del campo ID IPv4.

6.1 Implicazioni sulla privacy​

La strategia di generazione del campo ID può rivelare informazioni sul mittente. Contromisure includono l'uso di valori casuali e contatori per flusso.

6.2 Attacchi di frammentazione​

La frammentazione IPv4 può essere sfruttata per vari attacchi. Contromisure includono l'uso di datagrammi atomici e Path MTU Discovery.

6.3 Attacchi di collisione ID​

Gli attaccanti possono tentare di sfruttare la capacità limitata dell'ID. Contromisure includono generazione ID randomizzata e IPsec.

6.4 Attacchi denial-of-service​

L'elaborazione del campo ID IPv4 può essere bersaglio di attacchi DoS. Contromisure includono limitazione di velocità e gestione delle risorse.

Navigazione:

Appendice A. Capacità di rilevamento duplicati​

Questa appendice discute il ruolo del campo ID IPv4 nel rilevamento di datagrammi duplicati e l'impatto degli aggiornamenti sulla capacità di rilevamento duplicati.

A.1 Contesto del rilevamento duplicati​

I datagrammi duplicati possono verificarsi per vari motivi: ritrasmissione dello strato di collegamento, loop di routing, bilanciamento del carico e attacchi malevoli.

A.2 Limitazioni dell'IPv4 ID​

Il campo ID a 16 bit ha limitazioni come meccanismo di rilevamento duplicati in ambienti ad alta velocità.

A.3 Impatto degli aggiornamenti RFC 6864​

Per i datagrammi atomici, il campo ID IPv4 non fornisce più capacità di rilevamento duplicati.

A.4 Meccanismi raccomandati​

I meccanismi raccomandati includono numeri di sequenza TCP, meccanismi dello strato applicativo e IPsec.

Navigazione:

Appendice B. Ringraziamenti​

L'autore di questo documento ringrazia le seguenti persone e organizzazioni per i loro contributi e supporto.

B.1 Contributori​

Lo sviluppo di questo documento ha beneficiato dei contributi di numerosi membri della comunità IETF, tra cui Fred Baker, Brian Carpenter, Wesley Eddy, Fernando Gont e altri.

B.2 Contributi del gruppo di lavoro​

Questo documento è stato ampiamente discusso e rivisto nel gruppo di lavoro IETF INTAREA (Internet Area).

B.3 Esperienza di implementazione​

Lo sviluppo ha tenuto conto dell'esperienza di implementazioni di sistemi operativi (Linux, FreeBSD, Windows), dispositivi di rete e applicazioni.

B.4 Contesto storico​

Lo sviluppo è stato ispirato da RFC 791 (1981), RFC 1122 (1989) e RFC 4963 (2007).

B.5 Indirizzo dell'autore​

Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292
U.S.A.

Navigazione: