Passa al contenuto principale

RFC 4944 - Transmission of IPv6 Packets over IEEE 802.15.4 Networks (Trasmissione di pacchetti IPv6 su reti IEEE 802.15.4)

  • Stato: Proposed Standard
  • Pubblicato: September 2007
  • Stream: IETF
  • Errata: Nessun errata

Abstract (Riassunto)​

Questo documento descrive i formati di frame per il trasporto di pacchetti IPv6 su reti IEEE 802.15.4, e i metodi per formare indirizzi IPv6 link-local e indirizzi configurati automaticamente senza stato su reti IEEE 802.15.4. Le specifiche aggiuntive includono un semplice schema di compressione delle intestazioni che usa un contesto condiviso, e le disposizioni per la consegna dei pacchetti in reti mesh IEEE 802.15.4.

Contents (Indice)​

Appendices (Appendici)​

Risorse correlate​

1. Introduction (Introduzione)​

Lo standard IEEE 802.15.4 [ieee802.15.4] è rivolto alle Low-Power Personal Area Network. Questo documento definisce i formati di frame per il trasporto di pacchetti IPv6 [RFC2460] su reti IEEE 802.15.4, e i metodi per formare indirizzi IPv6 link-local e indirizzi configurati automaticamente senza stato su reti IEEE 802.15.4. Poiché IPv6 richiede il supporto di dimensioni di pacchetto molto maggiori rispetto alla dimensione massima di un frame IEEE 802.15.4, viene definito un livello di adattamento (Adaptation Layer). Questo documento definisce inoltre i meccanismi di compressione delle intestazioni necessari per rendere pratico IPv6 su reti IEEE 802.15.4, e le disposizioni necessarie per la consegna dei pacchetti in reti mesh IEEE 802.15.4. Tuttavia, la specifica completa del routing mesh, inclusi protocolli specifici e interazioni con Neighbor Discovery, è fuori dall'ambito di questo documento.

1.1. Requirements Notation (Notazione dei requisiti)​

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC2119].

1.2. Terms Used (Termini usati)​

AES: Advanced Encryption Scheme

CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance

FFD: Full Function Device

GTS: Guaranteed Time Service

MTU: Maximum Transmission Unit

MAC: Media Access Control

PAN: Personal Area Network

RFD: Reduced Function Device

2. IEEE 802.15.4 Mode for IP (Modalità IEEE 802.15.4 per IP)​

IEEE 802.15.4 definisce quattro tipi di frame: beacon frame, MAC command frame, acknowledgement frame e data frame. I pacchetti IPv6 DEVONO essere trasportati nei data frame. Un data frame può richiedere facoltativamente un acknowledgement. In coerenza con [RFC3819], si RACCOMANDA di trasportare i pacchetti IPv6 in frame che richiedono acknowledgement, per aiutare il recupero a livello collegamento.

Una rete IEEE 802.15.4 può essere nonbeacon-enabled o beacon-enabled [ieee802.15.4]. Quest'ultima è una modalità facoltativa in cui i dispositivi si sincronizzano tramite beacon emessi da un coordinator. Questo consente l'uso di superframe, nei quali può essere implementato il Guaranteed Time Service (GTS) privo di contesa. Questo documento NON RICHIEDE che la rete IEEE operi in modalità beacon-enabled. In una rete nonbeacon-enabled, i data frame, inclusi quelli che trasportano pacchetti IPv6, sono inviati tramite il metodo di accesso al canale CSMA/CA non slotted e basato su contesa.

In una rete nonbeacon-enabled, i beacon non vengono usati per la sincronizzazione. Tuttavia, restano utili per la scoperta dei dispositivi a livello collegamento, aiutando gli eventi di associazione e disassociazione. Questo documento RACCOMANDA di configurare i beacon per supportare tali funzioni. Un'ulteriore raccomandazione è rendere questi eventi disponibili al livello IPv6, per aiutare il rilevamento dell'attacco alla rete, tema che al momento della scrittura era oggetto di studio in IETF.

La specifica consente frame in cui l'indirizzo sorgente o l'indirizzo di destinazione, oppure entrambi, siano omessi. I meccanismi definiti in questo documento RICHIEDONO che l'intestazione del frame IEEE 802.15.4 includa sia l'indirizzo sorgente sia l'indirizzo di destinazione. Possono inoltre essere inclusi i campi PAN ID sorgente o destinazione.

3. Addressing Modes (Modalità di indirizzamento)​

IEEE 802.15.4 definisce diverse modalità di indirizzamento: consente l'uso di indirizzi estesi IEEE a 64 bit oppure, dopo un evento di associazione, di indirizzi a 16 bit univoci all'interno del PAN [ieee802.15.4]. Questo documento supporta sia gli indirizzi estesi a 64 bit sia gli indirizzi brevi a 16 bit.

