Roadmap for IPv6?

charliebrown · Tue Aug 24, 2010 2:47 am

Seems to be a few questions and few key features of IPv6 floating around. Would anyone from Mikrotik care to comment on a roadmap for v6 and what features are expected to make it into what version of ROS?

From the wiki all access to the router is v4 only currently (SSH/API/Winbox/etc) along with alot of tools like bandwidth test, torch, queues and some key things like MPLS which MT is pushing quite hard for us to use on links in order to get the best out of them. Transition technology is somethings thats been raised in another thread, Does MT have any plans to implement any of them and which one(s) is MT going to push?

There is alot of talk about the new wireless tech in ROS 5 but almost no talk about the extensions to v6 in ROS 5, This time next year if we haven't run out already we will be down to the last 1 or 2 /8's left for IANA to hand out, As ISP's with any foresight are starting to layout the plans for v6 for their own networks now it the time for MT to come out and outline their own plans for v6 and give us an idea of the timeline/featureset we can expect from ROS

risnet · Thu Aug 26, 2010 5:16 am

I have to say this is something key that really needs to be done. I understand it will be improbable to apply all the features of IPV6 within the space of 6 to 12 months so a time frame of what kind of features we can expect to see when would be key to the next round of purchasing decisions my org makes. Currently I run a combination of UBNT and MT equipment, but have recently been told I need to be running a dual stack network no later than Feb next year. And currently with no DHCPv6 or PD this is an issue (this would need to work with PPPoE as well).

If there is only going to be a few months wait time, then it would be worth me just doing a patch job using some older servers as routers, but if this is going to take 6 months + then maybe I need to look at cisco again.

Its the not knowing that is really killing me at the moment......

charliebrown · Mon Aug 30, 2010 12:11 pm

I find it very disappointing that there is no MT comment on this, Ignoring v6 wont stop it from coming. Any serious ISP is planning their v6 deployment if not already in trails like us, If MT's roadmap of v6 isnt upto spec then we will have to work around this with a partner like cisco as will a many other ISP's

I've e-mailed support with a request for comment

charliebrown · Mon Aug 30, 2010 1:02 pm

Hello,

There are some principles we use when we are choosing what features to implement next. No matter if it is IPv6 feature, new wireless feature, hardware support feature or any other feature.

1) are there standards available that describe how feature should be implemented?
2) number of clients asking for specific feature.
3) number of clients willing to try out and debug new feature if necessary.

We have resources to implement only few new features at the same time. And situation at the moment is simple - new wireless protocols and features / proper multi-cpu support and load balancing over cores are features that are far more demanded by customers than IPv6 features.

Also only few customers have actual feature requests - most of others just ask "all IPv6".

Sorry, bur at this point i can't give you any time frame.

Regards,
MikroTik Support

charliebrown · Mon Aug 30, 2010 1:15 pm

I'm very disappointed in this response, Its a complete cop out. There are a number of threads asking for some advanced features and some basic ones, NAT64/DNS64 is a new one without comment. Basics like torch, bandwidth test, v6 router services like winbox and ssh.

Clients may not be demanding them now but when ISP's are no longer able to request v4 space the clients will be screaming for it and MT's v6 feature set will be young and untested and given past history buggy for the first 10-15 releases. Now I'm not asking for a "We will have X by Jan/01/2011" but an simple outline of what MT intends to include (Router access to all services over v6, All tools able to do v6, v6 pppoe, DHCPv6 etc) and what transition tech MT is looking into and *MAYBE* if they know what ROS version they are planning to put each feature into.

Like I've said a number of times, Now is the time to be upskilling into v6 for techs, Planning rollout and vendor selection for ISP's along with bringing backoffice systems upto speed and for Vendors to be outlining their v6 plans and working towards a stable v6 feature set.

Based on whats just been said to me I now have to devise a "Plan B" network design to use Cisco to deploy v6 and break a pure MT network up because MT's listening to what clients want right now without looking at what they will need in the future. Its worth noting that a high percentage of contracts with major companies and govt's are requiring pure v6 upgrades in order to secure them.

I suggest anyone else like me who's looking forward to a pure v6 world posts here and e-mails MT letting them know they want v6 now

blake · Mon Aug 30, 2010 1:30 pm

I suggest anyone else like me who's looking forward to a pure v6 world posts here and e-mails MT letting them know they want v6 now

Sure, I'd like to see better IPv6 support.

We have resources to implement only few new features at the same time. And situation at the moment is simple - new wireless protocols and features / proper multi-cpu support and load balancing over cores are features that are far more demanded by customers than IPv6 features.

Okay, so MikroTik is spread thin. I guess customers aren't purchasing enough RouterBoards to create the revenue needed to hire the developers to address these requests.

There are quite a few feature requests by customers. Some may not be in as high demand as others, but most of the requests I've seen lately are quite reasonable. What would it take to start a bounty program to implement various features? Companies regularly fund Linux/BSD developers to implement various features. Would MikroTik be open to something simliar?

charliebrown · Mon Aug 30, 2010 1:38 pm

The thing is, In my mind their v6 feature set is almost done, Router access over v6, Router tools for v6 and some protocols are even in the 5 beta now (pppoe,dhcpv6), Add in a transition tech like NAT64/DNS64 and It wouldn't take much to polish it off even if it meant that for now v6 ROS tools like bandwidth test were console only, Having to console in to do something rather than winbox it is ALOT better than having no option at all.

mrz · Mon Aug 30, 2010 2:10 pm

RouterOS has enough IPv6 features to slowly deploy IPv6 network. PPP IPv6 support is already added, stateless auto-configuration is added (can be used until statefull configuration is implemented).

Mon Aug 30, 2010 3:42 pm

NAT64 looks to me as unnecessary, incomplete feature that is not that popular (judging from my Google search).

tbh it looks like it addresses only HTTP transition - i can't see other services (like FTP) working in this.

So if you need IPv6 customers to be able to browse IPv4 HTTP pages - use a simple everyday solution --> HTTP PROXY, and don't ask MT to rip the Kernel apart.
Manually assign IPv6 Proxy address in your client browsers and allow HTTP Proxy handle IPv6-IPv4 transition

charliebrown · Mon Aug 30, 2010 4:30 pm

RouterOS has enough IPv6 features to slowly deploy IPv6 network. PPP IPv6 support is already added, stateless auto-configuration is added (can be used until statefull configuration is implemented).

Your right PPP IPv6 is back in ROS 5 beta which was taken out due to security reasons from 3.18 IIRC. As I said the feature set is almost there but its the access and tools of ROS its self which is holding back alot of our plans personally.

As for NAT64, Dont confuse it with NAT-PT, NAT64 is what google and cisco are pushing and is currently being deployed, Its in active trails with T-Mobile in the USA and a couple of UK isp's run it via Cisco's CGv6 platform. NAT64 is out there and tested, for the most part applications work right away and FTP is the most common one to fail which is corrected with ALG's

