IPv6: differenze tra "prefisso indirizzato" e "prefisso collegamento"?


14

Quali sono le differenze esatte tra "prefisso indirizzato" e "prefisso collegamento" per IPv6?
In che modo queste differenze in una traccia wirefrack? (se si osserva un host con un "prefisso indirizzato" assegnato o un host con un "prefisso link" assegnato).
In che modo queste differenze nel Neighbor Discovery Protocol? (dal punto di vista di un altro host / esterno)
Hanno a lavorare insieme , questi due tipi di prefissi?

Risposte:


19

Il modo più semplice per comprendere la differenza tra i due è tramite un esempio che mostra la natura gerarchica dei prefissi.

Una gerarchia di esempio

A un ISP è stato assegnato un prefisso da un RIR (Registro Internet regionale) che in questo esempio assumeremo 2001:db8::/32. Questo prefisso è diverso da quelli tramandati ai clienti, nel senso che l'ISP dovrà annunciarlo tramite BGP ad altri ISP con cui è stato analizzato.

L'ISP ora assegnerà i prefissi a un cliente. Per prima cosa si assegnano 2001:db8:0:1::/64al collegamento che collega il router ISP al router CPE (attrezzature del cliente). Questo è un prefisso di collegamento perché è assegnato a un collegamento. Come raccomandazione generale, dovrebbero essere presenti tutti i prefissi di collegamento in IPv6 /64.

Il router ISP invierà annunci router annunciando questo prefisso e il CPE utilizzerà SLAAC per costruire un indirizzo per l'interfaccia esterna che punta verso il router ISP all'interno del /64. Supponiamo che l'interfaccia esterna abbia ottenuto l'indirizzo IP 2001:db8:0:1:42:ff:fe00:42/64(in questa notazione /64è inclusa per ricordarci quale sia la lunghezza del prefisso del collegamento, ma avrei potuto anche lasciarlo fuori).

Questo prefisso di collegamento è sufficiente per consentire al router CPE di comunicare con il resto del mondo, ma non aiuta il router CPE a supportare alcun client sulla LAN collegato alla sua interfaccia interna. Il router CPE necessita di un prefisso per la LAN che viene instradato attraverso questo router CPE, quindi questo viene chiamato prefisso instradato .

Il prefisso indirizzato può essere configurato staticamente o tramite DHCPv6. I dettagli esatti di come il router CPE negozia una lunghezza prefisso con il server DHCPv6 fornito dall'ISP non rientra nell'ambito di questa risposta. Una ricerca per la delega dei prefissi può dirti di più al riguardo. Supponiamo che il prefisso instradato finisca per essere 2001:db8:1::/48. Sul router ISP verrà creata una voce della tabella di routing che indica che è 2001:db8:1::/48necessario instradare attraverso il gateway 2001:db8:0:1:42:ff:fe00:42. Questa voce della tabella di routing è la caratteristica che definisce il prefisso instradato.

Il router CPE potrebbe avere più LAN interne, da /48cui può allocare un /64prefisso di collegamento a ciascuna LAN interna. Se supponiamo che una delle LAN sia stata assegnata 2001:db8:1:1::/64come prefisso di collegamento, un nodo su questo collegamento può ottenere l'indirizzo 2001:db8:1:1::42:ff:fe00:43tramite SLAAC. Quel nodo potrebbe essere un router wireless che ha bisogno di un prefisso per la sua interfaccia wireless. Il CPE potrebbe assegnare 2001:db8:1:100::/60come prefisso instradato per il router wireless e il router wireless potrebbe assegnare 2001:db8:1:100::/64come prefisso di collegamento per l'interfaccia wireless.

Ora in una tale configurazione abbiamo una gerarchia di prefissi. Di seguito sono nidificati tutti l'uno sotto l'altro:

  • 2001:db8::/32 BGP ha annunciato il prefisso
  • 2001:db8:1::/48 prefisso indirizzato
  • 2001:db8:1:100::/60 prefisso indirizzato
  • 2001:db8:1:100::/64 prefisso di collegamento

Come vengono gestiti i pacchetti?

Quando il router ISP riceve un pacchetto per il 2001:db8:0:1::/64quale è un prefisso di collegamento, esegue l'individuazione dei vicini per trovare l'indirizzo MAC dell'host all'interno di /64.

