Native IPv6 and DHCPv6-PD mit Cisco IOS - eine kleine Erfolgsgeschichte

netztier

Hallo zusammen

Lange Jahre war ich 6RD-Nutzer bei Swisscom, eigentlich seit den Anfängen in 2011. Stets mit Cisco-Routern der 800er-Serie, zuletzt ein C891-24X (mit 24 Switchports) und einem vorgeschalteten C892SFP-mit-G.Fast-SFP-als-Bridge (weil das G.fast-SFP im C891 nicht so recht wollte.

Die doch eher schmächtige CPU des C891-24X liess leider nicht viel mehr als 200 Mbit/s bei IPv4 zu (mit Zone Based FIrewall und mit - bzw. vor allem wegen dem NAT), und nur ca 120Mbit/s bei IPv6 mit 6RD. Tunnelling/Enkapsulation und das dabei dauernd nötige Umschreiben bzw Neu-Erstellen von IP-Headern fordern wohl ihren Tribut. So blieb halt etwas von dem Potential des 300/100-Anschlusses nicht ausgeschöpft.

Alle paar Monate liess ich die Suchmaschine des geringsten Misstrauens nach “Swissom IPv6 native” oder “Swisscom DHCPv6 PD” suchen, und fand vor allem immer wieder alte Posts aus dieser Community - aber nichts Neues. Dann, vor ein paar Tagen, tauchte dieses Resultat hier auf:

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

Swisscom führt bei BBCS aktuell den Dualstack Ansatz für IPv6 ein. Ab Anfang 2022 kann Dualstack IPv4/v6 pro BBCS Anschluss aktiviert werden.

Ja… wenn’s für die BBCS-Kunden geht (mein Arbeitgeber ist auch so einer) - können es dann Swisscom-Endkunden auch? Das müssten man mal probieren, vielleicht klappt es ja.

Nachdem die Suche in der Swisscom Community nichts hergeben wollte… Versuch macht klug!

schnell das alte für 6RD benutzte “Tunnel 6” Interface auf shutdown gesetzt, und das WAN-Interface (gig0/0) mit IPv6-Konfig ergänzt:

interface GigabitEthernet0/0
 description * Link to DSL Bridge *
!
! halt das normale IPv4-Zeug
!
 no ip dhcp client request domain-name
 no ip dhcp client request dns-nameserver
 ip dhcp client client-id GigabitEthernet0/0
 ip dhcp client class-id 100008,0001
 ip dhcp client hostname MEINROUTER
 ip address dhcp
 no ip proxy-arp
 ip nat outside
!
! und jetzt neu für IPv6 (bei 6RD hatte das "outside" Interface keine
! konfigurations-Stücke für IPv6)
!
 ipv6 enable
 ipv6 nd autoconfig default-route
 ipv6 tcp adjust-mss 1440 <-- braucht's eigentlich auch nicht mehr
!
!
! und dann das Kernstück - wir holen uns als DHCPv6-PD client ein
! Prefix und geben ihm einen Namen
!
 ipv6 dhcp client pd DHCPv6-SWISSCOM rapid-commit
!
! ein bisschen Firewalling muss schon sein:
!
 zone-member security Z-INTERNET
!
end

Kurz darauf kam es zu dem hier:

swouter6rd# show ipv6 dhcp interface
...
GigabitEthernet0/0 is in client mode
  Prefix State is OPEN
  Renew will be sent in 00:19:09
  Address State is IDLE
  List of known servers:
    Reachable via address: FE80::200:5EFF:FE00:10B
    DUID: FE8000000000000002005EFFFE00010B
    Preference: 0
    Configuration parameters:
      IA PD: IA ID 0x001C0001, T1 3600, T2 5760
        Prefix: 2A02:1210:865C:6F00::/56                     <---- zack, da war es!
                preferred lifetime 7200, valid lifetime 21600
                expires at Apr 07 2022 02:52 AM (19150 seconds)
      Information refresh time: 0
   Prefix name: DHCPv6-SWISSCOM
   Prefix Rapid-Commit: enabled
   Address Rapid-Commit: disabled
...

Umgehend kam das erste von einigen LAN-seitigen Interfaces dran:

interface Vlan50
 desc * Technik VLAN *
!
! halt das normale IPv4-Zeug
!
 ip address etwas.rfc.1918.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 ip nat inside
!
! und wir greifen uns ein Subnet (hier: 50) aus dem zugewiesenen Prefix
! sowie ein ein Subnet aus unserem hausinternen /48 nach RFC 4193
!
 ipv6 address ULA-MEINNETZ::50:0:0:0:1/64
 ipv6 address DHCPv6-SWISSCOM::50:0:0:0:1/64
 ipv6 enable
!
!
! und wir verteilen noch ein bisschen Zusatzinfo, z.B die eigenen DNS-Server (2x Pi-Holes)
!
 ipv6 nd other-config-flag
 ipv6 nd ra dns server FDnn:nnnn:nnnn:41::25:53
 ipv6 nd ra dns server FDnn:nnnn:nnnn:41::26:53
 no ipv6 redirects
!
!
! und auch hier: bisschen zone based firewalling muss sein:
!
 zone-member security Z-INSIDE
!
end

Und was sage ich euch?

IPv4 mit NAT und ZBFW: immer noch ca 200Mbit/s
IPv6 ohne 6RD, mit ZBFW: 275Mbit/s

Na bitte geht doch! Stolz wie Bolle! 😉

Gruss

Marc

Thowaugrio27

tiptop,

wie Du schreibst

ipv6 tcp adjust-mss 1440 <– braucht’s eigentlich auch nicht mehr

würde ich auch weglassen oder auf 1460 adaptieren

netztier

würde ich auch weglassen oder auf 1460 adaptieren

Die Werte bei MSS-Clamping müssen bei…

IPv4 40bytes kleiner sein als die MTU
(20bytes IPv4-Header, 20bytes TCP-Header, lassen 1460bytes für Payload übrig)
IPv6 60bytes kleiner sein als die MTU:
(40bytes IPv6-Header, 20bytes TCP-Header, lassen 1440bytes für Payload übrig)

Bezugsgrösse ist jeweils als die MTU des ausgehenden Links, natürlich. Heute meistens 1500bytes auf einem normalen Ethernet: Oft genug aber auch weniger, besonders wenn Tunnels ins Spiel kommen [1], nur sehr selten ist es mehr.

Schauen wir zwei Fälle an:

A) Der Regelfall: lokales LAN mit MTU 1500, Internet-/Uplink mit MTU 1500

