We have been happily using IPv6 over PPPoE but note that this was removed/disabled in ROS 3.18
Is there a timescale for when this will be reinstated ?
Thanks
Nick.
I’ll second that question - I raised a bug report yesterday when a perfectly working IPv6/PPPoE configuration failed to operate at all after an upgrade to 3.20.
Nick.
If you want to transport IPv6 traffic over a tunnel, then the only option is 6to4 tunnels
That’s not a particularly helpful answer - especially since it used to work and appears to have been deliberately broken. It’s also not helpful if one’s Internet connection is delivered over a PPPoE connection. Perhaps it would be helpful if you explained why this feature is no longer available and why it cannot be enabled with a ‘I want this feature’ switch.
In the mean time, as far as I am concerned, the only option is not to use 6to4 tunnels, but to revert to ROS 3.17.
Nick.
I understand the only current option from 3.18 onwards is 6to4 tunnels
I want to know when we will be able to use native IPv6 over PPPoE, as this is what our ISP provides and is a clean solution.
It was working up to 3.17 and then someone took it away.
Surely it must be possible for the PPPoE tunnel to know the IP6CP has been negotiated and then to allow IPv6 to pass over the PPPoE rether than just not allowing it at all. (after all it used to work)
Nick.
If it was working for you, it doesn’ t mean that it was working correctly in all cases.
IPv6 can’t be transported over ppp, it requires new implementation which will not be added in near future.
Sure you can revert to v3.17, but when eventually some problems will occur then do not complain, you have been warned. 
Are you stating that your implementation of PPP is broken/buggy and that you are not prepared to investigate/fix? If so, this has very serious implications for our use of ROS/RBs in future.
I appreciate that electronic communications are sometimes unintentionally confrontational, so perhaps this is something we could discuss face to face in Prague over the next couple of days?
Nick.
hello there
I think this thread finally explains the problems I also have been having here in the UK with my IP V6 configuration over PPPoE since upgrading to version 3.20. Everything was working just fine with 3.17, and I have spent a morning trying to work out why my IP six connectivity failed!
Having now read the release notes in more detail, it seems that this feature has actually been removed! I have had to resort to a 6-4 tunnel in order to restore my IPv6 connectivity. this is not an ideal situation, especially since our Internet provider is one of the few to support native IP V6.
it would be really helpful if you could provide some details on why these changes have had to be made, and your approximate date for resolution.
Best regards
Tim Robinson
To update:
Well, I did try, but sadly this didn’t happen.
I have received the following response from Mikrotik:
Which seems to say to me “Our product has a bug in it we’re not prepared to fix”, and “we’ve disabled the feature because some other people’s products have bugs in them.”
In the first case, please can you categorically state that your PPP code is buggy and that you are not prepared to fix it?
In the second case, none of my clients have this problem, my ISP doesn’t have this problem, so why can’t I use this feature? At least disable it by default and give me an option to enable it if I want to.
Given the number of people at MUM who were talking about PPPoE connections, it seems to me that Mikrotik will disenfranchise an awful lot of people who would like to move to IPv6.
Nick.
no, it’s like this
- it was a bug that it was working, because it’s not supposed to work over IPv6. We fixed the bug, so it doesn’t work anymore, as it should be
so, what’s replacement of PPPoE for IPv6? =)
That explains it. We are not using IPv6 ‘yet’ but do use PPPoE. Is there any time frame for PPPoE server to work with IPv6? Year from now? IPv6 is the future. Hopefully a good long ways off but there is no way around it.
Matt
WOW its not often that something working is described as a bug !
Lets just get this clear
in version 3.17 I can configure up PPPoE client, with my DSL router in bridge mode.
I can then login to my ISP and it automatically negotiates both IPv4 and IPv6 - yes it all works - even IPV6CP
I can then route IPv6 over the connection.
From 3.18 you removed this facility, so why was it removed ? and when can we have it back ?
Nick.
I specifically ran into the bug they were talking about. There may have been many others I’m sure. In my specific case L2TP encryption no longer worked, even without using IPv6 across it. Simply adding the IPv6 package broke L2TP encryption.
Prior to where we are at today there was no RFC or standard for IPv6 over PPP lines. I show RFC2742 has been updated, http://tools.ietf.org/html/draft-ietf-ipv6-over-ppp-v2-03 or http://tools.ietf.org/html/rfc5072. This talks about IPv6 over PPP. Microsoft has also just implemented this in their newer OS, per their statement below:
“For native IPv6 traffic, the VPN client, server, or router sends IPv6
packets across the VPN connection without the initial IPv4 encapsulation.
This works for intranets that have native IPv6 connectivity and requires
that the VPN clients, servers, and routers support the IPv6 Control Protocol
(IPV6CP), RFC 2472, which defines how IPv6 nodes negotiate IPv6
configuration options for Point-to-Point Protocol (PPP)-based connections.
Windows Vista and Windows Server 2008 support IPV6CP while Windows XP and
Windows Server 2003 do not. Figure 4 shows the general packet structure for
VPN traffic when sending a native IPv6 packet using a VPN connection across
the IPv4 Internet.” … http://technet.microsoft.com/en-us/magazine/2007.07.cableguy.aspx
I am sure that if there is an RFC that it will get implemented soon… I really need it.
Sam
IPv6 over PPP is defined in RFC2023 originally.
And that’s dated October 1996.
Bump
Looks like I’ll have to continue exploiting the bug in v3.17 for IPv6 over pppoe too until either the option/(bug) is re-introduced in newer versions or I find alternative equipment.
Bump
Bump
Bump