Per l'uso in una 6LoWPAN, questo documento impone vincoli aggiuntivi sul formato degli indirizzi brevi a 16 bit, oltre ai vincoli imposti da IEEE 802.15.4, come specificato nella Sezione 12. Poiché gli indirizzi brevi sono intrinsecamente temporanei, è necessaria particolare attenzione: essendo assegnati dalla funzione PAN coordinator durante un evento di associazione, validità e unicità sono limitate alla durata di tale associazione. Questa durata può essere abbreviata dalla scadenza dell'associazione o da un guasto del PAN coordinator. A causa dei problemi di scalabilità introdotti da questa allocazione centralizzata e dal single point of failure presso il PAN coordinator, chi dispiega la rete dovrebbe valutare attentamente vantaggi e svantaggi dell'espansione basata su indirizzi brevi e implementare i meccanismi necessari. Gli indirizzi estesi IEEE a 64 bit non soffrono necessariamente di questi difetti, ma condividono comunque i restanti problemi di scalabilità relativi a routing, discovery e configurazione.

Questo documento assume che un PAN corrisponda a uno specifico collegamento IPv6. Ciò è coerente con la raccomandazione secondo cui una rete condivisa dovrebbe supportare il broadcast del subnet a livello collegamento [RFC3819]. In senso stretto, in IPv6 esiste multicast e non broadcast. Tuttavia, IEEE 802.15.4 non supporta multicast nativo. Pertanto, i pacchetti multicast del livello IPv6 DEVONO essere trasportati come frame broadcast di livello collegamento in una rete IEEE 802.15.4. Questo DEVE essere fatto in modo che il frame broadcast sia considerato solo dai dispositivi nel PAN specifico del collegamento in questione. Secondo la Sezione 7.5.6.2 di [ieee802.15.4], ciò si ottiene così:

  1. Il frame DEVE includere il Destination PAN Identifier, che DEVE corrispondere al PAN ID del collegamento in questione.

  2. Il frame DEVE includere uno Short Destination Address, che DEVE corrispondere all'indirizzo broadcast (0xffff).

Inoltre, il supporto alla mappatura degli indirizzi multicast IPv6 della Sezione 9 DEVE essere usato solo in una configurazione mesh. La specifica completa di tale funzionalità è fuori dall'ambito di questo documento.

Come di consueto, gli host apprendono i prefissi IPv6 tramite Router Advertisement, come descritto in [RFC4861].

4. Maximum Transmission Unit (Unità massima di trasmissione)​

La MTU dei pacchetti IPv6 su IEEE 802.15.4 è di 1280 ottetti. Tuttavia, un pacchetto IPv6 completo non entra in un singolo frame IEEE 802.15.4. Le PDU IEEE 802.15.4 hanno dimensioni diverse a seconda dell'overhead presente [ieee802.15.4]. Partendo dalla dimensione massima del pacchetto fisico, 127 ottetti (aMaxPHYPacketSize), e dall'overhead massimo del frame, 25 ottetti (aMaxFrameOverhead), la dimensione massima finale del frame a livello MAC è di 102 ottetti. La sicurezza a livello collegamento introduce ulteriore overhead; nel caso peggiore, AES-CCM-128 aggiunge 21 ottetti, mentre AES-CCM-32 e AES-CCM-64 aggiungono rispettivamente 9 e 13 ottetti, lasciando disponibili solo 81 ottetti. Questo è chiaramente molto meno della dimensione minima dei pacchetti IPv6, 1280 ottetti, e secondo la Sezione 5 della specifica IPv6 [RFC2460] un livello sotto IP DEVE fornire un livello di adattamento per frammentazione e riassemblaggio. Tale livello è definito nella Sezione 5.

Inoltre, poiché l'intestazione IPv6 è lunga 40 ottetti, rimangono solo 41 ottetti per protocolli superiori come UDP. Quest'ultimo usa 8 ottetti di intestazione, lasciando solo 33 ottetti per i dati applicativi. Come indicato sopra, è inoltre necessario un livello di frammentazione e riassemblaggio, che userà ulteriori ottetti.

Le considerazioni precedenti portano a due osservazioni:

  1. DEVE essere fornito un livello di adattamento per soddisfare il requisito della MTU minima IPv6. Tuttavia, ci si aspetta che (a) la maggior parte delle applicazioni IEEE 802.15.4 non usi pacchetti così grandi, e (b) payload applicativi più piccoli, combinati con una compressione appropriata delle intestazioni, producano pacchetti che entrano in un singolo frame IEEE 802.15.4. La ragione di questo livello di adattamento non è solo la conformità a IPv6, perché alcuni scambi applicativi, ad esempio configurazione o provisioning, produrranno probabilmente pacchetti che richiedono pochi frammenti.

  2. Anche se il calcolo dello spazio mostrato sopra rappresenta il caso peggiore, indica chiaramente che la compressione delle intestazioni è quasi inevitabile. Poiché ci si aspetta che la maggior parte, se non tutte, le applicazioni IP over IEEE 802.15.4 usino la compressione delle intestazioni, essa è definita nella Sezione 10.