I dont think you understand what NAT64 is about, You cant simply put a proxy in place as your client browser will still get a A dns record and attempt to go V4, NAT/DNS 64 catchs this and changes it into a AAA dns record. There are currently 3 main transitional tech out there, LSN, DS-L and NAT64. LSN is large scale NAT and is only seen as a option for tiny ISP's, DS-L helps ease transition and NAT64 is the main endgame as v6 content outweighs v4 content

risnet · Mon Aug 30, 2010 4:32 pm

Hi again,

I am currently running v5 Beta 6, and your right, a lot of the iv6 features are almost there. However, Ipv6 client over PPPoE isn't working (/Doesn't exist), and as far as I can test DHCPv6 server or client (that can get a PD), doesn't exist either.

I know their have been plently of request for a working ipv6 PPPoE client (even reports that it worked as part of a bug in an older version).. so it would be interesting to know if this is still on the books, or on a roadmap.

And your right, this isnt going away.... if end users can not get an IP address, then having a router is kind of pointless. Any word from MT on a time frame for the closure of at least SOME of these issues?

Cheers,

Jake

Ozelo · Mon Aug 30, 2010 11:01 pm

Seems fairly natural to me so far. NAT64 is all that we need at the moment, so, we just need (have) this feature to wait or become more demanded than others as presented by MT support, unfortunately. As for me to say that people still didn't realize how important it is...

mrz · Tue Aug 31, 2010 11:20 am

I am currently running v5 Beta 6, and your right, a lot of the iv6 features are almost there. However, Ipv6 client over PPPoE isn't working (/Doesn't exist), and as far as I can test DHCPv6 server or client (that can get a PD), doesn't exist either.

IPv6 DHCP is not the same as you are used to. There is no need for DHCP client at all. Hosts receive RA messages and generates IPv6 address based on MAC. This is a part of IPv6 autoconfiguration features. Also according to RFC Routers are ignoring RAs and does not perform address autoconfiguration, this feature is ment only for the hosts.
DHCPv6 (server) is also just an option for statefull autoconfiguration.

With latest beta versions I don't see any problems routing IPv6 traffic over ppp tunnels. If you have any problems please describe in details.

Ozelo · Tue Aug 31, 2010 4:16 pm

Could't see anything torching a IPv6 interface?? Am I doing wrong or still not available? *bump*

mrz · Tue Aug 31, 2010 4:19 pm

torch will not see ipv6 currently, but packet sniffer will.

mrz · Tue Aug 31, 2010 4:23 pm

As I said the feature set is almost there but its the access and tools of ROS its self which is holding back alot of our plans personally.

btw you can already connect to routers link-local and global ipv6 addreses from telnet.

charliebrown · Tue Aug 31, 2010 10:46 pm

Well thats a step in the right direction, For those of us who dont like sending passwords in clear text when will SSH/API/Winbox over LL/Global v6 Address be in place?

Ozelo · Fri Sep 03, 2010 4:42 pm

With latest beta versions I don't see any problems routing IPv6 traffic over ppp tunnels. If you have any problems please describe in details.

Is there any way available on ROS to route IPv4 traffic over IPv6 tunnels? i.e. EoIPv6??

gustkiller · Fri Sep 03, 2010 5:10 pm

here we really need ipv6 simple queues, for shape ipv6 users..

bazzer · Fri Sep 03, 2010 7:14 pm

For the most part, IPv6 (running b5v6) works fine for my needs apart for one key piece within ipv6 firewall mangle. There's no action: 'mark routing'. I utilize this feature within the IPv4 to round robin packets over multiple pppoe links.
Is this mangle function going to be included at some point in the near future?

mrz · Sat Sep 04, 2010 12:24 am

For the most part, IPv6 (running b5v6) works fine for my needs apart for one key piece within ipv6 firewall mangle. There's no action: 'mark routing'. I utilize this feature within the IPv4 to round robin packets over multiple pppoe links.
Is this mangle function going to be included at some point in the near future?

At some point it will be included

charliebrown · Sat Sep 04, 2010 2:30 am

Care to put a timeframe on that? Will it be in v5 or v6? How about simple queues? And v6 access to the router? Sounds like you need to release a roadmap

omidkosari · Sat Sep 04, 2010 2:42 pm

With latest beta versions I don't see any problems routing IPv6 traffic over ppp tunnels. If you have any problems please describe in details.

Radius based ip pool/assignment . Mikrotik-Address-List radius attribute ?

Thu Sep 09, 2010 6:33 pm

I have just checked the latest 5b6 webfig and note that the IPv6 section is still not working right.

I reported this against the beta 1 iirc !

Nick.

charliebrown · Fri Sep 10, 2010 1:05 am

There's an issue RA's and Slave'ed ports that stops IPv6 autoconfig aswell thats had no official word from MT about it

xxiii · Fri Sep 10, 2010 2:57 am

In terms of specific requests, we need:

BGP recursive lookup to work correctly when link-local addresses are involved.

ipv6 pool functionality for pppoe. Specifically, I'd like the ability to say something like "here is a /56, hand out /64s from it".

omega-00 · Mon Sep 13, 2010 8:57 am

ipv6 pool functionality for pppoe. Specifically, I'd like the ability to say something like "here is a /56, hand out /64s from it".

Seconding this request, along with support for prefix delegation via DHCPv6 (both to and from a router... server and client modes so to speak).

bevhost · Mon Sep 13, 2010 3:17 pm

NAT64 looks to me as unnecessary, incomplete feature that is not that popular (judging from my Google search).

tbh it looks like it addresses only HTTP transition - i can't see other services (like FTP) working in this.

So if you need IPv6 customers to be able to browse IPv4 HTTP pages - use a simple everyday solution --> HTTP PROXY, and don't ask MT to rip the Kernel apart.
Manually assign IPv6 Proxy address in your client browsers and allow HTTP Proxy handle IPv6-IPv4 transition

HTTP Proxy isn't going to solve the POP3/IMAP/SMTP access issue for clients., however allowing clients to have a RFC 1918 (private) IPv4 address and use a Normal IPv4 NAT (NAT44) for IPv4 Access will. This is not new technology and is well tested. Clients can be dual stacked with Private IPv4 and Public IPv6. This all works now without the need for new features.

Having said that if you're a web hosting company you could use HTTP Proxy in Accelerator mode to provide IPv6 access to IPv4-Only hosts.

Mon Sep 13, 2010 3:19 pm

I have just checked the latest 5b6 webfig and note that the IPv6 section is still not working right.

I reported this against the beta 1 iirc !

Nick.

tell me the ticket number and I will check the status

Mon Sep 13, 2010 3:21 pm

I have just checked the latest 5b6 webfig and note that the IPv6 section is still not working right.

I reported this against the beta 1 iirc !

Nick.
tell me the ticket number and I will check the status

2010040166000303

Mon Sep 13, 2010 3:23 pm

OK, will check bug status. Thanks!

bevhost · Mon Sep 13, 2010 3:43 pm

IPv6 DHCP is not the same as you are used to. There is no need for DHCP client at all. Hosts receive RA messages and generates IPv6 address based on MAC. This is a part of IPv6 autoconfiguration features. Also according to RFC Routers are ignoring RAs and does not perform address autoconfiguration, this feature is meant only for the hosts.
DHCPv6 (server) is also just an option for statefull autoconfiguration.