In questo modo il router ISP avrà bisogno di una voce di cache adiacente separata per ogni indirizzo IP all'interno del prefisso del collegamento.

Quando il router ISP riceve un pacchetto per il 2001:db8:1::/48quale è un prefisso instradato, esegue l'individuazione del vicino per trovare l'indirizzo MAC del gateway 2001:db8:0:1:42:ff:fe00:42.

In questo modo il router ISP necessita solo di una singola voce cache vicina per il gateway per instradare i pacchetti a qualsiasi indirizzo IP all'interno del prefisso instradato. Questa proprietà è cruciale per la scalabilità di Internet.

Risolvere la mancanza di prefisso indirizzato

A volte i clienti si ritrovano bloccati con un ISP che fornirà solo un prefisso di collegamento e nessun prefisso indirizzato. In una situazione del genere è possibile che il cliente installi un demone che risponde alla scoperta dei vicini per tutti gli indirizzi IP all'interno di una specifica gamma del prefisso del collegamento. Ciò avrà un effetto simile alla configurazione di quel prefisso come prefisso indirizzato. Ma ha diversi inconvenienti:

  • In generale, si suppone che i prefissi indirizzati siano più brevi di /64, ma il demone che risponde alle richieste di rilevamento vicine può solo creare un prefisso "instradato" che è più lungo di /64.
  • Aumenta leggermente la latenza a causa di un roundtrip aggiuntivo ogni volta che un indirizzo IP non si trova nella cache vicina sul router ISP.
  • Aumenta il carico sul router ISP a causa della necessità di una scoperta del vicino molto più frequente. È molto probabile che il router ISP possa inoltrare i pacchetti a un prefisso di destinazione già noto esclusivamente nell'hardware, ma la scoperta dei vicini verrà eseguita nel software.
  • Aumenta il consumo di memoria sul router ISP. Se l'ISP assegna un prefisso indirizzato a ciascun cliente, può facilmente cavarsela con una sola voce cache vicina per cliente. Ma con il demone risponditore vicino questo potrebbe trasformarsi in migliaia di voci per cliente.

L'overhead di elaborazione sul router ISP può essere un problema significativo. Alcuni router sono stati così male a gestire un flusso di pacchetti che necessitano prossimo scoperta che si è trasformato in un vero e attacchi DoS, e l'utilizzo di prefissi di collegamento più lunghe (in /120- 127gamma) è stato usato come soluzione per questo tipo di attacchi DoS.

Anche se il router non è vulnerabile all'attacco DoS, la memoria necessaria per le voci della cache vicine quando viene utilizzata la soluzione alternativa sopra descritta è molto più costosa per l'ISP rispetto agli indirizzi IP per un prefisso instradato, quindi ci sono poche ragioni per un ISP di rifiutare la distribuzione di un prefisso indirizzato.

Casi speciali relativi ai collegamenti punto-punto

Sui collegamenti punto-punto (come tunnel 6in4 e collegamenti PPP) non è necessario scoprire i vicini. Esiste solo una direzione per inviare un pacchetto su tale collegamento e non è necessario cercare alcun indirizzo hardware prima di inviare il pacchetto.

Ciò significa che il sovraccarico della scoperta del vicino non è un problema su tale collegamento. Pertanto, avere un'estremità di un collegamento punto a punto utilizza molti indirizzi non è un problema, purché gli endpoint abbiano un accordo su chi utilizza quali indirizzi. La mancanza della scoperta del vicino significa che non esiste nemmeno un rilevamento dell'indirizzo duplicato, quindi entrambi gli endpoint dovrebbero provare a utilizzare lo stesso indirizzo che non funzionerà come previsto (a meno che non ti aspetti che si comporti come un indirizzo anycast).

C'è un avvertimento da tenere a mente per i collegamenti punto a punto. Ciascun endpoint supporrà che tutti gli indirizzi sul collegamento a cui non è assegnato stesso siano assegnati all'altra estremità. Ciò significa che gli indirizzi non utilizzati su un collegamento punto a punto sono inclini a innescare un ciclo di routing. Tale ciclo di routing (e molti altri casi di loop di routing) può essere evitato da un endpoint che non invia mai un pacchetto direttamente al nodo da cui è stato ricevuto. Quindi un pacchetto ricevuto da un collegamento punto a punto non deve essere rinviato sullo stesso collegamento punto a punto, fintanto che un endpoint ha ragione, il ciclo di routing viene interrotto. Come nodo laterale su Ethernet è valido ricevere un pacchetto e inoltrarlo nuovamente allo stesso collegamento, ma è una buona idea evitare di farlo se fosse inoltrato allo stesso indirizzo MAC da dove è stato ricevuto.