5. LoWPAN Adaptation Layer and Frame Format (Livello di adattamento LoWPAN e formato dei frame)​

I formati di incapsulamento definiti in questa sezione, indicati nel seguito come "incapsulamento LoWPAN", costituiscono il payload della MAC Protocol Data Unit (PDU) IEEE 802.15.4. Il payload LoWPAN, ad esempio un pacchetto IPv6, segue immediatamente queste intestazioni di incapsulamento.

Tutti i datagrammi incapsulati LoWPAN trasmessi su IEEE 802.15.4 sono preceduti da uno stack di intestazioni di incapsulamento. Ogni intestazione nello stack contiene un tipo di intestazione, seguito da zero o più campi. In un'intestazione IPv6, lo stack contiene nell'ordine: indirizzamento, hop-by-hop options, routing, frammentazione, destination options e infine payload [RFC2460]. Nelle intestazioni LoWPAN, una sequenza analoga è: indirizzamento mesh (L2), hop-by-hop options, inclusi broadcast/multicast L2, frammentazione e infine payload.

Esempio tipico di stack di intestazioni:

Datagramma IPv6 incapsulato in LoWPAN:

+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+

Caso con indirizzamento mesh e frammentazione:

+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+

Quando più intestazioni LoWPAN sono usate nello stesso pacchetto, DEVONO apparire nell'ordine seguente: intestazione di indirizzamento mesh, intestazione broadcast, intestazione di frammentazione.

5.1. Dispatch Type and Header (Tipo e intestazione Dispatch)​

Il tipo Dispatch è identificato dai primi due bit "01"; un selettore a 6 bit identifica il tipo di intestazione immediatamente successivo.

Pattern di bit dei valori Dispatch:

  • 00 xxxxxx: NALP, non è un frame LoWPAN
  • 01 000001: IPv6, indirizzi IPv6 non compressi
  • 01 000010: LOWPAN_HC1, IPv6 compresso con HC1
  • 01 010000: LOWPAN_BC0, broadcast BC0
  • 01 111111: ESC, byte Dispatch aggiuntivo
  • 10 xxxxxx: MESH, intestazione mesh
  • 11 000xxx: FRAG1, intestazione del primo frammento
  • 11 100xxx: FRAGN, intestazione dei frammenti successivi

5.2. Mesh Addressing Type and Header (Tipo e intestazione di indirizzamento mesh)​

Il tipo mesh è definito dai primi due bit "10":

|1 0|V|F|HopsLft| originator address, final address

Definizione dei campi:

  • V: 1 bit; 0 indica che l'indirizzo dell'originator è a 64 bit, 1 indica un indirizzo breve a 16 bit
  • F: 1 bit; 0 indica che l'indirizzo della destinazione finale è a 64 bit, 1 indica un indirizzo breve a 16 bit
  • Hops Left: 4 bit; decrementato a ogni inoltro, il pacchetto viene scartato quando raggiunge 0. Il valore 0xF indica che segue un campo di estensione a 8 bit
  • Originator Address: indirizzo di livello collegamento dell'originator
  • Final Destination Address: indirizzo di livello collegamento della destinazione finale

5.3. Fragmentation Type and Header (Tipo e intestazione di frammentazione)​

Se un datagramma non entra in un singolo frame 802.15.4, DEVE essere suddiviso in frammenti di collegamento. Tutti i frammenti tranne l'ultimo DEVONO avere dimensione multipla di 8 ottetti.

Intestazione del primo frammento (FRAG1):

|1 1 0 0 0| datagram_size | datagram_tag |

Intestazione dei frammenti successivi (FRAGN):

|1 1 1 0 0| datagram_size | datagram_tag |
|datagram_offset|

Definizione dei campi:

  • datagram_size: 11 bit, codifica la dimensione dell'intero pacchetto IP prima della frammentazione di livello collegamento. Per IPv6, il valore è Payload Length + 40
  • datagram_tag: 16 bit, uguale per tutti i frammenti dello stesso datagramma; il mittente incrementa questo valore per datagrammi consecutivi
  • datagram_offset: 8 bit, offset del frammento in unità di 8 ottetti; presente solo nei frammenti successivi

Regole di riassemblaggio:

Il ricevitore identifica i frammenti dello stesso datagramma usando:

  1. indirizzo sorgente 802.15.4 del mittente, o indirizzo originator mesh
  2. indirizzo 802.15.4 della destinazione, o indirizzo final destination mesh
  3. datagram_size
  4. datagram_tag

Il timeout di riassemblaggio DEVE essere al massimo 60 secondi. Quando viene rilevato un evento di disassociazione, tutti i frammenti parzialmente riassemblati DEVONO essere scartati.

6. Stateless Address Autoconfiguration (Autoconfigurazione degli indirizzi senza stato)​

