IPv6 nativo e DHCPv6-PD con Cisco IOS: una piccola storia di successo

Ciao a tutti

Sono stato per molti anni un 6RD utente presso Swisscom, anzi dall’inizio nel 2011. Sempre con router Cisco della serie 800, da ultimo un C891-24X (con 24 porte switch) e un C892SFP upstream con G.Fast SFP come un bridge (perché l’SFP G.fast del C891 non ne aveva proprio voglia.

Purtroppo la CPU piuttosto sottile del C891-24X non permetteva molto più di 200 Mbit/s con IPv4 (con Zone Based Firewall e con - o soprattutto a causa del NAT), e solo circa 120 Mbit/s con IPv6 con 6RD . Il tunneling/incapsulamento e la costante necessità di riscrivere o ricreare le intestazioni IP probabilmente hanno il loro prezzo. Quindi parte del potenziale della connessione 300/100 è rimasto inutilizzato.

Ogni pochi mesi eseguivo il motore di ricerca meno sospetto per “Swissom IPv6 nativo” o “Swisscom DHCPv6 PD” e soprattutto trovavo sempre vecchi post di questa comunità - ma niente di nuovo. Poi, qualche giorno fa, questo risultato è apparso qui:

https://www.swisscom.ch/de/business/wholesale/ueberwholesale/aktuelles/dualstackipv6.html

Swisscom presenta attualmente alla BBCS l’approccio Dual Stack per IPv6. Dall’inizio del 2022 è possibile attivare il dual stack IPv4/v6 secondo BBCS Anschluss.

Sì… se funziona per i clienti BBCS (anche il mio Arbeitgeber è uno di quelli) - possono farlo anche i clienti finali Swisscom? Dovresti provarlo, forse funzionerà.

Dopo che la ricerca nella Swisscom Community non ha dato risultati… Provare rende intelligenti!

imposta rapidamente lo spegnimento della vecchia interfaccia “Tunnel 6” utilizzata per 6RD e aggiungi l’interfaccia WAN (gig0/0) con la configurazione IPv6:

interfaccia GigabitEthernet0/0
 descrizione * Collegamento al Bridge DSL *
!
! solo le normali cose IPv4
!
 nessun nome di dominio richiesto dal client DHCP ip
 nessuna richiesta client DHCP ip server dei nomi DNS
 ip DHCP client ID-client GigabitEthernet0/0
 ID classe client DHCP ip 100008,0001
 ip nome host del client DHCP MYROUTER
 indirizzo IP DHCP
 nessun proxy IP arp
 ip nat fuori
!
! e ora novità per IPv6 (in 6RD l'interfaccia "esterna" non ne aveva una
! elementi di configurazione per IPv6)
!
 abilitare ipv6
 percorso predefinito ipv6 e configurazione automatica
 ipv6 tcp adjustment-mss 1440 <- in realtà non è più necessario
!
!
! e poi il nocciolo della questione: ci otteniamo come client DHCPv6-PD
! Prefisso e assegnagli un nome
!
 client DHCP ipv6 pd Commit rapido DHCPv6-SWISSCOM
!
! È necessario un po' di firewall:
!
 sicurezza dei membri della zona Z-INTERNET
!
FINE

Poco dopo accadde questo:

swouter6rd# mostra l'interfaccia DHCP ipv6
...
GigabitEthernet0/0 è in modalità client
  Lo stato del prefisso è APERTO
  Il rinnovo verrà inviato alle 00:19:09
  Lo stato dell'indirizzo è IDLE
  Elenco dei server conosciuti:
    Raggiungibile tramite indirizzo: FE80::200:5EFF:FE00:10B
    DUID: FE80000000000000002005EFFFE00010B
    Preferenza: 0
    Parametri di configurazione:
      PD IA: ID IA 0x001C0001, T1 3600, T2 5760
        Prefisso: 2A02:1210:865C:6F00::/56 <---- bang, eccolo!
                durata preferita 7200, durata valida 21600
                scade il 07 aprile 2022 02:52 (19150 secondi)
      Tempo di aggiornamento delle informazioni: 0
   Nome del prefisso: DHCPv6-SWISSCOM
   Prefisso commit rapido: abilitato
   Indirizzo commit rapido: disabled
...

È stata immediatamente aggiunta la prima di numerose interfacce lato LAN:

interfaccia Vlan50
 desc * Tecnologia VLAN *
!
! solo le normali cose IPv4
!
 indirizzo IP qualcosa.rfc.1918.1 255.255.255.0
 nessun reindirizzamento IP
 nessun proxy IP arp
 ip nat dentro
!
! e prendiamo una sottorete (qui: 50) dal prefisso assegnato
! nonché una sottorete del nostro interno /48 secondo RFC 4193
!
 indirizzo ipv6 ULA-MEINNETZ::50:0:0:0:1/64
 indirizzo ipv6 DHCPv6-SWISSCOM::50:0:0:0:1/64
 abilitare ipv6
!
!
! e distribuiamo alcune informazioni aggiuntive, ad es. i nostri server DNS (2x Pi-Holes)
!
 ipv6 e other-config-flag
 ipv6 nd ra server DNS FDnn:nnnn:nnnn:41::25:53
 server ipv6 nd ra DNS FDnn:nnnn:nnnn:41::26:53
 nessun reindirizzamento IPv6
!
!
! e anche qui: un po' di firewall basato sulla zona è d'obbligo:
!
 sicurezza dei membri della zona Z-INSIDE
!
FINE

E cosa ti dico?

IPv4 con NAT e ZBFW: ancora intorno ai 200Mbit/s
IPv6 senza 6RD, con ZBFW: 275Mbit/s

Bene, per favore, vai! Orgoglioso da morire! 😉

Saluto

Marc

Mostra lingua originale (Tedesco)

Lo tralascerei o lo adatterei anche al 1460

I valori per il bloccaggio MSS devono…

  • IPv4 40byte più piccolo dell’MTU
    (intestazione IPv4 da 20 byte, intestazione TCP da 20 byte, lasciando 1460 byte per il payload)
  • IPv6 60byte essere più piccolo della MTU:
    (intestazione IPv6 da 40 byte, intestazione TCP da 20 byte, lasciando 1440 byte per il payload)

Il valore di riferimento è, ovviamente, la MTU del collegamento in uscita. Oggi su una normale Ethernet di solito 1500 byte: spesso sufficienti ma anche meno, soprattutto quando entrano in gioco i tunnel [1], solo molto raramente sono di più.

Consideriamo due casi:

A) Il caso generale: LAN locale con MTU 1500, Internet/uplink con MTU 1500

