Mine (RB5009) still seems to be working fine.

BlackHand:

 

Mine (RB5009) still seems to be working fine.

 

Hi BlackHand,

Do you have a static v6 range? 

Nick.

Nope

Hi All,

I managed to get it work with some help from friends (thanks) and a bit of trial and error.

Here’s some screenshots that should be useful to those who have migrated to the Vocus stack from old 2degrees/Snap (or for new customers) that have a IPV6/56 static pool. My router is a Mikrotik RB5009UG+S+.

In the Winbox configuration application.

IPv6/Addresses

IPv6/DHCP Client

IPV6/Settings

We use their gear at the ISP I work for and a lot of clients use it as well.

I have all Mikrotik here.

Everything with IPv6 is working.

If you are running the latest stable release 7.19.3 you can also turn on IPv6 Fast Track which should make it on par with IPv4 now.

Also be aware with IPv6 you will need to manually set your MTU under neighbour discovery if its not 1500.

MichaelNZ:

 

If you are running the latest stable release 7.19.3 you can also turn on IPv6 Fast Track which should make it on par with IPv4 now.

 

A bit OT but what do you mean "on par with IPv4 now"?

freitasm:

 

A bit OT but what do you mean "on par with IPv4 now"?

 

Prior to 7.18 Fast Track was an IPv4 only feature.

I see in the above images the OP has enabled it.

Possibly related to some network rearrangements by Vocus ?

I have static IPv4 and IPv6 addresses as I am running NTP servers in the public pool and while the IPv4 address came back by itself, the IPv6 didn't and I had to reboot my router. (an opnsense firewall) Twice.

MichaelNZ:

 

Also be aware with IPv6 you will need to manually set your MTU under neighbour discovery if its not 1500.

 

BlackHand:

Sorry noob question; just making sure my settings are optimal, do you mean setting the MTU like this? Shouldn't it be 1508 for PPP? 

 

You will need to ask your ISP.

1508 is a non-standard number but may work if its supported at the other end.

1500 is the standard for non-PPP encapsulated traffic. PPP has an overhead of 8 bytes so 1500 - 8 = 1492.

Other option is see if they support DHCP address assignment. Then its a fairly safe bet the number will be 1500.

However, for IPv6 ND (neighbour discovery) purposes you need to set this at the value after allowing PPPoE. So even if you set the interface at 1508 and got a effective 1500, you would need to set ND at 1500. In other words the same as your IPv4 MTU.

MichaelNZ:

 

BlackHand:

Sorry noob question; just making sure my settings are optimal, do you mean setting the MTU like this? Shouldn't it be 1508 for PPP? 

 

 

You will need to ask your ISP.

 

1508 is a non-standard number but may work if its supported at the other end.

 

1500 is the standard for non-PPP encapsulated traffic. PPP has an overhead of 8 bytes so 1500 - 8 = 1492.

 

Other option is see if they support DHCP address assignment. Then its a fairly safe bet the number will be 1500.

 

However, for IPv6 ND (neighbour discovery) purposes you need to set this at the value after allowing PPPoE. So even if you set the interface at 1508 and got a effective 1500, you would need to set ND at 1500. In other words the same as your IPv4 MTU.

 

MichaelNZ:

 

You will need to ask your ISP.

 

1508 is a non-standard number but may work if its supported at the other end.

 

1500 is the standard for non-PPP encapsulated traffic. PPP has an overhead of 8 bytes so 1500 - 8 = 1492.

 

Other option is see if they support DHCP address assignment. Then its a fairly safe bet the number will be 1500.

 

However, for IPv6 ND (neighbour discovery) purposes you need to set this at the value after allowing PPPoE. So even if you set the interface at 1508 and got a effective 1500, you would need to set ND at 1500. In other words the same as your IPv4 MTU.

 

The 1508 MTU is now pretty standard as IPv6 is badly broken by MTU 1500 on the PPP connection.  The PPP software (client and server) has had MTU 1508 support for a very long time now.  Chorus does MTU 1508 and I think all the other fibre providers do now also.  So ISPs should all support MTU 1508 on fibre for PPP connections.  But there may still be some that do not, especially if they also do not do IPv6.  Even with IPv4, not supporting MTU 1508 with PPP will cause fragmentation of large packets which will slow the connection down a little.  And if your router does not handle fragmentation of packets in its routing hardware and has to pass the packet to the CPU to be fragmented, there can be a serious slow down.

fe31nz:

 

The 1508 MTU is now pretty standard as IPv6 is badly broken by MTU 1500 on the PPP connection.  The PPP software (client and server) has had MTU 1508 support for a very long time now.  Chorus does MTU 1508 and I think all the other fibre providers do now also.  So ISPs should all support MTU 1508 on fibre for PPP connections.  But there may still be some that do not, especially if they also do not do IPv6.  Even with IPv4, not supporting MTU 1508 with PPP will cause fragmentation of large packets which will slow the connection down a little.  And if your router does not handle fragmentation of packets in its routing hardware and has to pass the packet to the CPU to be fragmented, there can be a serious slow down.

 

You are right when you say Chorus does >1500mtu but this is not supported by all CPE.

As someone who works doing this stuff at an ISP I have to design stuff which is safe to deploy to clients. Pretty much noone cares about MTU but they do care about the consequences of getting it wrong.

In regards to the difference between 1492 and 1500 this is negligible.

But if someone wants 1500 (and that someone includes me) we have two options: DHCP or PTP.

DHCP is available for all clients but it does come with downsides. The most common example is we do not recommend it for use on marginal DSL connections. PTP is wasteful of IP addresses so we only really deploy it for ourselves and in special cases like using routing protocols.

In my experience of deploying a lot of Mikrotik gear its only broken for IPv6 by lack of configuring the MTU under neighbour discovery. And given I configure the gear before giving it to the clients its not an issue.

Is there any benefit in doing this and setting the MTU accordingly?  On my Mikrotik I've left it default (not set)

ping -6 -l 1500 facebook.com

and reduce that until you don't get failures.  the highest I can get is 1424

MichaelNZ:

 

If you are running the latest stable release 7.19.3 you can also turn on IPv6 Fast Track which should make it on par with IPv4 now.

 

When using ping command for path MTU discovery be aware of OS variations. Some treat the size variable as the data component only and others as the entire packet (data + header).

When we are talking 1500 MTU this value is including the header.

IPv6 has a fixed header size of 40 bytes so a 1500 MTU would yield a max payload (data) of 1460 bytes. If you are using ping deduct another 8 bytes for ICMPv6 so 1452 bytes.

Also be sure to use the "do not fragment" switch.