This is true in a dual stack IPv6/IPv4 environment because the clients will receive a DNS setting from the DHCPv4 server. However once DHCPv4 is removed, the DNS must be statically set or done via DHCPv6. The RA should have a flag in which tells the client if stateless or stateful DHCP is to be used. In fact in a dual stack environment there can be conflicts between DHCPv4 and DHCPv6 settings such as DNS Search Order. I don't see much point in running stateful DHCPv6 unless you have a big network eg: many downstream routers to allocate prefixes too.

DHCPv6 Prefix Delegation is the main reason to want to use DHCPv6 as I see it. If you're an ISP with 1000's of clients, you want to be able to allocate network assignments automatically. That's is, the WAN side of the customer router requests a Prefix from the provider and then allocates subnets to each of it's internal interfaces to be used for RA's.

Currently here in Australia we only have one ISP doing IPv6 for home networks. They allocate a dymanic /64 to the PPP link and a stable /60 for the customer router to use for it's internal networks. This allows each home to have up to 16 internal /64 networks and I'd be surprised if many at all went past 2 assuming one for wired and one for wireless. Currently these customers cannot use RouterOS as their gateway as they have no way to find out what their internal allocation is as they are unable to make a DHCPv6 PD request.

I can imagine that someone who understand RouterOS scripting better than me could write a script to allocate the DHCP asignment to the internal interfaces if it were possible to do the DHCP PD request.

mrz · Mon Sep 13, 2010 3:47 pm

/ipv6 nd> add advertise-dns=yes

And DNS will be advertised to the host, in RouterOS you already can specify IPv6 DNS servers address.

janisk · Thu Sep 16, 2010 10:51 am

$ ssh admin@fe80::20c:42ff:fe72:f62b%eth3



  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 5.0rc1 (c) 1999-2010       http://www.mikrotik.com/
[admin@MikroTik] >

almost ready

charliebrown · Thu Sep 16, 2010 10:59 am

Well I have to say thats a decent step in the right direction, However my point about the roadmap still stands, Whens v6 Winbox coming? etc etc. Good on MT for getting SSHv6 running but you can save yourself alot of posts and put alot of minds at ease by mapping out what you plan to support and in which version you aim to put it in

janisk · Thu Sep 16, 2010 11:45 am

winbox includes a lot of stuff in it, while still appears to be simple.

charliebrown · Thu Sep 16, 2010 12:09 pm

I dont doubt that but v6 is a critical issue thats going to affect MT's client base that use it for more than plain old AP's and all thats been released to us right now is some basic v6 things and wishy washy hints about their plans. Its time to front up and let us know your plans, what features/options are you planning to include and in what ROS versions.