Questa sezione definisce come ottenere l'Interface Identifier IPv6.

L'Interface Identifier [RFC4291] per un'interfaccia IEEE 802.15.4 può essere basato sull'identificatore EUI-64 assegnato al dispositivo IEEE 802.15.4 [EUI64]. In questo caso, l'Interface Identifier è formato dall'EUI-64 secondo la specifica "IPv6 over Ethernet" [RFC2464].

Tutti i dispositivi 802.15.4 hanno un indirizzo IEEE EUI-64, ma sono possibili anche indirizzi brevi a 16 bit, come nelle Sezioni 3 e 12. In questi casi si forma un "indirizzo pseudo a 48 bit" nel modo seguente. Prima, i 32 bit più a sinistra sono formati concatenando 16 bit zero al PAN ID a 16 bit; se il PAN ID non è noto, possono essere usati 16 bit zero. Questo produce il campo a 32 bit:

16_bit_PAN:16_zero_bits

Poi questi 32 bit sono concatenati all'indirizzo breve a 16 bit. Questo produce l'indirizzo a 48 bit:

32_bits_as_specified_previously:16_bit_short_address

L'Interface Identifier è formato da questo indirizzo a 48 bit secondo la specifica "IPv6 over Ethernet" [RFC2464]. Tuttavia, nell'Interface Identifier risultante, il bit "Universal/Local" (U/L) DEVE essere impostato a zero, per riflettere il fatto che il valore non è globalmente univoco. Per entrambi i formati di indirizzo, NON DEVE essere usato l'indirizzo tutto zero.

Un indirizzo MAC diverso, impostato manualmente o tramite software, PUÒ essere usato per derivare l'Interface Identifier. Se viene usato un indirizzo MAC di questo tipo, la sua proprietà di unicità globale dovrebbe riflettersi nel valore del bit U/L.

Il prefisso degli indirizzi IPv6 usato per l'autoconfigurazione senza stato [RFC4862] sulle interfacce IEEE 802.15.4 DEVE avere lunghezza di 64 bit.

9. Multicast Address Mapping (Mappatura degli indirizzi multicast)​

La funzionalità di questa sezione DEVE essere usata solo in una LoWPAN con mesh abilitata. Un pacchetto IPv6 con indirizzo di destinazione multicast (DST), composto dai sedici ottetti DST[1] fino a DST[16], viene trasmesso al seguente indirizzo multicast 802.15.4 a 16 bit:

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |1 0 0|DST[15]* |   DST[16]     |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 8: formato della mappatura multicast

Qui DST[15]* indica gli ultimi 5 bit dell'ottetto DST[15], cioè i bit 3-7 all'interno di DST[15]. Il pattern iniziale a 3 bit "100" segue il formato degli indirizzi multicast a 16 bit della Sezione 12.

Questo consente il supporto multicast all'interno della rete 6LoWPAN, ma la specifica completa di tale supporto è fuori dall'ambito di questo documento. Esempi di meccanismi includono flooding, controlled flooding e unicast verso il PAN coordinator. Ci si aspetta che ciò sia specificato dai diversi meccanismi di routing mesh.

10. Header Compression (Compressione delle intestazioni)​

Esiste una quantità significativa di lavoro pubblicato e in corso di standardizzazione sulla compressione delle intestazioni. Tuttavia, la compressione delle intestazioni per IPv6 over IEEE 802.15.4 ha vincoli diversi, riassunti di seguito:

  • Il lavoro esistente assume molti flussi tra due dispositivi qualunque. Qui si assume uno stile di compressione delle intestazioni molto semplice e con poco contesto. Pur essendo indipendente dal lavoro sui flussi, che possono anche essere più di uno, non usa alcun contesto specifico di flusso. Pertanto non può raggiungere il grado di compressione ottenibile da schemi che costruiscono contesti separati per ciascun flusso da comprimere.

  • Date le dimensioni estremamente limitate dei pacchetti, è altamente desiderabile integrare la compressione di livello 2 e livello 3, cosa tradizionalmente non fatta, anche se sta cambiando grazie al lavoro del gruppo ROHC (RObust Header Compression).

  • Ci si aspetta che i dispositivi IEEE 802.15.4 siano dispiegati in reti multi-hop. Tuttavia, la compressione delle intestazioni in una rete mesh è diversa dallo scenario usuale di collegamento punto-punto, in cui compressore e decompressore comunicano direttamente ed esclusivamente fra loro. Nelle reti IEEE 802.15.4 è altamente desiderabile che un dispositivo possa inviare pacchetti con intestazioni compresse attraverso qualunque vicino, con una costruzione preliminare del contesto quanto più ridotta possibile.

Ogni nuovo formato di pacchetto richiesto dalla compressione delle intestazioni riusa il formato di pacchetto di base definito nella Sezione 5, usando valori Dispatch diversi.

