We select RouterOS for border router w BGP full route tables.
All devices running w dual-stack scenario, but IPv6 support in IPv6 is limited; we are blind.
We need IPv6 support for: torch, VRRPv6, Queue (simple), Routing Policy, other tools (bwtest, netwatch).
http://www.keepalived.org (extend VRRP to support IPv6)
-
-
Princemild
just joined
- Posts: 1
- Joined:
Re: RouterOS border router need more IPv6 support
Full implementation of ripe-501 "router or layer 3 switch" profile.
http://www.ripe.net/docs/ripe-501.html
Mandatory support:
IPv6 Basic specification [RFC2460]
IPv6 Addressing Architecture basic [RFC4291]
Default Address Selection [RFC3484]
ICMPv6 [RFC4443]
SLAAC [RFC4862]
MLDv2 snooping [RFC4541]
Router-Alert option [RFC2711]
Path MTU Discovery [RFC1981]
Neighbour Discovery [RFC4861]
Classless Inter-domain routing [RFC4632]
If dynamic internal guidance protocol (IGP) is requested, then RIPng [RFC2080], OSPF-v3 [RFC5340] or IS-IS [RFC5308] must be supported. The contracting authority shall specify the required protocol.
If OSPF-v3 is requested, the equipment must comply with "Authentication/Confidentiality for OSPF-v3" [RFC4552]
If BGP4 protocol is requested, the equipment must comply with RFC4271, RFC1772, RFC4760, RFC1997, RFC3392 and RFC2545
Support for QoS [RFC2474, RFC3140]
Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213]
Using IPsec to Secure IPv6-in-IPv4 tunnels [RFC4891]
Generic Packet Tunneling and IPv6 [RFC2473]
If 6PE is requested, the equipment must comply with "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)” [RFC4798]
Multicast Listener Discovery version 2 [RFC3810]
If mobile IPv6 is requested, the equipment must comply with MIPv6 [RFC3775, RFC5555] and "Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture" [RFC4877]
If MPLS functionality (for example, BGP-free core, MPLS TE, MPLS FRR) is requested, the PE-routers and route reflectors must support "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" [RFC 4798]
If layer-3 VPN functionality is requested, the PE-routers and route reflectors must support "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN" [RFC 4659]
If MPLS Traffic Engineering is used in combination with IS-IS routing protocol, the equipment must support "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120]
Optional support
Revised ICMPv6 [RFC5095]
DHCPv6 client / server [RFC3315]
Extended ICMP for multi-part messages [RFC4884]
SEND [RFC3971]
SLAAC Privacy Extensions [RFC4941]
Stateless DHCPv6 [RFC3736]
DHCPv6 PD [RFC3633]
Route Refresh for BGP Capabilities-4 [RFC2918]
BGP Extended Communities Attribute [RFC4360]
(QOS), Assured Forwarding [RFC2597]
(QOS) Expedited Forwarding [RFC3246]
Generic Routing Encapsulation [RFC2784]
Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]
Cryptographically Generated Addresses [RFC3972]
ProSafe-v3 [RFC4301, RFC4303, RFC4302]
IPSec-v2 [RFC2401, RFC2406, RFC2402]
IKE version 2 (IKEv2) [RFC4306, RFC4718]
SNMP protocol [RFC3411]
SNMP capabilities [RFC3412, RFC3413, RFC3414]
Mibsam SNMP for IP [RFC4293] Forwarding [RFC4292], IPsec [RFC4807] and DiffServ [RFC3289]
DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596]
DNS message extension mechanism [RFC2671]
DNS message size Requirements [RFC3226]
127-bit IPv6 Prefixes on Inter-Router Links:
http://tools.ietf.org/html/draft-kohno- ... len-p2p-01
Packetization Layer Path MTU Discovery [RFC4821]
When IS-IS routing protocol is requested, the equipment should support "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120] (this support is highly recommended)
http://www.ripe.net/docs/ripe-501.html
Re: RouterOS border router need more IPv6 support
I see that:
Mandatory support:
MLDv2 snooping [RFC4541]
as http://tools.ietf.org/html/rfc4541 is still in state of "Considerations for ..."
I still hope they come up with something decent for switches and then can justify why this cannot be also as MLD. If compared to Multicast in IPv4, then snooping brakes it in a very bad way and every vendor has its own way of seeing things.
Mandatory support:
MLDv2 snooping [RFC4541]
as http://tools.ietf.org/html/rfc4541 is still in state of "Considerations for ..."
I still hope they come up with something decent for switches and then can justify why this cannot be also as MLD. If compared to Multicast in IPv4, then snooping brakes it in a very bad way and every vendor has its own way of seeing things.
Re: RouterOS border router need more IPv6 support
DHCPv6 client / server [RFC3315] <- Pretty please? 
We would urgently need this capability to dispatch Mikrotik CPEs for IPv6 enabled customers...
We would urgently need this capability to dispatch Mikrotik CPEs for IPv6 enabled customers...
Re: RouterOS border router need more IPv6 support
it (DHCPv6) is in the TODO list, no ETA yet.
Re: RouterOS border router need more IPv6 support
MT has most things on a TODO list for v6, when are you guys going to get your act together and work on it, its getting pretty late in the game to still be giving 'no eta's to us about something pretty critical
Re: RouterOS border router need more IPv6 support
if at this moment you can create functioning IPv6 only network using RouterOS and maintain it. It is other matter that you do not have something you want to use instead of already something else already available.
There is no ETA, because it is not know precisely how much time will be spent developing and testing it. And we do not like to share some estimates that can fail.
There is no ETA, because it is not know precisely how much time will be spent developing and testing it. And we do not like to share some estimates that can fail.
-
-
roadracer96
Forum Veteran
- Posts: 733
- Joined:
Re: RouterOS border router need more IPv6 support
I just got an IPV6 allocation and I gotta say... Needs connection tracking....
Re: RouterOS border router need more IPv6 support
connection tracking information is not currently displayed. It is working however. So you can go to mangle and mark connections and after that packets based on connection-marks.
Re: RouterOS border router need more IPv6 support
I thought I'd share this with the forums
So list, This is what we need as a minimum
Winbox access over Local-Link and Global IP's
API access over Global IP's
Bandwidth Test to Global IP's
EoIP & IPIP over Global IP's
VRRP (Any changes needed here? Got asked to ask)
DHCPv6 (Dont need it but have clients who will want it)
SNMP access over Global Ip's
IP > Services - Be able to restrict these to v6 IP prefix's
NTP Client and Server - Unicast Global IP's
Watchdog to support v6 Global IP's
Radius Client to support v6 Global IP's
Tools > E-mail to support Global IP's Netwatch - v6 Host's
Torch
Is what I asked for in a e-mail to support, Their response was:
The above list is what we need to operate a functional v6 network on top of whats already announced, With those things in you should be able to operate a v6 network in much the same way you run your v4 network
So list, This is what we need as a minimum
Winbox access over Local-Link and Global IP's
API access over Global IP's
Bandwidth Test to Global IP's
EoIP & IPIP over Global IP's
VRRP (Any changes needed here? Got asked to ask)
DHCPv6 (Dont need it but have clients who will want it)
SNMP access over Global Ip's
IP > Services - Be able to restrict these to v6 IP prefix's
NTP Client and Server - Unicast Global IP's
Watchdog to support v6 Global IP's
Radius Client to support v6 Global IP's
Tools > E-mail to support Global IP's Netwatch - v6 Host's
Torch
Is what I asked for in a e-mail to support, Their response was:
I asked if all of the above would be in the final ROS 5.0 and got thisOnly problem should be with API - it is not highest priority, so will be implemented later, VRRP will need some research first, i just added it to the list.
Rest of the list we already had in our list.
So hopefully this sheds some light on what MT is going to support in ROS 5.0 with IPv6 (Also hope the dynamic routing isn't too buggy, We have to go with static routing right now as ROS 4.13 is very very odd)Hello,
Some of those features will be there even in v5.0rc6. More advanced features such as DHCPv6 and Dynamic Routing will take more time.
The above list is what we need to operate a functional v6 network on top of whats already announced, With those things in you should be able to operate a v6 network in much the same way you run your v4 network
Re: RouterOS border router need more IPv6 support
just wait for rc6 release. This is all i can say at this moment.
-
-
roadracer96
Forum Veteran
- Posts: 733
- Joined:
Re: RouterOS border router need more IPv6 support
connection tracking information is not currently displayed. It is working however. So you can go to mangle and mark connections and after that packets based on connection-marks.
Hmm... When I set connection state to new on certain ICMPv6 ins, with accept established/related above it, the ICMPv6 never hit. Untill I took off the connection state. (ICMPv6 for Router Discovery).
Ill try again.