Right now 14 /8 blocks are unallocated to RIR's from IANA. APNIC alone burns thru a /8 in 3-4 months based on the past 3 years of allocations to them, Some methods show the last main /8 will be handed out in as little as 8 months and then you're left with IANA's 5 /8's that may or may not be used. Bottom line is around 11-4 months from today a ISP wont be able to get v4 space from a RIR, there may be some on the open market (Another issue, When you start selling spare /24's from your /16 the global route table will explode) but dont count on that, At that point your running NAT444 and pretty screwed.

Starting to sound like a broken record here but MT need to front up and tell us their plans with v6 are, If MT's implementation is going halfassed and feature-sparse then I'll be planning for Cisco rollout in our network. It MT keep this approach of say nothing up then I'll be doing the cisco push. It too much of a massive issue for me to risk our network

janisk · Thu Sep 16, 2010 4:13 pm

get IPv6 routes in through BGP, then in AS use OSPF-V3, set up routers to hand out IPv6 prefixes to customers with IPV6 DNS servers. and set up DNS cacher with IPv6 dns servers. Secure all that using firewall.

So what i am missing from this picture to make full dual stack now, to call it names?

charliebrown · Thu Sep 16, 2010 5:04 pm

Dual stake only works when you have v4 and v6 to hand out, mt should be preparing for a no v4 world. Giving clients v6 address is only a small part (haven't tested v6 pppoe yet) we have very few if and tolls to use with v6 in ros, btest,torch etc along with winbox.

Here's the feature set ros needs; everything we can do with v4? Make it so we can do it with v6

Don't use dual stack as a sheild to justify slowing down work and not provide us with info

bevhost · Thu Sep 16, 2010 11:01 pm

Starting to sound like a broken record here but MT need to front up and tell us their plans with v6 are, If MT's implementation is going halfassed and feature-sparse then I'll be planning for Cisco rollout in our network.

Maybe I've not read all your posts, but I'm not sure what features you'd need for your particular situation. I've seen from posts above that you've requested NAT64, is there anything else you need? Is that really a roadblock, can you not use dual stack? Are you using the MT in your core network or is it for CPE?

Speaking for our setup, all we need is IPv6 Hotspot and we're good to go.

bevhost · Thu Sep 16, 2010 11:19 pm

So which step are you at now?

bevhost · Thu Sep 16, 2010 11:27 pm

Here's the feature set ros needs; everything we can do with v4? Make it so we can do it with v6

I don't think this is helpful, yes we all want to get all the features eventually, but surely some are more urgent than others?

charliebrown · Fri Sep 17, 2010 4:08 am

Starting to sound like a broken record here but MT need to front up and tell us their plans with v6 are, If MT's implementation is going halfassed and feature-sparse then I'll be planning for Cisco rollout in our network.
Maybe I've not read all your posts, but I'm not sure what features you'd need for your particular situation. I've seen from posts above that you've requested NAT64, is there anything else you need? Is that really a roadblock, can you not use dual stack? Are you using the MT in your core network or is it for CPE?

Speaking for our setup, all we need is IPv6 Hotspot and we're good to go.

Access to routeros via all methods over v6, All RouterOs tools able to be used over v6. NAT64 is really a pipe dream considering the trouble we have to goto to get the basic's put in. Those of us who like stable networks are using 4.10/4.11 and in reality I wont touch ROS 5 till 5.6ish due to history. Right now I can run v6 to our AP's via static or bgp routing. Then I hit a wall, I have to use SIT tunnels to jump to the client router from the AP over pppoe and then staticly route this. a major time waster really.

As for where we are? Running dual stack with public v4 and v6 in a rather butchered setup due to core v6 features missing (Like v6 pppoe which was removed in 3.18 iirc due to it being a security risk or something back then) When we're out of v4 we wont be using RFC space and running Nat444, It will be the biggest support nightmare our network has ever seen, That transitional step is going to hurt alot of people.

But once again all I'm asking for from MT is a roadmap, Simple plain old roadmap saying what they want to support and when. I get really peeved off when I get responses from MT that downplay the need for v6 and avoid doing the work due to clients not asking for it yet, This is one of those things that you dont wait for your clients to ask for. Every other major router vendor has had a full featureset for v6 for quite some time now

FIPTech · Sat Sep 18, 2010 3:31 am

Using IPv4 with NAT will not be an option for linux based providers. Too much support problems. NAT is not reliable in Linux world and this has not been corrected in latest 2.6 kernels.

NAT is ok for WEB over xDSL, but as soon as you are doing VoIP or multiWAN, it is unusable.

There are still bugs specially when NAT is used with PPPoE interfaces and VoIP UDP trafic. Those bugs fully break trafic, sending sometimes privates IP to the Internet ! (confirmed with a protocol analyser on the WAN link). Then the outbound client trafic never come back. We have seen this since OpenWRT whiterussian with kernel 2.4, and same problem is still present in recent 2.6 kernel.

IPv6 will be the only way to get things working correctly and get machine to machine clean Internet connectivity. IPv6 will need a fast rollout as soon as IPv4 address space will be exhausted.

Latest Linux 2.6 kernels have a better support for IPv6, with a full set of compatibility tunnels (4 to 6, 6 to 4, 6 over 6).

IPv6 needs to be tested and fully implemented now as we are about one year from massive public IPv6 roll out.

Vendors without serious IPv6 support will stop selling hardware a few monthes before this date, because clients are not mad.

This is a good point for Cisco who has a serious IPv6 support since about 10 years, but will be a problems for many users without their devices.

I hope to see Mikrotik opening the code to a community, so that coding will be faster enough to take the train of IPv6. This will as well make the main code stable sooner. It will give the possibility as well to developpe third party packages.

Actually if i'm right the Router OS source code (free part) is not available without asking.

I think this is a handicap for code sanity and development speed. But this could transform to a full disaster as well if a big name in the routing world would decide to attack Mikrotik against GPL violation. We have seen in the telcom industry manufacturers disapearing because of patents violation.

As a Mikrotik client, i need to take care of this and not engage to much.

charliebrown · Sat Sep 18, 2010 11:45 am

Opening ROS just wont ever happen GPL or not. I dont think its needed either for this purpose, All MT needs to do is roadmap v6 in ROS and put some dev time on it. This is one of those things that when your clients are demanding it its too late to start on it

FIPTech · Sat Sep 18, 2010 1:57 pm

Yes you are right, Ipv6 needs to be done now. I think that clients will ask for it massively in a few monthes, and it will be too late for all manufacturers who will not have implemented and tested it seriously.

We are now about 8 monthes before IPv4 exhaustion, so Ip addresses prices will start to rise fastly in a few monthes. This will produce a massive interest for IPv6 addresses. Even today it is more and more difficult to get IPv4 addresses.

Software editors should concentrate all their efforts now to support IPv6 and the transitionnal functions needed. If they don't do it, other company will do it and a new startups market will start.

fmenard123 · Sat Sep 18, 2010 3:35 pm

This is the functionality I am interested.

On RouterOS, can a PPPoE session, as it is coming online, create automatically a route that can be advertised through OSPF, in IPv6 as it currently works in IPv4 ?

Upon an end-to-end IPv6 session over PPPoE, between say a RouterOS box at the customer premise, and a RouterOS core router, behind, the RouterOS PPPoE server, pick-up the end-to-end IPv6 traffic and support ....

TADAM

an IPv4 over IPv6 tunnel ?

This way I see the need for IPv4 only for the time being someone needs to access the legacy Internet.

F.

FIPTech · Sat Sep 18, 2010 4:29 pm

yes IPv4 over IPv6 tunneling is important for the transitionnal period.

IPv6 needs to be implemented with IPv4 supression in mind. We should be able to start router OS without the IPv4 stack and still get all functions needed for routing, firewalling and management.

IPv4 developpement should now slow down, concentrating not only on IPv6 but Ethernet technologies as well :

- GMPLS :Generalized Multiprotocol Label Switching. Simplify and reduce cost of Internet Mesh networks. Can be considered like enhanced MPLS-TE. GMPLS allow cost reduction and management enhancement supressing intermediate transport layers.

From year 1999 to 2002 here is the available network structures for Data transport :

1999 : Data -> IP -> ATM -> Sonet/SDH -> DWDM
2000 : Data -> IP with MPLS -> Sonet/SDH -> DWDM
2001 : Data -> IP with GMPLS -> Thin Sonet/SDH -> DWDM with optical switching
2002 : Data -> IP with GMPLS -> DWDM with optical switching

- Provider Backbone Bridge : IEEE 802.1ah. Can be considered like advanced QinQ. PBB adapts Ethernet technology to Access networks. IEEE 802.1ah-2008 is a set of architecture and protocols for routing of a customer network over a provider's network allowing interconnection of multiple Provider Bridge Networks without losing each customer's individually defined VLANs.

- Provider Backbone Bridge - Trafic Engineering : IEEE 802.1Qay-2009. PBB-TE adapts Ethernet technology to carrier networks.

- OAM management : 802.1ag. Defines protocols and practices for OAM (Operations, Administration, and Maintenance) for paths through 802.1 bridges and local area networks (LANs).

- EtherSAM testing : ITU-T Y.156sam. New testing method, enhancing RFC2544, for SLA certification with multi flows in mind (VoIP trafic quality when Data trafic flow at the same time)

Sonet / SDH / ATM has become too costly and heavy in the Internet world. The present is in IPv6, Ethernet and mesh networks with active single plane management. This is a chance for small manufacturers like Mikrotik to be able to provide products quite easily for this recent market, without the cost development of ATM and Sonet / SDH synchronous hardware.

Ozelo · Sun Sep 19, 2010 8:19 am

got stateless autoconfiguration not working on bridge interfaces... i.e. put a ether1 plus wlan1 on bridge and setup a /64 on the bridge interface.

I don't know if it should work at all, but I like the way it is. Giving a /48 to every single client according to the RFC seems to be the best practice indeed face the address space abundance.

Its been nice to be IPv6 ready, thanks to Mikrotik.

FIPTech · Sun Sep 19, 2010 1:23 pm

Giving a /48 to each client is the standard. It does allow each client to define about 65 000 /64 subnetworks...

An IPv6 subnetwork is always a /64.

Most clients are fully ignorant regarding IPv6. But as soon they will realize that they will get full Machine to Machine conectivity with IPv6, and that IPv6 is simpler and less costly than IPv4, i think that it will trig a massive IPv6 migration in a few monthes.

That's why manufacturers need to be ready to avoid a difficult situation.

Wed Sep 22, 2010 1:01 pm

I have just checked the latest 5b6 webfig and note that the IPv6 section is still not working right.

I reported this against the beta 1 iirc !

Nick.
tell me the ticket number and I will check the status
2010040166000303

This is still not working correctly on rc1 - is anyone actually testing webfig ?

Wed Sep 22, 2010 1:08 pm

there are several interface issues that we know of, and have not yet been fixed. Webfig as such is not yet a complete product, so we decided that giving you other RouterOS improvements now is better than holding off for another 2 weeks.

charliebrown · Wed Sep 22, 2010 1:18 pm

I think its worth pointing out to those looking for full v6 feature set from MT that out of the MT ROS v5 change log so far

What's new in 5.0rc1 (2010-Sep-17 13:58):

*) wireless nv2 - add WDS support;
*) added ability to monitor cpu usage by task (/tool profile);
*) added support for RPS (Receive Packet Steering) on multicore systems;
*) added cisco compatible gre tunnels;
*) fix simple queues on multicore (fixes intel 82576 crash/reboot);
*) fixed sstp memory leak;
*) winbox - fixed ability to configure RB1100 switches;
*) ssh - fix possible crashing;
*) snmp - fix GET request processing;
*) ipsec - added ability to specify ID_USER_FQDN peer identity;
*) ipsec - encypt last IKE phase 1 packet when in aggresive mode as initiator;
*) wireless nv2 - added nv2-cell-radius parameter to specify distance
     in km to farthest client on AP;