La compressione delle intestazioni può produrre un allineamento che non cade su un confine di ottetto. Poiché l'hardware normalmente non trasmette unità inferiori all'ottetto, è necessario usare padding. Il padding è eseguito così: prima si dispongono tutte le intestazioni compresse contigue, questo documento definisce solo schemi di compressione per intestazioni IPv6 e UDP, anche se altri schemi possono essere definiti altrove. Poi si aggiungono bit zero quanto basta per allineare al confine di ottetto. Questo elimina il possibile disallineamento introdotto dalla compressione delle intestazioni, così che i campi successivi, ad esempio intestazioni non compresse o payload dati, inizino su un confine di ottetto e procedano normalmente.

10.1. Encoding of IPv6 Header Fields (Codifica dei campi dell'intestazione IPv6)​

Unendosi alla stessa rete 6LoWPAN, i dispositivi condividono una parte dello stato. Questo consente di comprimere le intestazioni senza costruire esplicitamente uno stato di contesto di compressione. Di conseguenza, la compressione delle intestazioni 6LoWPAN non conserva stato di flusso; si basa invece su informazioni associate all'intero collegamento. I seguenti valori dell'intestazione IPv6 sono previsti come comuni in una rete 6LoWPAN, perciò l'intestazione HC1 è progettata per comprimerli efficacemente fin dall'inizio:

  • Version è IPv6
  • Gli indirizzi IPv6 sorgente e destinazione sono entrambi link-local
  • L'Interface Identifier IPv6, cioè i 64 bit meno significativi, dell'indirizzo sorgente o destinazione può essere dedotto dagli indirizzi sorgente e destinazione di livello 2; ciò vale naturalmente solo per Interface Identifier derivati dagli indirizzi MAC 802.15.4 sottostanti
  • La lunghezza del pacchetto può essere dedotta dal livello 2, tramite il campo "Frame Length" nella PPDU IEEE 802.15.4, o dal campo "datagram_size" dell'intestazione di frammentazione, se presente
  • Traffic Class e Flow Label sono entrambi zero
  • Next Header è UDP, ICMP o TCP

L'unico campo dell'intestazione IPv6 che deve sempre essere trasportato per intero è Hop Limit (8 bit). A seconda di quanto il pacchetto corrisponde a questo caso comune, alcuni campi potrebbero non essere comprimibili e dovranno quindi essere trasportati "in-line" (Sezione 10.3.1). Questa intestazione IPv6 comune, descritta sopra, può essere compressa a 2 ottetti, uno per la codifica HC1 e uno per Hop Limit, invece dei 40 ottetti originali.

Un pacchetto di questo tipo può essere compresso con il formato LOWPAN_HC1 usando il valore Dispatch LOWPAN_HC1, seguito dal campo "HC1 encoding" dell'intestazione LOWPAN_HC1 (8 bit), che codifica le diverse combinazioni mostrate sotto.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | HC1 encoding  |     Non-Compressed fields follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 9: LOWPAN_HC1 (codifica comune dell'intestazione compressa)

I campi indirizzo codificati da "HC1 encoding" sono interpretati così:

  • PI: Prefix carried in-line
  • PC: Prefix compressed, assume il prefisso link-local
  • II: Interface identifier carried in-line
  • IC: Interface identifier elided, derivabile dall'indirizzo di livello collegamento corrispondente

Codifica HC1, dai bit 0 a 7:

Indirizzo sorgente IPv6 (bit 0 e 1):

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

Indirizzo destinazione IPv6 (bit 2 e 3):

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

Traffic Class e Flow Label (bit 4):

  • 0: non compressi; invia gli 8 bit completi di Traffic Class e i 20 bit di Flow Label
  • 1: Traffic Class e Flow Label sono zero

Next Header (bit 5 e 6):

  • 00: non compresso; invia gli 8 bit completi
  • 01: UDP
  • 10: ICMP
  • 11: TCP

Codifica HC2 (bit 7):

  • 0: non seguono altri bit di compressione delle intestazioni
  • 1: la codifica HC1 è immediatamente seguita da ulteriori bit di compressione secondo il formato HC2. I bit 5 e 6 determinano quale possibile codifica HC2 si applica, ad esempio UDP, ICMP o TCP.