Poiché la maggior parte degli indirizzi su un collegamento punto a punto verranno semplicemente inoltrati all'altra estremità del collegamento senza necessità di rilevamento del vicino, sembra molto simile a un prefisso indirizzato. Ad esempio, se l'ISP ha assegnato 2001: db8: 42 :: / 64 a un collegamento punto a punto con gli endpoint assegnati indirizzi 2001: db8: 42 :: 1 e 2001: db8: 42 :: 2, quindi i pacchetti alla maggior parte degli indirizzi nel 2001: db8: 42 :: / 64 verrà inoltrato dall'ISP al cliente esattamente come farebbe se questo fosse un prefisso indirizzato usando 2001: db8: 42 :: 2 come gateway.

Ciò significa che un certo hack è possibile. Sul CPE è possibile configurare effettivamente 2001: db8: 42 :: / 64 come prefisso di collegamento sulla LAN. Affinché il CPE sappia su quale dei due collegamenti è attiva una determinata destinazione, la configurazione effettiva sul collegamento punto a punto verso l'ISP dovrebbe quindi essere modificata in 2001: db8: 42 :: / 126. Funzionerà tutto con un'eccezione minore, gli host sulla LAN non possono comunicare con i quattro indirizzi IP nel 2001: db8: 42 :: / 126. Dal momento che probabilmente non avevano bisogno di comunicare con quelli comunque, questo non è un grosso problema. Tuttavia non è consigliabile utilizzare questo hack, la configurazione corretta è quella di ottenere un prefisso indirizzato dall'ISP.

Un altro trucco per salvare gli indirizzi consiste nell'allocare solo gli indirizzi globali per un prefisso indirizzato e utilizzare gli indirizzi RFC 4193 per il collegamento punto a punto. Questo è comunque un trucco sciocco poiché introduce ancora alcuni inconvenienti al fine di risolvere un problema inesistente.

È anche possibile non assegnare alcun prefisso a un collegamento punto a punto. Fino a quando ciascun endpoint ha un'altra interfaccia su cui ha un indirizzo globale, possono utilizzare l'indirizzo assegnato all'altra interfaccia quando comunicano sul collegamento punto a punto. Non conosco alcun inconveniente di questo approccio, quindi se scopri che questo approccio ai collegamenti punto a punto semplifica la configurazione della tua rete, sentiti libero di usarlo, ma non usarlo come misura per salvare gli indirizzi.

Usa casi per un prefisso indirizzato

  • Il routing gerarchico come nel mio primo esempio è quello per cui sono progettati i prefissi indirizzati.
  • VPN / tunnel aggiungono un altro livello nella gerarchia dei router che necessitano di prefissi. Sebbene siano hardware virtuale piuttosto che reale, non sono diversi in termini di indirizzamento e hanno bisogno di un prefisso indirizzato proprio come farebbe un collegamento fisico.
  • Assegnazione di molti indirizzi a un host . Esistono casi d'uso per assegnare molti indirizzi a un singolo host. Per alcuni indirizzi possono semplicemente essere assegnati e gestiti con il rilevamento dei vicini per ciascuno e quante voci di cache quanti sono gli indirizzi. Ma se sono necessari migliaia di indirizzi, un prefisso indirizzato è migliore.

Un esempio più dettagliato dell'ultimo punto sarebbe costituito dai ricursori DNS. Dal momento che non vedo DNSSEC ottenere molta trazione fino a quando non abbiamo finito di combattere con IPv4, sono necessarie altre misure contro l'avvelenamento da DNS. È stato fatto uno sforzo per ottenere quanta più entropia possibile nelle query. L'ID e il numero di porta possono contenere al massimo 32 bit di entropia, altri pochi bit possono essere conservati nella richiesta se le lettere maiuscole e minuscole vengono miscelate nel nome di dominio da risolvere. Raramente arriverai a più di 48 bit in questo modo. Assegnare un pieno /64al ricursore DNS consentirebbe di aumentare l'entropia di 64 bit in una volta, il che è più di tutti gli altri sforzi combinati.