*) wireless nv2 - fix transmit stall issue for non-11n chips;
*) wireless - fix x86 nstreme multiprocessor hang;
*) made user manager web interface work again;
*) updated drivers and kernel (to linux-2.6.35);

What's new in 5.0beta6 (2010-Aug-10 13:22):

*) sstp - fixed memory leak;
*) wireless - changed band setting and added channel-width setting
*) wireless - support for 11n rates in 5&10mhz channels
*) wireless nv2 - fixed multiple problems including occasional tx stall;
*) made gps accessible through SNMP;
*) snmp - added GETBULK support, no more table caching - solves problems
            with huge tables, routing tables currently are not available;
*) ssh - fixed public key authentication in case
        when client is not verifying if server will accept the key;
*) fixed problem - MetaROUTER did not work on RB800, RB1000 & RB1100;

*) user manager is not working - will be fixed in next version;
*) intel 82576 (uncommon expensive chip) crash/reboot to be fixed in
   next release;

What's new in 5.0beta5 (2010-Jul-23 14:50):

*) email - supports multiple CCs
*) fix 5&10MHz channel support for 11n cards;
*) ssh - fix ssh client crash;
*) ssh - password authentication is disabled for users with public keys;
*) ping - fixed ping packet-loss calculation;

What's new in 5.0beta4 (2010-Jun-28 16:17):

*) console - /ping command again returns number of ping responses received,
    didn't work in 5.0beta3;
*) added ability to monitor each cpu core usage;
*) added support for SATA,SCSI & USB CD-ROMs in CD installer;
*) fixed problem - IRQ balancer did not use correct CPU core
   on non auto MSI irqs after reboot;
*) fixed memory leak;
*) route - new property 'vrf-interface' (for static and dhcp routes),
    automatically updates 'routing-mark' of the route to keep it in the same
    VRF as the specified interface;

What's new in 5.0beta3 (2010-Jun-17 13:46):

*) hotspot - drop hotspot specific tcp connections from non-hotspot clients
   already at firewall;
*) lcd - added support for AX89063
*) console - output of '/ping' and '/tool traceroute' commands is more
    in line with the rest of the console commands;
*) api - '/ping' and '/tool traceroute' commands are fully functional;
*) console - added 'server' and 'server-port' arguments to '/resolve' command;
*) lcd - show free/total memory in units of million bytes (MB);
*) lcd - added page that shows system identity;
*) sstp - made it work with Windows 7;
*) sstp server - client reconnects did not work;
*) winbox - implemented proper maximize support for inner windows;
*) fix 5&10MHz channel support for 11n cards;
*) added IRQ balancer;
*) enabled PCI MSI on i386 multicore setups;

What's new in 5.0beta2 (2010-Apr-30 11:24):

*) added wireless distance setting, removed ack-timeout;
*) improved 802.11 operation for outdoor distances;
*) fixed sstp on x86;
*) console - removed 'delay' argument from '/system scheduler add' command;
*) console - remove 'comment=""' values from export;
*) console - updated '/system script job':
    - also show active login sessions here;
    - new read-only property 'type' with values "command", "login"
        or "api-login" for running commands and either kind of login sessions;
    - new optional read-only property 'parent' with id of the job that
        has spawned this one;
*) console - changed "started" property of '/system script job' to use
    local time;
*) console - new property 'type' in '/system script job'
*) console - added '/port remote-access export' command;
*) console - fixed bug that caused "cannot set ..." error when using
    some properties in 'find' commands;
*) show old software id in export file header;
*) api - can supply password to '/system/upgrade/upgrade-package-source/add';
*) api - 'print' command was not showing values of some properties
    such as 'servers' in "/ip/dns";
*) api - fixed api login sessions not dissapearing from '/user active' after
    termination;
*) '/user active' now lists type of api connections as 'api';
*) added support for hardware watchdog on RB1000 & RB800;
*) added support for ASIX AX88xxx based USB Ethernet Adapters on RB4xx;
*) fixed problem - ipv6 traffic was not bridged if ipv6 package was not enabled;
*) fixed getting interface stats in dude;
*) fixed metarouter stability problem on RB400s & RB750s;
*) fixed metarouter - it didn't work on RB1000 with 2Gb;
*) fixed metarouter - it locked up on RB800;
*) fixed problem - SFQ queues did not work on interfaces (wireless) if none
   of simple or tree queues were added;
*) fixed RB800 temperature;
*) fixed problem - WinBox crashed while opening VAP interface;
*) dhcp server - fixed possible inactive dhcp server in case of many
   dhcp leases with address-pool enabled;
*) dhcp server - show non-printable option 82 agent-circuit-id and
   agent-remote-id values in hexadecimal notation
   (in the same way as client-id is shown);

What's new in 5.0beta1 (2010-Mar-31 09:17):

*) updated drivers and kernel (to linux-2.6.32.5);
*) ssh is now completely rewritten (supports connection forwarding, only DSA keys);
*) added support for SSTP protocol (PPP over TLS);
*) added support for multiple Intel Ethernet cards;
*) added support for IPv6 over PPP
   (enabled by default if ipv6 package is installed),
   link-local addresses are assigned, and server can issue IPv6 global prefixes
   to clients per ppp secret or RADIUS reply (Framed-IPv6-Prefix);
*) added proper support for MPLS over PPP (by default it is now disabled);
*) fixed RB800 temperature;
*) silentboot feature updated;
*) WinBox - any file dropped on WinBox will be uploaded to router;
*) multicast - fixed possible crash during PIM startup;
*) report platform name in "/sysrem resource";
*) fixed problem - vlans were not working on RB750 ether1;
*) fixed mac address handling on RB750, some specific arp requests did not work;
*) more than two dns servers allowed in /ip dns;
*) sniffer and torch could process packet from other interfaces;
*) ospf - fixed DR and BDR election;
*) ospf - changed "/routing ospf route" to show type 2 metric instead of
    internal metric for type 2 external routes;
*) added IPv6 support to trafflow (v9 only);
*) rewritten user-manager (formerly known as userman-test);
*) dns cache rotates order of records in reply messages

Only 3 items are to do with v6

*) added IPv6 support to trafflow (v9 only);
*) fixed problem - ipv6 traffic was not bridged if ipv6 package was not enabled;
*) added support for IPv6 over PPP

1 of which is a bug fix, PPP is a major one and a huge step forward but netflow for v6 is token given netflow bugs overall, We're still missing from ROS v5

DHCPv6 (Is it in v5? Nothing in the change log but I thought it was for some reason)
IPSEC;
SSH, FTP, API, Winbox, Webbox access;
simple queues;
automatic tunnel creation;
policy routing;
multicast routing;
MPLS;
torch, netwatch, bandwidth test and other tools