10.2. Encoding of UDP Header Fields (Codifica dei campi dell'intestazione UDP)​

I bit 5 e 6 di LOWPAN_HC1 consentono di comprimere il campo Next Header dell'intestazione IPv6 per UDP, TCP e ICMP. È anche possibile comprimere ulteriormente ciascuna di queste intestazioni di protocollo. Questa sezione spiega come comprimere l'intestazione UDP. La codifica HC2 in questa sezione è la codifica HC_UDP, applicabile solo quando i bit 5 e 6 in HC1 indicano che il protocollo successivo all'intestazione IPv6 è UDP.

La codifica HC_UDP consente la compressione dei seguenti campi dell'intestazione UDP: Source Port, Destination Port e Length. Il campo Checksum dell'intestazione UDP non è compresso e viene quindi trasportato per intero. Lo schema definito sotto consente di comprimere l'intestazione UDP a 4 ottetti invece degli 8 originali.

L'unico campo dell'intestazione UDP il cui valore può essere dedotto da informazioni disponibili altrove è Length. Gli altri campi devono essere trasportati in-line per intero o in forma parzialmente compressa (Sezione 10.3.2).

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |HC_UDP encoding|     Fields carried in-line follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 10: HC_UDP (codifica comune dell'intestazione UDP compressa)

"HC_UDP encoding" per UDP, dai bit 0 a 7:

UDP Source Port (bit 0):

  • 0: non compresso, trasportato in-line
  • 1: compresso a 4 bit. La porta sorgente effettiva a 16 bit è ottenuta come P + valore short_port. Il valore di P è 61616 (0xF0B0). short_port è rappresentato come valore a 4 bit, trasportato in-line

UDP Destination Port (bit 1):

  • 0: non compresso, trasportato in-line
  • 1: compresso a 4 bit. La porta destinazione effettiva a 16 bit è ottenuta come P + valore short_port. Il valore di P è 61616 (0xF0B0). short_port è rappresentato come valore a 4 bit, trasportato in-line

Length (bit 2):

  • 0: non compresso, trasportato in-line
  • 1: compresso; la lunghezza è calcolata dalle informazioni di lunghezza dell'intestazione IPv6. Il valore del campo UDP Length è pari al Payload Length dell'intestazione IPv6, meno la lunghezza di eventuali intestazioni di estensione presenti tra l'intestazione IPv6 e l'intestazione UDP

Riservati (bit 3-7)

10.3. Non-Compressed Fields (Campi non compressi)​

10.3.1. Non-Compressed IPv6 Fields (Campi IPv6 non compressi)​

Questo schema consente di comprimere l'intestazione IPv6 a vari livelli. Pertanto è necessario trasmettere solo i campi non compressi, invece dell'intera intestazione IPv6 standard. L'intestazione successiva, indicata dal campo Next Header nell'intestazione IPv6 originale, segue immediatamente i campi IPv6 non compressi.

Il campo IPv6 non compresso che DEVE sempre essere presente è Hop Limit (8 bit). Questo campo DEVE sempre seguire i campi di codifica, ad esempio il campo "HC1 encoding" mostrato nella Figura 9, eventualmente insieme ad altri campi di codifica futuri. Gli altri campi non compressi DEVONO seguire Hop Limit nell'ordine implicato da "HC1 encoding", esattamente nello stesso ordine mostrato sopra nella Sezione 10.1: prefisso sorgente (64 bit) e/o Interface Identifier (64 bit), prefisso destinazione (64 bit) e/o Interface Identifier (64 bit), Traffic Class (8 bit), Flow Label (20 bit) e Next Header (8 bit). L'effettiva intestazione successiva, ad esempio UDP, TCP o ICMP, segue i campi non compressi.

10.3.2. Non-Compressed and Partially Compressed UDP Fields (Campi UDP non compressi e parzialmente compressi)​

Questo schema consente di comprimere l'intestazione UDP a vari livelli. Pertanto è necessario trasmettere solo i campi non compressi o parzialmente compressi, invece dell'intera intestazione UDP standard.

I campi non compressi o parzialmente compressi dell'intestazione UDP DEVONO sempre seguire l'intestazione IPv6 e tutti i relativi campi in-line. Qualsiasi campo in-line UDP presente DEVE apparire nello stesso ordine dei campi corrispondenti nella normale intestazione UDP [RFC0768], cioè Source Port, Destination Port, Length e Checksum. Se Source Port o Destination Port usa la rappresentazione "short_port", come mostrato nell'intestazione UDP compressa, il numero di porta in-line occupa 4 bit invece di 16.

Sebbene ci si aspetti che le reti 802.15.4 usino comunemente il routing mesh, la specifica IEEE 802.15.4-2003 [ieee802.15.4] non definisce tale capacità. In questo contesto, i Full Function Device (FFD) eseguono protocolli di routing ad hoc o mesh per popolare le loro tabelle di routing; ciò è fuori dall'ambito di questo documento. In uno scenario mesh, due dispositivi non devono necessariamente essere direttamente raggiungibili per comunicare. In questi dispositivi, il mittente è chiamato "originator" e il ricevitore è chiamato "final destination". Il dispositivo originator può usare altri dispositivi intermedi come forwarder verso la final destination. Per realizzare questa consegna dei frame usando unicast, oltre alla sorgente e alla destinazione hop-by-hop devono essere inclusi anche gli indirizzi di livello collegamento dell'originator e della final destination.

Questa sezione definisce come realizzare la consegna dei frame di livello 2 in una mesh, dato l'indirizzo di livello collegamento della "final destination".

La consegna mesh è realizzata includendo un'intestazione Mesh Addressing prima di qualsiasi altra intestazione dell'incapsulamento LoWPAN (Sezione 5), incluse intestazioni non frammentate o frammentate, un'intestazione IPv6 completa, oppure un'intestazione IPv6 compressa secondo la Sezione 10 o definita altrove.

Se un nodo vuole usare un forwarder mesh predefinito per consegnare un pacchetto, ad esempio perché non ha raggiungibilità diretta verso la destinazione, DEVE includere un'intestazione Mesh Addressing in cui l'indirizzo di livello collegamento dell'originator è impostato al proprio indirizzo e l'indirizzo di livello collegamento della final destination è impostato alla destinazione finale del pacchetto. Imposta l'indirizzo sorgente nell'intestazione 802.15.4 al proprio indirizzo di livello collegamento e inserisce l'indirizzo di livello collegamento del forwarder nel campo indirizzo di destinazione dell'intestazione 802.15.4. Infine, trasmette il pacchetto.

Analogamente, se un nodo riceve un frame con intestazione Mesh Addressing, DEVE esaminare il campo "Final Destination" dell'intestazione Mesh Addressing per determinare la destinazione reale. Se il nodo stesso è la final destination, consuma il pacchetto secondo la normale consegna. Se non è la final destination, il dispositivo decrementa il campo "Hops Left"; se il risultato è zero, scarta il pacchetto. Altrimenti, il nodo consulta la propria tabella di routing di livello collegamento, determina quale deve essere il next hop verso la final destination e inserisce quell'indirizzo nel campo indirizzo di destinazione dell'intestazione 802.15.4. Infine, il nodo cambia l'indirizzo sorgente nell'intestazione 802.15.4 impostandolo al proprio indirizzo di livello collegamento e trasmette il pacchetto.

Sebbene un nodo DEBBA partecipare a un protocollo di routing mesh per diventare forwarder, non esiste tale requisito per usare semplicemente l'inoltro mesh. Ci si aspetta che solo i Full Function Device (FFD) partecipino come router nella mesh. I Reduced Function Device (RFD) si limitano a scoprire gli FFD e a usarli per tutto l'inoltro, in modo simile a come un host IP usa normalmente un router predefinito per inoltrare tutto il traffico fuori dal proprio collegamento. Per un RFD che usa la consegna mesh, il "forwarder" è sempre l'FFD appropriato.

11.1. LoWPAN Broadcast (Broadcast LoWPAN)​

Funzionalità aggiuntive di routing mesh sono codificate usando un'intestazione di routing che segue immediatamente l'intestazione mesh. In particolare, l'intestazione broadcast è composta dal Dispatch LOWPAN_BC0 seguito dal campo Sequence Number. Il Sequence Number è usato per rilevare pacchetti duplicati e, auspicabilmente, sopprimerli.

                       1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|1|LOWPAN_BC0 |Sequence Number|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 11: intestazione broadcast

Definizione dei campi:

Sequence Number: questo campo a 8 bit DEVE essere incrementato dall'originator ogni volta che invia un nuovo pacchetto mesh broadcast o multicast. La specifica completa di come trattare questo campo è fuori dall'ambito di questo documento.

Le ulteriori implicazioni di tale broadcast a livello mesh, ad esempio la sua mappatura su un meccanismo di controlled flooding o il suo ruolo nella scoperta della topologia, sono fuori dall'ambito di questo documento.

Capacità aggiuntive di routing mesh, come la specifica di un protocollo di routing mesh o source routing, possono essere espresse definendo ulteriori intestazioni di routing posizionate nello stack di intestazioni prima delle intestazioni di frammentazione o indirizzamento. La specifica completa di tali capacità di routing mesh è fuori dall'ambito di questo documento.

12. IANA Considerations (Considerazioni IANA)​

Questo documento crea due nuovi registri IANA, descritti di seguito. Le future assegnazioni in questi registri saranno coordinate da IANA secondo la policy "Specification Required" [RFC2434]. Ci si aspetta che questa policy consenta ad altre organizzazioni, anche non IETF, di ottenere assegnazioni più facilmente.

Registro del campo Dispatch Type​

Questo documento crea un nuovo registro IANA per il campo Dispatch Type mostrato nelle definizioni di intestazione della Sezione 5. Il documento definisce valori per IPv6, compressione delle intestazioni LOWPAN_HC1, broadcast BC0 e due modalità di escape: NALP indica che non si tratta di un frame LoWPAN, mentre ESC consente byte Dispatch aggiuntivi. Questo documento definisce il campo come lungo 8 bit. I valori 00xxxxxx sono riservati e non usati; restano quindi 192 valori distinti, quantità che dovrebbe essere sufficiente. Se vengono definiti formati di compressione delle intestazioni diversi da HC1, oppure ulteriori formati HC2 per TCP o ICMP, ci si aspetta che usino i valori Dispatch riservati successivi a LOWPAN_HC1. Se vengono definiti formati aggiuntivi per la consegna mesh, ci si aspetta che usino i valori riservati successivi a LOWPAN_BC0.

Registro degli indirizzi brevi a 16 bit​

Questo documento crea un nuovo registro IANA per il campo indirizzo breve a 16 bit usato nei pacchetti 6LoWPAN.

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |     16-bit short Address      |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 12: formato dell'indirizzo breve a 16 bit

Questo registro DEVE includere gli indirizzi 0xffff, indirizzo broadcast a 16 bit accettato da tutti i dispositivi che ascoltano il canale corrente, e 0xfffe, come definiti in [ieee802.15.4]. Inoltre, all'interno di una rete 6LoWPAN, gli indirizzi brevi a 16 bit DEVONO seguire il formato seguente, riferito all'ordine dei campi di bit da 0 a 7, dove "x" indica un valore di bit non specificato:

Range 1, 0xxxxxxxxxxxxxxx: se l'indirizzo a 16 bit è un indirizzo unicast, il primo bit (bit 0) DEVE essere zero. Restano 15 bit per l'indirizzo effettivo.

Range 2, 100xxxxxxxxxxxxx: se l'indirizzo a 16 bit è un indirizzo multicast, vedere la Sezione 9, i bit 0, 1 e 2 DEVONO seguire questo pattern. Restano 13 bit per l'indirizzo multicast effettivo.

Range 3, 101xxxxxxxxxxxxx: questo pattern per i bit 0, 1 e 2 è riservato. Qualsiasi assegnazione futura deve seguire la policy sopra indicata.

Range 4, 110xxxxxxxxxxxxx: questo pattern per i bit 0, 1 e 2 è riservato. Qualsiasi assegnazione futura deve seguire la policy sopra indicata.

Range 5, 111xxxxxxxxxxxxx: questo pattern per i bit 0, 1 e 2 è riservato. Qualsiasi assegnazione futura deve seguire la policy sopra indicata.

13. Security Considerations (Considerazioni sulla sicurezza)​

Il metodo per derivare Interface Identifier da indirizzi MAC EUI-64 mira a mantenere l'unicità globale quando possibile. Tuttavia, non fornisce protezione contro duplicati causati accidentalmente o tramite falsificazione.

Neighbor Discovery sui collegamenti IEEE 802.15.4 può essere vulnerabile alle minacce dettagliate in [RFC3756]. Ci si aspetta che il routing mesh sia comune nelle reti IEEE 802.15.4. Questo implica minacce aggiuntive dovute al routing ad hoc, secondo [KW03]. IEEE 802.15.4 fornisce alcune capacità per la sicurezza a livello collegamento. Quando possibile e pratico, si raccomanda fortemente agli utenti di usare tali disposizioni. Questo mitigherà le minacce descritte sopra.

Ci si aspetta che una parte significativa dei dispositivi IEEE 802.15.4 comunichi sempre all'interno del proprio PAN, cioè, in termini IPv6, all'interno del proprio collegamento. Per rispondere a considerazioni di costo e consumo energetico, e in coerenza con il modello IEEE 802.15.4 dei Reduced Function Device (RFD), questi dispositivi implementeranno spesso solo l'insieme minimo di funzionalità necessarie. Di conseguenza, la sicurezza di tali dispositivi può dipendere in larga misura dai meccanismi definiti da IEEE 802.15.4 a livello collegamento. Tuttavia, questi ultimi definiscono solo modalità Advanced Encryption Standard (AES) per autenticare o cifrare frame IEEE 802.15.4, e in particolare non specificano la gestione delle chiavi, che potrebbe essere orientata ai gruppi. Ulteriori problemi da affrontare nei dispiegamenti reali riguardano configurazione e gestione sicure. Anche se il quadro completo è fuori dall'ambito di questo documento, tali considerazioni devono essere prese in conto quando si dispiegano reti IEEE 802.15.4. Naturalmente, ci si aspetta anche che alcuni dispositivi IEEE 802.15.4, i cosiddetti Full Function Device (FFD), implementino funzioni di coordinamento o integrazione. Questi dispositivi possono comunicare periodicamente con peer IPv6 fuori dal collegamento, oltre ai più comuni scambi intra-link. Ci si aspetta che tali dispositivi IPv6 proteggano la comunicazione end-to-end con meccanismi comuni come IPsec o TLS.

14. Acknowledgements (Ringraziamenti)​

Si ringraziano gli autori di RFC 2464 e RFC 2734, poiché parti di questo documento sono state scritte seguendo il loro modello. Si ringrazia Geoff Mulligan per le discussioni utili che hanno contribuito a plasmare questo documento. I suggerimenti di Erik Nordmark sono stati fondamentali per la sezione sulla compressione delle intestazioni. Si ringraziano inoltre Shoichi Sakane, Samita Chakrabarti, Vipul Gupta, Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus Westerlund e Jari Arkko.