Bei IPv4 beginnen die TCP-Speaker mit MSS 1460 in den TCP-Options. MSS-Clamping für ipv4 mit “ip tcp adjust-mss 1460” wäre just auf der Linie und würde nie manipulierend in die TCP-Header eingreifen.

Bei IPv6 beginnen die TCP-Speaker mit MSS 1440 in den TCP-Options. MSS-Clamping für ipv6 mit “ipv6 tcp adjust-mss 1460” wäre ein zu hoher Wert, und würde nicht eingreifen.

B) Spezialfall, lokales LAN mit MTU 9000 (Jumbo Frames), Internet-/Uplink mit MTU 1500

Bei IPv4 beginnen die TCP-Speaker mit MSS 8960 in den TCP-Options. MSS-Clamping für ipv4 mit “ip tcp adjust-mss 1460” wäre dringend nötig, damit die TCP-Verbindungen über den Uplink “fliegen”. Man will nicht auf PathMTU-Discovery für IPv4 setzen.

Bei IPv6 beginnen die TCP-Speaker mit MSS 8940 in den TCP-Options. MSS-Clamping für ipv6 mit “ipv6 tcp adjust-mss 1460” MSS wäre nachgerade falsch. Während SYN und SYN-ACK noch durchpassen würden, wären dann die ersten “ernsthaften” Pakete der TCP-Verbindungn hoffnungslos zu gross, und müssten - wenn’s denn ginge - fragmentiert werden.

Ein Router darf/kann bei IPv6 aber nicht fragmentieren, also wird er den sendenden Hosts eine ICMPv6 Type 2 Code 0 ( Packet Too Big) Message zukommen lassen, mit dem Hinweis, dass die WAN-MTU des ausgehenden Links halt nur 1500 sei. Die muss dann durch den Host korrekt empfangen und verarbeitet werden.

Kurz:
Beinem Uplink mit MTU 1500 und einer lokalen MTU >1500 sind MSS Clamping auf 1440 für IPv6 und 1460 für IPv4 durchaus sinnvoll. 1460 hingegen passt nie wirklich zu IPv6.

Gruss

Marc

[1] ein paar Beispiele von Links mit geringerer MTU (ausgehend von den allgegenwärtigen 1500 bytes)
PPPoE (8): MTU 1492

GRE-Tunnel (24): MTU 1476
6RD-Tunnel (20): MTU 1480
6RD-Tunnel über PPPoE: MTU 1472 (das haben die Swisscom 6RD Border Relays als MTU auf den 6RD Tunneln)
IPSec-Tunnel Site-to-Site ohne NAT-T (ca 62, je nach IPsec-Dialekt): MTU 1438
IPSec-Tunnel Site-to-Site mit NAT-T (ca 70, je nach IPsec-Dialekt): MTU 1428

GRE-Over-IPSec-Tunnel Site-to-Site (ca 100, je nach IPsec-Dialekt): MTU 1400

Das sind dann alles Fälle, bei denen man sich das Leben mit korrektem MSS-Clamping leichter machen kann.