Now what I wanted from ROS v5 was

DHCPv6
IPSEC
SSH, FTP, API, Winbox, Webbox access
simple queues
torch, netwatch, bandwidth test and other tools

It looks like the v6 crowd have missed the boat on getting these into ROS v5, Can we get a promise from MT to have these put into ROS v6? I'd really prefer to see these in v5 even if they are added in as point releases during the ROS v5 life cycle

Ozelo · Wed Sep 22, 2010 9:11 pm

I'm missing "routing filters" for OSPFv3... we can't apply a appropriate policy routing then.

Fri Oct 01, 2010 11:31 am

Some ipv6 updates:

- SSH and FTP already have ipv6 access
- API is coming next
- Winbox is coming very soon
- Bandwidth test is coming soon

- IPsec is planned this year, or early next year, probably for v5
- DHCPv6 is planned, but after the above, will try to make it into v5

omidkosari · Fri Oct 01, 2010 11:36 am

And what about Mikrotik-Address-List and Radius things ?

Fri Oct 01, 2010 11:38 am

Any news on ipv6 mangle mark routing ?

Fri Oct 01, 2010 11:43 am

we try to order these things based on number of requests, the two mentioned are not so popular, so will come after what was listed.

charliebrown · Fri Oct 01, 2010 11:52 am

Really? Route marking is seriously that hard to put in? I dont have a need for it right now but I'm extremely surprised to see something so completely basic not in yet

Fri Oct 01, 2010 11:53 am

if you desperately need something, tell us

charliebrown · Fri Oct 01, 2010 11:55 am

Its pretty basic, I mean comon. The tricky stuff like winbox access and even API I can understand but its route marking! Is there anything else in Firewall/Mangle I cant do? I'm about to start work on the trial prep

gustkiller · Fri Oct 01, 2010 2:30 pm

simple queues and torch for ipv6!!!!

FIPTech · Fri Oct 01, 2010 2:40 pm

A switch to disable all IPv4 stack.

Ozelo · Fri Oct 01, 2010 3:59 pm

Okay, we desperately need IPv6 mangling (for QoS and policy routing), OSPFv3 routing filters (policy routing), torch (to do the homework), winbox (helpdesk fellas need it), NAT64 (make it possibly growing IPv4 needless) and YES, we ALSO desperately need DUDE supporting IPv6 so we can gladly monitor our fresh native IPv6 networks.

We desperately need everything else Mikrotik can do, but I desperately can't remember all those to list up to you yet! Kudos to Mikrotik anyway, without we couldn't implement IPv6 that fast.

dssmiktik · Fri Oct 01, 2010 6:32 pm

Is ipv6 routing mark available for netfilter/iptables? If so, Mikrotik only has to include that version, there's no real work that needs to be done other then testing to make sure it works.

If not, I suggest trying to encourage the netfilter core team to implement this, and once they do, notify Mikrotik that it's ready.

bevhost · Fri Oct 01, 2010 9:52 pm

If you can't do DHCPv6 client/server yet can you at least do DHCPv6 relay?

If hotspot with IPv6 can't be made to work then we need to fall back to PPPoE Server working with IPv6 and we need DHCPv6 relay.

This won't be too good for Hotels and the like, but for sites with longer term users they can use PPPoE for RADIUS authentication/billing instead of captive portal/hotspot. RFC4779 suggests that this is how customers should be connected over an ethernet connection. I don't think the authors of the RFC thought about how guests in hotels should know how to sign up for PPPoE.

Beccara · Mon Oct 18, 2010 8:30 am

Annnnd we're starting to see what happens when you get allocated the bottom of the v4 barrel

"Hi All,

We are having a little trouble with a new IPv4 address range recently received from APNIC. The range is xxx.xxx.xx.0/22 (although according to APNIC it affects the entire /8). Please see the attached email. It seems that there are some routers which have blocks on this range, which need to be lifted. Some of the sites we cannot connect to include: airnz.co.nz and dse.co.nz. We suspect some email is also not getting through.

Can anyone suggest how best to get these routing blocks lifted? My shiny new IP address range is starting to feel distinctly second-hand.

Any help you can provide would be warmly welcomed."

So as we dip more into the last of v4 land we'll see more of this, Old routers with static bogon lists and stacks that took shortcuts.

We've just requested another /22, I predict it will be the last slice of v4 we'll be able to get

Ozelo · Mon Oct 18, 2010 9:50 pm

Interesting, ROS 4.11 does NOT allow assign multiples IP addresses from the same /64 on the same interface, even disabled ones. I wonder if that is a must...

Paxy · Thu Oct 28, 2010 12:09 pm

What about NAT64 ?

Thu Oct 28, 2010 12:13 pm

What about NAT64 ?

before crossposting in every topic, please search the forum!

Paxy · Thu Oct 28, 2010 12:22 pm

before crossposting in every topic, please search the forum!

Sure, if I maked to find what I looking for, I would not post a question !

Can not believe that few users that can not see advontage of NAT64 can slow down its development.

Thu Oct 28, 2010 12:32 pm

read the thread from the start:

http://forum.mikrotik.com/viewtopic.php ... 69#p224669

Beccara · Thu Nov 25, 2010 3:30 pm

So to drag this bad boy back up but...

After carefully working on V6 with a few connections, getting everything working, coming up with a bypass for v6 over pppoe with ROS 4.0 and spending a lot of time testing the links to make sure a v6 enabled connection didn't break anything I deployed it to 4-5 CPE on our network and watched and used it.

Everything worked great, nobody noticed it was on but it worked and we spent a bit of time using v6 google.

Fast forward to the past week and I've been preparing for larger trails by setting up BGP for v6. Then I was the Titanic and hit an iceberg.

our AP's static route /64's over 6to4 tunnels to the client which is then put on the lan, From the AP there is a full BGP mesh between our AP's to our core router which passes it up the chain over BGP again. I was surprised to see a full v6 route table making it's way out to AP's when it was not setup to do so and also concerned to see the testing CPE's when switch over could access some v6 sites but not others and some can communicate with the other CPE's but some can't even tho the route was showing up in the other AP it was not routing to that router.

Basically dynamic routing of v6 was all messed up, I had a phantom full v6 route table still being sent around the AP's even when the AP's were disconnected from the core routers and had routes showing up in AP's but not being able to be used.

Keep in mind that dynamic routing of v6 was added in ROS 3.0 RC's I sent this to MT support who replied with:

Ticket #2010112466000113
"Hello,

Sorry, but currently it looks like this feature is simple unsupported. Please, avoid using it till we will came out with release that supports it. We can't give any estimates.

Regards,
MikroTik Support"

So not only are some fairly major v6 features missing the ones we have are pretty broken, All this when the first of the estimates of IANA exhaustion has ticked over to under 100days.

Very not cool MT

cste005 · Sat Nov 27, 2010 6:44 am

As we start to push IPv6 out to customers, features like DHCPv6 are pretty much non-negotiable. We have had to start running Cisco as CPE to get this feature set. I'd much rather be using RouterOS! So take this as another vote for DHCPv6 support for us just client would do (for prefix delegation) but I'll take server support as well!