Mi sarei collegato a un Q / A su CIDR se avessi potuto trovarne uno buono. Bisogna assolutamente capire il CIDR prima di leggere questa risposta.
Kasperd,

Per CIDR l'articolo di Wikipedia mi sembra a posto, secondo me un link a en.wikipedia.org/wiki/Classless_Inter-Domain_Routing è utile per un'ulteriore comprensione.
Erik,

Ho dei problemi con la tua risposta. Non coprono il comportamento osservato, non per il mio ISP a casa e non per il provider di hosting sul mio server (entrambi non usano la classica scoperta del vicino). Penso di aver bisogno di una descrizione più dettagliata dell'ambito principale del mio domanda. Devo aggiornare la mia domanda o esistere in un altro modo preferito? Siamo spiacenti, sono nuovo su serverfault.com / StackExchange.
Erik,

Sono confuso sulla situazione in cui parli. Intendi un ISP (ad esempio su una linea DSL) per una connessione Internet per casa privata o intendi un provider di hosting che collega i server (con una vera LAN basata su Ethernet)?
Erik,

1
@ 1'OR1-- Se un pacchetto verso un indirizzo inutilizzato all'interno dei /48risultati si traduce in un pacchetto di sollecitazione adiacente per l'IP di destinazione, allora sembra davvero che il provider abbia configurato il /48prefisso di collegamento. La configurazione di un /48prefisso di collegamento non è una configurazione consigliata, ma ho sentito parlare comunque di provider. Se si trattava di un prefisso indirizzato, indipendentemente dall'indirizzo IP all'interno di /48un pacchetto a cui era destinato, la sollecitazione adiacente che vedresti sarebbe ogni volta per lo stesso indirizzo IP. E una volta che hai risposto a questo, non vedresti più la sollecitazione del vicino.
Kasperd,

3

Un prefisso di collegamento viene utilizzato tra il router e l'ISP.

Il prefisso instradato viene utilizzato all'interno della rete.

Se ricevi un prefisso / 64 instradato dal tuo ISP, allora il tuo router dovrebbe semplicemente pubblicizzare quel prefisso sulla tua LAN. Se hai un prefisso più piccolo di / 64 (forse un / 48?) Dovresti considerare come eseguire la sottorete di quel prefisso in modo logico, per essere usato da tutti i tuoi router nella tua organizzazione.

In Wireshark, a seconda di dove si acquisiscono i pacchetti, è possibile che venga utilizzato solo il prefisso instradato (se si acquisisce sulla LAN) oppure si possono vedere entrambi i prefissi utilizzati (se si acquisisce sulla WAN).

Per quanto riguarda il Neighbor Discovery Protocol, dipende anche dal collegamento. Sul collegamento tra l'ISP e il router, NDP viene utilizzato per rilevare l'indirizzo MAC dell'interfaccia WAN del router e l'indirizzo MAC del router upstream dell'ISP. Nell'interfaccia LAN, NDP viene utilizzato per rilevare l'indirizzo MAC degli host sul segmento LAN.

Spero che sia di aiuto.


1
If you received a /64 from your ISP, then you would simply have your router advertise that prefix on your LANProbabilmente sarebbe meno probabile che la frase venisse fraintesa se la rendessi esplicita /64facendo riferimento al prefisso indirizzato.
Kasperd,

2

Un prefisso è un prefisso instradato se i pacchetti per quel prefisso devono passare attraverso un router per raggiungere la loro destinazione. Un prefisso è un prefisso di collegamento se si trova su un segmento a cui è collegata un'interfaccia di rete locale.

Mentre un pacchetto viaggia su Internet, il / 64 a cui è destinato sarà un prefisso instradato fino a raggiungere l'ultimo hop. Quindi sarà un prefisso di collegamento.

I prefissi indirizzati sono generalmente aggregati. Molti / 64 possono essere aggregati in un singolo prefisso più corto per ridurre le dimensioni delle tabelle di routing. Sul confine tra i provider di servizi Internet è comune applicare una lunghezza massima del prefisso di / 48.

Se un prefisso è compreso tra / 0 e / 63, di solito si può presumere che sia un prefisso indirizzato. Se il prefisso è / 64, sono necessarie ulteriori informazioni per sapere se si tratta di un prefisso indirizzato o di collegamento.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.