Native IPv6 and DHCPv6-PD with Cisco IOS - a small success story

Hello everyone

I was a 6RD user at Swisscom for many years, actually since the beginning in 2011. Always with Cisco routers of the 800 series, most recently a C891-24X (with 24 switch ports) and an upstream C892SFP with G.Fast SFP. as a bridge (because the G.fast SFP in the C891 didn’t really want to.

Unfortunately, the rather slender CPU of the C891-24X did not allow much more than 200 Mbit/s with IPv4 (with Zone Based Firewall and with - or especially because of the NAT), and only around 120 Mbit/s with IPv6 with 6RD. Tunneling/encapsulation and the constant need to rewrite or recreate IP headers probably take their toll. So some of the potential of the 300/100 connection remained unexploited.

Every few months I ran the least suspicious search engine for “Swissom IPv6 native” or “Swisscom DHCPv6 PD” and, above all, I kept finding old posts from this community - but nothing new. Then, a few days ago, this result showed up here:

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

Swisscom is currently introducing the dual stack approach for IPv6 at BBCS. From the beginning of 2022, dual stack IPv4/v6 can be activated per BBCS Anschluss.

Yes… if it works for BBCS customers (my Arbeitgeber is one of those too) - can Swisscom end customers do it too? You should try that, maybe it will work.

After the search in the Swisscom Community didn’t yield anything… Trying makes you smart!

quickly set the old “Tunnel 6” interface used for 6RD to shutdown, and added the WAN interface (gig0/0) with IPv6 config:

interface GigabitEthernet0/0
 description * Link to DSL Bridge *
!
! just the normal IPv4 stuff
!
 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 MYROUTER
 ip address dhcp
 no ip proxy arp
 ip nat outside
!
! and now new for IPv6 (in 6RD the "outside" interface didn't have one
! configuration pieces for IPv6)
!
 ipv6 enable
 ipv6 nd autoconfig default route
 ipv6 tcp adjust-mss 1440 <-- it's actually no longer needed
!
!
! and then the core - we get ourselves as a DHCPv6-PD client
! Prefix and give it a name
!
 ipv6 dhcp client pd DHCPv6-SWISSCOM rapid commit
!
! A bit of firewalling is necessary:
!
 zone member security Z-INTERNET
!
end

Shortly afterwards this happened:

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 <---- bang, there it was!
                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
...

The first of several LAN-side interfaces was immediately added:

interface Vlan50
 desc * Technology VLAN *
!
! just the normal IPv4 stuff
!
 ip address something.rfc.1918.1 255.255.255.0
 no IP redirects
 no ip proxy arp
 ip nat inside
!
! and we grab a subnet (here: 50) from the assigned prefix
! as well as a subnet from our in-house /48 according to RFC 4193
!
 ipv6 address ULA-MEINNETZ::50:0:0:0:1/64
 ipv6 address DHCPv6-SWISSCOM::50:0:0:0:1/64
 ipv6 enable
!
!
! and we distribute a bit of additional information, e.g. our own DNS servers (2x Pi-Holes)
!
 ipv6 and 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
!
!
! and here too: a bit of zone based firewalling is a must:
!
 zone member security Z-INSIDE
!
end

And what do I tell you?

IPv4 with NAT and ZBFW: still around 200Mbit/s
IPv6 without 6RD, with ZBFW: 275Mbit/s

Well please go! Proud as hell! 😉

Greeting

Marc

Show original language (German)

I would also leave it out or adapt it to 1460

The values ​​for MSS clamping must…

  • IPv4 40bytes smaller than the MTU
    (20bytes IPv4 header, 20bytes TCP header, leaving 1460bytes for payload)
  • IPv6 60bytes be smaller than the MTU:
    (40bytes IPv6 header, 20bytes TCP header, leaving 1440bytes for payload)

The reference value is, of course, the MTU of the outgoing link. Today usually 1500 bytes on a normal Ethernet: often enough but also less, especially when tunnels come into play [1], only very rarely is it more.

Let’s look at two cases:

A) The general case: local LAN with MTU 1500, Internet/uplink with MTU 1500

With IPv4, the TCP speakers start with MSS 1460 in the TCP options. MSS clamping for ipv4 with “ip tcp adjust-mss 1460” would be just on the line and would never manipulate the TCP headers.

With IPv6, the TCP speakers start with MSS 1440 in the TCP options. MSS clamping for ipv6 with “ipv6 tcp adjust-mss 1460” would be too high a value and would not intervene.

B) Special case, local LAN with MTU 9000 (jumbo frames), Internet/uplink with MTU 1500

With IPv4, the TCP speakers start with MSS 8960 in the TCP options. MSS clamping for ipv4 with “ip tcp adjust-mss 1460” would be urgently needed so that the TCP connections “fly” over the uplink. You don’t want to rely on PathMTU discovery for IPv4.

With IPv6, the TCP speakers start with MSS 8940 in the TCP options. MSS clamping for ipv6 with “ipv6 tcp adjust-mss 1460” MSS would be downright wrong. While SYN and SYN-ACK would still fit through, the first “serious” packets of the TCP connections would be hopelessly too large and would - if possible - have to be fragmented.

However, a router is not allowed/cannot fragment with IPv6, so it will send the sending hosts an ICMPv6 Type 2 Code 0 (Packet Too Big) message, with the note that the WAN MTU of the outgoing link is only 1500. This must then be received and processed correctly by the host.

Short:
With an uplink with MTU 1500 and a local MTU >1500, MSS clamping to 1440 for IPv6 and 1460 for IPv4 makes sense. 1460, on the other hand, never really fits IPv6.

Greeting

Marc

[1] a few examples of links with lower MTU (starting from the ubiquitous 1500 bytes)
PPPoE (8): MTU 1492

GRE Tunnel (24): MTU 1476
6RD Tunnel (20): MTU 1480
6RD tunnel via PPPoE: MTU 1472 (the Swisscom 6RD border relays have this as MTU on the 6RD tunnels)
IPSec tunnel site-to-site without NAT-T (approx. 62, depending on the IPsec dialect): MTU 1438
IPSec tunnel site-to-site with NAT-T (approx. 70, depending on the IPsec dialect): MTU 1428

GRE over IPSec tunnel site-to-site (approx. 100, depending on the IPsec dialect): MTU 1400

These are all cases where you can make your life easier with correct MSS clamping.

Show original language (German)