It's great to see IPV6CP and IPv6 support in PPP just need DHCPv6 to complete our puzzle.

Thanks

FIPTech · Mon Nov 29, 2010 10:21 am

We have pushed IPv6 to clients 4 years ago, and we enable it in the client LANs now.

It would be nice to get full IPv6 support from Mikrotik as fast as possible because we are now advertising IPv6 as an important part of our offer.

IPv4 address pool end date has been advanced to 03 march 2011. But this has been projected since about ten years. So every manufacturer should be ready. Unfortunately, this is not the case.

As IPv6 global rollout is now in the rails, it's important to make IPv6 global deployment as fast as possible to avoid IPv4 / IPv6 connectivity problems.

IPv4 needs now to be supressed as fast as possible from the global Internet network and from clients.

Beccara · Mon Nov 29, 2010 10:40 am

Its nice to have some support in this, To be fair to MT a little IPv4 runout has been predicted as "next-year" for a number of years by some media despite the numbers not stacking up. Unless we see a very dramatic downturn in IP allocations it looks like we're less than 100 days away now from IANA runout

It's sad to say but with the amount of people screaming for V5 release and NV2 IPv6 will be put on the back burner, UBNT's turned up the heat with AirMax and AirMax GPS. I fear those of us speaking logic and reason (Slow down, fix the broken things first then add new features etc) are being shouted down by those wanting their shiny new toy

Beccara · Mon Dec 06, 2010 3:18 pm

So perhaps time to ask MT again to come out and state what they will support and when with IPv6, There's a number of big holes in that MT feature set

Mon Dec 06, 2010 3:19 pm

So perhaps time to ask MT again to come out and state what they will support and when with IPv6, There's a number of big holes in that MT feature set

Some ipv6 updates:

- SSH and FTP already have ipv6 access
- API is coming next
- Winbox is coming very soon
- Bandwidth test is coming soon

- IPsec is planned this year, or early next year, probably for v5

Beccara · Mon Dec 06, 2010 3:22 pm

Cool so all you're going to support is what we have now plus API/WINBOX/BTest and maybe IPSEC

So no DHCPv6 etc etc, That's good to know that your same post 2 months on has no updates what so ever

Mon Dec 06, 2010 3:30 pm

Cool so all you're going to support is what we have now plus API/WINBOX/BTest and maybe IPSEC

So no DHCPv6 etc etc, That's good to know that your same post 2 months on has no updates what so ever

what updates do you want, the promised time has not come yet (early next year)!
Already said in the other topic, that winbox/webfig etc is coming in v5rc6.

I have no information about any other timeframes.

DownUnder · Mon Dec 06, 2010 3:50 pm

So are we the public to take it that a company of your size two months later has no more progress made? Winbox v6 is great but I think you are forgetting your basic tools. Radius client cant use a v6 address yet, neither can e-mail smtp, Torch doesn't work and what about SNMP?

If Current + API/Winbox/Btest are the only v6 that are going to make it into ROS 5.0 then I feel sorry for your client's who will be left behind

Mon Dec 06, 2010 3:56 pm

So are we the public to take it that a company of your size two months later has no more progress made? Winbox v6 is great but I think you are forgetting your basic tools. Radius client cant use a v6 address yet, neither can e-mail smtp, Torch doesn't work and what about SNMP?

If Current + API/Winbox/Btest are the only v6 that are going to make it into ROS 5.0 then I feel sorry for your client's who will be left behind

Sure, make new accounts.

Why do you think no progress is made? Two months ago we didn't have anything made for ipv6 winbox. Now I just told you that it's ready for next release.

DownUnder · Mon Dec 06, 2010 4:02 pm

Because in response to a post asking you to state what you will support and when you c&p'ed the item you posted 2 months ago. Which leaves one to ask will MT look at the tools like Radius Client and SNMP for v6 or will they be forgotten.

The post was very clear and your response frank.
Perhaps to be clear you should answer this:
Do you intend to make all function seen in Winbox (I.e IP > IPsec, IP > SNMP etc) v6 compatible in beta form before IANA exhaustion and to have them all stable before RIR exhaustion?

omega-00 · Fri Dec 31, 2010 7:04 am

We're awaiting some form of IPv6 hotspot support however can work with DHCPv6 support and other IPv6 PPP support for the time being.

However, there are still things like radius (mentioned above) that are really part and parcel.

All that said, very excited to see the list of new IPv6 features in the beta!

janisk · Mon Jan 03, 2011 8:32 am

you can look at change log - you would see:

What's new in 5.0rc6 (2010-Dec-23 13:33):
*) added IPv6 support to RADIUS client;
*) added IPV6 support to graphing;
*) added IPv6 support to SNTP client;
*) added IPv6 support to watchdog;
*) added IPv6 support for /tool e-mail;
*) added IPv6 support for /tool bandwidth-test;
*) added IPv6 support for /tool torch;

Anticimex · Thu Jan 20, 2011 7:46 pm

Hi Mikrotik,

first let me express how impressed I am with the agility of this networking operating system and the low cost of the routerboards that you produce. Well done!

I'm a quite experienced networking professional who recently bought a few RB:s for private testing/laboration, and I run ROS 5.0 on them right now.

I run a few ROS 5 boxes with l2tp tunnels between themselves, and I run IPv6 over this. I recently set up xl2tpd / PPP on my Debian Squeeze laptop to tunnel out IPv6 to it. And it kind of works fine, for the hacking level of functionality. IP6CP works, but there is something missing to make the IPv6 support, or "portfolio" if you will, of ROS much, much more complete, namely DHCPv6 and Prefix Delegation.

You can look at http://tools.ietf.org/html/rfc4241 for a conceptual overview of how DHCPv6 (and PPP) interacts, with Prefix Delegation ( http://tools.ietf.org/html/rfc3633 ), to provide a device with one or several prefixes that it can further propagate/assign to clients of its own.

Here's an idea on how you can go about implementing support for this:

1) Research relevant DHCPv6 RFCs and get a grip on the architecture
2) Add a simple DHCPv6 relay server
3) Add a DHCPv6 server
4) Add Prefix Delegation to the DHCPv6 server
5) Add a DHCPv6 client
6) Add Prefix Delegation (Requesting) to the DHCPv6 client

I have only a few months of experience with ROS here, but it is my understanding that you have a good code base to build upon. For example, adding something like a "Prefix Pool" similar to the ip pools should not be very complicated.

A function similar to a "Prefix Pool" is necessary for the Prefix Delegation to work properly. Perhaps you will soon start to see the real value possible with having these features. If you haven't already, let me explain further:

If ROS runs at the provider edge, it can for example (as I have done) configure a prefix larger than /64 in the PPP secrets database, which it will then autoconfigure for its clients who supports IP6CP. There's however no real way to precisely propagate the information about the prefix to the client.
When I configure a /56 in the PPP secrets database, a /56 is issued to my laptop over via PPP-over-L2TP. (Debian then tries to run the SLAAC autoconfiguration and create an address out of the /56, which doesn't work (it assumes a /64), but that's Debians problem). My laptop configures the entire prefix on the ppp0 device, which is kind of correct but perhaps not what I was really looking for here. In other words, the prefix and would-be address from a /64, given out with PPP/IP6CP is assumed to sit on the ppp0-link itself, which isn't what I want.