Con IPv4 gli altoparlanti TCP iniziano con MSS 1460 nelle opzioni TCP. Il blocco MSS per ipv4 con “ip tcp adjustment-mss 1460” sarebbe semplicemente in linea e non manipolerebbe mai le intestazioni TCP.

Con IPv6 gli altoparlanti TCP iniziano con MSS 1440 nelle opzioni TCP. Il blocco MSS per ipv6 con “ipv6 tcp adjustment-mss 1460” sarebbe un valore troppo alto e non interverrebbe.

B) Caso speciale LAN locale con MTU 9000 (jumbo frame), Internet/uplink con MTU 1500

Con IPv4 gli altoparlanti TCP iniziano con MSS 8960 nelle opzioni TCP. Il clamping MSS per ipv4 con “ip tcp adjustment-mss 1460” sarebbe urgentemente necessario affinché i collegamenti TCP “volino” sull’uplink. Non vuoi fare affidamento sulla scoperta PathMTU per IPv4.

Con IPv6 gli altoparlanti TCP iniziano con MSS 8940 nelle opzioni TCP. Il blocco MSS per ipv6 con “ipv6 tcp adjustment-mss 1460” MSS sarebbe decisamente sbagliato. Mentre SYN e SYN-ACK riuscirebbero comunque a passare, i primi pacchetti “seri” delle connessioni TCP sarebbero irrimediabilmente troppo grandi e, se possibile, dovrebbero essere frammentati.

Tuttavia, un router non è consentito/non può frammentarsi con IPv6, quindi invierà agli host mittente un messaggio ICMPv6 Type 2 Code 0 (Packet Too Big), con la nota che la WAN MTU del collegamento in uscita è solo 1500. Questo deve poi essere ricevuto ed elaborato correttamente dall’host.

Corto:
Con un uplink con MTU 1500 e un MTU locale >1500, il clamping MSS a 1440 per IPv6 e 1460 per IPv4 ha senso. 1460, d’altra parte, non si adatta mai veramente a IPv6.

Saluto

Marc

[1] alcuni esempi di collegamenti con MTU inferiore (a partire dagli onnipresenti 1500 byte)
PPPoE (8): MTU 1492

Tunnel GRE (24): MTU 1476
6RD Tunnel (20): MTU 1480
Tunnel 6RD tramite PPPoE: MTU 1472 (i relè di frontiera Swisscom 6RD lo hanno come MTU sui tunnel 6RD)
Tunnel IPSec site-to-site senza NAT-T (ca. 62, a seconda del dialetto IPsec): MTU 1438
Tunnel IPSec site-to-site con NAT-T (ca. 70, a seconda del dialetto IPsec): MTU 1428

GRE su tunnel IPSec da sito a sito (circa 100, a seconda del dialetto IPsec): MTU 1400

Questi sono tutti i casi in cui puoi semplificarti la vita con il corretto serraggio MSS.

Mostra lingua originale (Tedesco)