At any rate, there is a well-standardized way to handle the proper propagation of prefixes. And instead of re-inventing the wheel with adding new not-yet-existing standards to IP6CP (which I considered at first), a lot can be won by using DHCPv6 / PD.

The future has these wonderful networking options in store:
A DHCPv6-server has a Prefix Pool which it can "~randomly" take unassigned prefixes from and assign to requesting clients, or it can be matched to certain DHCPv6 client IDs or certain tunnels (or whatever).

The prefixes are provisioned to clients on a need basis, eg, obviously only a DHCPv6 client that requests one or several prefixes will receive one or several prefixes. (here you see another configuration option; max prefixes per DHCPv6 client ID/interface/MAC/something).

So from a clients perspective, it can become real useful if for example a ISP hands out /56 prefixes to requesting clients.

The requesting device can receive this /56, store it into its Prefix Pool as a master prefix or something, which it, by configuration of the DHCPv6-client, can chop up some amount of bits (divide by 2,4,8,16 etc), into prefixes which its DHCPv6 Server then can further assign to other interfaces.

And voila, IPv6 can reach so far, with very little address/prefix configuration, only meta-configuration. Truly good capabilities.

There are potential issues here, of course. For example, what happens if a prefix is cascaded in many steps (3 - 4) and suddenly the top device does not receive it anymore? Well, lease times can take moderately care of removing the prefixes downstream, but essentially it ought to be up to every DHCPv6 server administrator along the cascading path to *not* change the prefix too often, to minimize work and hassle.

That is mostly an operational issue however.

And yes, I'm willing to test the eventual DHCPv6-code with you if you want me to.

Thank you for your time,
Regards,
Martin

themmc · Tue Jan 25, 2011 9:53 am

I work for an ISP running a dual stack PPP trial for customers. Broadband with IPv6 really requires DHCPv6 Prefix Delegation to work. Is 5rc8 likely to have this?

janisk · Tue Jan 25, 2011 11:05 am

rc8 most probably will not include DHCPv6 yet.

themmc · Tue Jan 25, 2011 11:42 am

rc8 most probably will not include DHCPv6 yet.

Any kind of time frame? A few customers have asked and become frustrated that they can't use your product. DHCPv6 PD is pretty critical.

Tue Jan 25, 2011 11:48 am

rc8 most probably will not include DHCPv6 yet.
Any kind of time frame? A few customers have asked and become frustrated that they can't use your product. DHCPv6 PD is pretty critical.

why ?

themmc · Tue Jan 25, 2011 11:56 am

why ?

Why is DHCPv6 Prefix Delegation important?

So, typically in the IPv4 world a PPP session comes up and you negotiate a single IP address and NAT behind that. A subnet routed through the PPP session is unusual and typically done where the end customer knows what it is.

IPv6 doesn't really involve NAT. So you need to be able to acquire an IPv6 range (/56 or /48 or whatever) to use on your internal network. Typically the PPP session itself is either unnumbered and/or has a /64 assigned. So your CPE uses DHCPv6 PD to discover the IPv6 prefix you need to use. Your CPE can then assign /64s to it's network interfaces based on that or even subassign space to other routers.

If you don't use DHCPv6 PD then you can't discover plus your provider's BRAS/BNG/LNS doesn't have the range in it's routing table.

DHCPv6 Prefix Delegation (PD) is the way that this is all being done. It's critical to IPv6 broadband.

Have a look at TR-187 from Broadband Forum (http://www.broadband-forum.org/technica ... TR-187.pdf).

(This also applies to IPoE providers where DHCPv4 is used).

(If you want any more info etc, then happy to discuss offline).

FIPTech · Tue Jan 25, 2011 2:43 pm

That's true.

With our IPv6 PPPoE DSL links, we need to manually setup IPv6 prefix on the router. Not so evident for final customers (most of the time today nobody knows something about IPv6, but they'll need it quite fastly).

Beccara · Wed Jan 26, 2011 10:00 pm

DHCPv6 PD is nice but it's not a game changer, Work around the issue by just assigning the /64 on the interface rather than wait for PD

themmc · Thu Jan 27, 2011 10:13 am

DHCPv6 PD is nice but it's not a game changer, Work around the issue by just assigning the /64 on the interface rather than wait for PD

DHCPv6 PD is actually critical to IPv6 broadband.

The PPP interface isn't the issue, it's the client's CPE getting the IPv6 range from us that is. When you've got 30k or more customers per BRAS and MANY BRAS you need to do this automatically.

At the moment my customers can't use MikroTik routers as CPE, so I'm trying to work out when that might be.

Beccara · Thu Jan 27, 2011 10:56 pm

Work around it? If you have 30k of users then script it. It's not hard to work around MT failing right now.

themmc · Fri Jan 28, 2011 8:37 am

Work around it? If you have 30k of users then script it. It's not hard to work around MT failing right now.

I have many times that. I have many BRAS which these customers can connect to. I also then have to have the customers hand code the IPv6 prefix in their CPE. This does not scale. Certainly not to the many hundreds of thousands of customers I have. (These BRAS aren't Mikrotik btw).

DHCPv6 PD allows this to just happen and is part of how everyone is and will deploy IPv6 broadband. Denying it won't help.

Beccara · Fri Jan 28, 2011 9:25 am

Denying it I'm not, Just saying there is a way around it now. No point in not doing it just cos there isnt a nice auto way of doing it.

Also who's handing out dynamic v6 space??? Thats pretty crazy!

butche · Fri Jan 28, 2011 10:06 am

DHCPv6/PD is really among the most important features needed. I have sent MY request to support@mikrotik.com. If EVERY one of you who want a useful feature would do the same, then perhaps we'd get a little developer time on this. While I think this is important, there are other features that are almost as important that are either not present or not working correctly.

* OSPFv3 is still not fully supported, or is not working correctly.
* DHCPv6 client is not present.
* No form of DHCPv6 server, but that has been mentioned
* IPv6 Queues (simple queues) - this MAY be there, haven't checked recently. This MUST be able to co-mingle with an IPv4 address, though. Customer owns 10.10.10.10 + their v6 prefix. All combined get 1m/1m (as an example).

For my money, those 4 are nearly "deal killers" for v6 and MT. Is it reasonable to assume that these will be working in 3 months? 6 months? I don't want a date, but SOME time frame would be helpful. I don't care if you answer here (in public) or privately (to my support ticket), but at least give us something to work with. I feel like I'm talking to D-Link here.

My customers are currently looking for guidance on v6. At this time, my advice is: wait or use another product if you can't wait. That "other" product is often cisco, which I despise, but I have to put food on my table, so I stick my hands in those networks, too. SIGH...

Fri Jan 28, 2011 10:10 am

Butch:
http://forum.mikrotik.com/viewtopic.php?f=2&t=47883

Who is online