RouterOS v7 cannot activate IPv4 connected route over ipipv6 (DS-Lite / RFC6333)

RouterOS RouterOS beta
1

This is a reproducible RouterOS v7 issue affecting IPv4 routing over ipipv6 interfaces.

Summary:

  • IPv6 connectivity is working (AFTR reachable, ICMPv6 OK)
  • ipipv6 interface is RUNNING
  • IPv4 address can be assigned to ipipv6 interface
  • RouterOS creates IPv4 connected route
  • However, the route remains DIc and never becomes ACTIVE
  • As a result, no IPv4 packets are generated

This occurs not only with DS-Lite (RFC6333) but also with a plain ipipv6 tunnel.

MikroTik support (SUP-209458) confirmed:

  • This is not a configuration issue
  • There is no user-configurable way to change this behavior

Impact:

This prevents RouterOS from functioning as a DS-Lite CPE on networks such as NTT FLET'S (Japan), where IPv4 connectivity depends entirely on IPv4-over-IPv6.

This behavior makes RouterOS unusable as a DS-Lite CPE in real-world deployments.

Required behavior:

RouterOS should allow IPv4 L3 routing over ipipv6 interfaces.
The IPv4 connected route should become ACTIVE when:

  • interface is RUNNING
  • IPv6 path is reachable
  • IPv4 address is assigned

Question to MikroTik developers:

Is this a known limitation, or a defect to be fixed?

Still reproducible in 7.22rc4 after clean configuration.

Environment was reset to remove all test configurations.

Observed:

  • ipipv6 interface is RUNNING
  • IPv4 address (192.0.0.2/32) is assigned correctly
  • RouterOS creates the connected route

However:

  • connected route remains DIc and never becomes ACTIVE
  • /ping 8.8.8.8 => no route to host
  • /ping 8.8.8.8 interface=dslite => timeout

This confirms the issue is not related to configuration or leftover state.

IPv4 routing over ipipv6 remains non-functional in RouterOS v7.

【日本語】

クリーンな状態で再構成しても、7.22rc4で同じ問題が再現します。

テスト用の設定はすべて削除し、環境をリセットした状態で確認しています。

確認結果：

・ipipv6 インターフェースは RUNNING 状態
・IPv4 アドレス（192.0.0.2/32）は正常に割り当てられる
・RouterOS は connected route を生成する

しかし：

・connected route は DIc のままで、ACTIVE にならない
・/ping 8.8.8.8 → no route to host
・/ping 8.8.8.8 interface=dslite → timeout

この結果から、設定ミスや残骸の影響ではないことが確認できました。

RouterOS v7 では ipipv6 上の IPv4 ルーティングが依然として機能していません。

2

Connected routes can be active only on running interfaces (interface with R flag).

3

Maybe try to use /29 instead?

At least with sniffer or torch active, I was able to get DS-lite working, see DS-Lite only works properly when sniffer/torch are active?

4

The ipipv6 interface already has the R flag (RUNNING).

/interface ipipv6 print shows the interface is RUNNING.

However, the IPv4 connected route still remains DIc and does not become ACTIVE.

So even though the interface meets the "R flag" condition, the connected route is not activated.

This suggests that ipipv6 interfaces are not treated as valid L3 interfaces for IPv4 routing in RouterOS v7.

ipipv6 インターフェースは既に RUNNING（Rフラグあり）状態です。

しかし、それでも IPv4 connected route は DIc のままで、ACTIVE になりません。

つまり「RフラグがあればACTIVEになる」という条件を満たしているにもかかわらず、connected route が有効化されていません。

この挙動から、RouterOS v7 では ipipv6 インターフェースがIPv4のL3インターフェースとして扱われていない可能性があります。

5 
[admin@CCR2004_2XS_111] /interface/ipipv6> print 
Flags: R - RUNNING
Columns: NAME, MTU, ACTUAL-MTU, LOCAL-ADDRESS, REMOTE-ADDRESS, KEEPALIVE, DSCP
#   NAME            MTU   ACTUAL-MTU  LOCAL-ADDRESS  REMOTE-ADDRESS  KEEPALIVE  DSCP   
0 R ipipv6-tunnel1  auto        1460  ::             2111:2::1       10s,10     inherit

[admin@CCR2004_2XS_111] /interface/ipipv6> /ip route/print where immediate-gw~"ipipv6"            
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE
    DST-ADDRESS  GATEWAY         ROUTING-TABLE  DISTANCE
DAc 1.2.3.1/32   ipipv6-tunnel1  main                  0
6

Thank you for the suggestions.

Regarding the /29 proposal:

The subnet size (/32 vs /29) should not affect whether a connected route becomes ACTIVE.

RouterOS already creates the IPv4 connected route correctly.
The issue is that the route remains DIc and never transitions to ACTIVE, regardless of subnet size.

This behavior is also reproducible on a plain ipipv6 tunnel, not only with DS-Lite.
Therefore, it is not specific to DS-Lite configuration.

Regarding the sniffer/torch observation:

Another user reported that DS-Lite starts working when sniffer or torch is active.

This is a very important clue.

It suggests that route evaluation or packet processing may not be triggered properly under normal conditions, and is only activated when traffic inspection tools are running.

This would indicate a timing or processing issue inside RouterOS rather than a configuration problem.

Summary:

  • ipipv6 interface is RUNNING (R flag present)
  • IPv4 address is assigned correctly
  • connected route is created
  • however, it never becomes ACTIVE under normal conditions
  • and IPv4 traffic is not generated

This behavior is consistent across clean configurations and multiple test scenarios.

Required behavior clarification (for development team):

Based on all observations, the issue appears to be in how RouterOS evaluates IPv4 connected routes on ipipv6 interfaces.

Currently:

  • ipipv6 interface can be RUNNING
  • IPv4 address can be assigned
  • connected route is created
  • but the route remains DIc and never becomes ACTIVE

As a result, no IPv4 packets are generated and DS-Lite (RFC6333) cannot function.

Expected behavior:

RouterOS should treat the ipipv6 interface as a valid L3 interface for IPv4 routing.

The IPv4 connected route MUST become ACTIVE when all of the following conditions are met:

  1. ipipv6 interface has R (RUNNING) flag
  2. IPv6 path to the remote endpoint (AFTR) is reachable
  3. IPv4 address is configured on the ipipv6 interface

If these conditions are satisfied, the system should:

  • mark the connected route as ACTIVE
  • allow IPv4 packet generation over the tunnel

Additional observation:

DS-Lite may start working when sniffer/torch is active.

This suggests that route evaluation or packet processing is not triggered properly under normal conditions.

This strongly indicates a missing or inconsistent trigger in RouterOS routing logic.

【日本語】

ご提案ありがとうございます。

/29 についてですが、

サブネットサイズ（/32 と /29）は、connected route が ACTIVE になるかどうかには影響しないはずです。

RouterOS は IPv4 connected route 自体は正しく生成していますが、
問題はそれが DIc のままで、ACTIVE に遷移しない点にあります。

また、この挙動は DS-Lite に限らず、通常の ipipv6 トンネルでも再現します。
したがって DS-Lite 固有の設定問題ではありません。

sniffer / torch に関する指摘についてですが、

sniffer や torch を有効にすると DS-Lite が動作するという報告がある点は非常に重要だと考えています。

これは通常時にルーティング評価やパケット処理が適切にトリガーされておらず、
トラフィック監視時にのみ処理が発火している可能性を示しています。

つまり、設定の問題ではなく、RouterOS内部の処理タイミングや評価ロジックの問題である可能性が高いです。

まとめ：

・ipipv6 インターフェースは RUNNING（Rフラグあり）
・IPv4 アドレスは正常に割り当てられる
・connected route は生成される
・しかし通常状態では ACTIVE にならない
・IPv4トラフィックが生成されない

この挙動はクリーンな環境でも再現しています。

【開発チーム向け 要求仕様の整理】

今回の挙動から、RouterOS における ipipv6 インターフェース上の
IPv4 connected route の評価ロジックに問題があると考えられます。

現状：

・ipipv6 は RUNNING 状態になる
・IPv4 アドレスを設定できる
・connected route は生成される
・しかし DIc のままで ACTIVE にならない

その結果、IPv4パケットが一切生成されず、
DS-Lite（RFC6333）が機能しません。

期待される挙動：

RouterOS は ipipv6 インターフェースを
IPv4ルーティングの有効なL3インターフェースとして扱う必要があります。

以下の条件を満たした場合：

1）ipipv6 が RUNNING（Rフラグあり）
2）リモートIPv6（AFTR）への到達性がある
3）IPv4アドレスが設定されている

connected route は ACTIVE になるべきです。

また：

sniffer / torch を有効にすると動作する場合があることから、
通常時にルーティング評価やパケット処理が適切にトリガーされていない可能性があります。

これは RouterOS のルーティングロジックにおける
トリガー欠落または不整合の可能性を示しています。

7

As it was explained already in SUP ticket, your interface is NOT running. Connected route can be active only on running interfaces for obvious reasons.

8

Have you ever tried explicitly disabling keepalive?

In my experience, the tunnel didn’t work until I explicitly removed keepalive using the `!` syntax. As I understand it, the ISP’s AFTR doesn’t respond to keepalive requests, so it seems the tunnel loses its state when the timer expires.

9

The issue is not about configuration.

Even with a clean setup:

  • ipipv6 is RUNNING
  • IPv4 address is assigned
  • connected route is created

But it never becomes ACTIVE.

This is reproducible and independent of configuration.

これは設定の問題ではありません。

クリーンな環境でも：

・ipipv6 は RUNNING
・IPv4 アドレスは割り当てられる
・connected route は生成される

しかし ACTIVE になりません。

設定に依存せず再現します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Additional comment:

I want to be very clear about the importance of this issue.

I am not reporting a minor configuration problem. I am providing reproducible evidence of a fundamental limitation or defect that directly affects real-world deployments.

In Japan, DS-Lite (RFC6333) over NTT FLET'S is widely used, and proper IPv4-over-IPv6 functionality is mandatory for any router to be viable in this market.

At the moment, this behavior makes RouterOS unusable as a DS-Lite CPE in such environments.

This is not just a technical issue — it is also a market opportunity.

Currently, there is growing concern in Japan around the reliability and security of consumer networking products from other vendors. This creates a strong opportunity for MikroTik to expand in this market.

However, without proper DS-Lite support, it will be difficult to compete.

I have been highlighting this opportunity since last year because I genuinely believe MikroTik hardware is excellent and has strong potential here.

That is exactly why I am pushing for this issue to be properly understood and addressed.

I strongly encourage the team to take this seriously and escalate it appropriately.

I am willing to provide any additional data, testing, or validation needed to help resolve this.

【追加コメント】

本件の重要性について明確にお伝えさせてください。

これは単なる設定の問題ではなく、
実運用に影響する根本的な制限または不具合の可能性を、
再現性のある形で報告しています。

日本では NTTフレッツ網における DS-Lite（RFC6333）が広く利用されており、
IPv4 over IPv6 が正しく動作することはルーターとして必須条件です。

現状の挙動では、RouterOS はこの用途において実質的に利用できません。

これは技術的な問題であると同時に、
市場機会にも直結する重要なポイントです。

現在、日本市場では他社製品の信頼性やセキュリティに関する問題が話題になっており、
MikroTik にとって大きな参入チャンスが存在しています。

しかし、DS-Lite が正しく動作しない限り、
この市場で競争することは難しくなります。

私は昨年からこの可能性についてお伝えしてきましたが、
それは MikroTik のハードウェアが非常に優れていると考えているからです。

だからこそ、本件を正しく理解し、適切に対応していただきたいと考えています。

必要であれば追加の検証やデータ提供にも協力いたします。

10

You have some strange definition of "running".
This is your interface status:

;;; LAN bridge
 9 R  bridgeLAN     bridge               1500   1596             04:F4:1C:51:C9:0D
10    dslite        ipipv6-tunnel        1460  65535                              
11 R  lo            loopback            65536                    00:00:00:00:00:00

It clearly shows that interface is NOT running, which means that connected route on that interface cannot be active, too.

You need to focus on making a tunnel working first. As it was suggested disable keepalive, check connectivity whether ipipv6 packet is not being blocked by firewalls or lost on hops in between etc.

11

The ipipv6 interface IS running.

Here is the exact output:

/interface ipipv6 print detail where name="dslite"

It clearly shows the R flag (RUNNING).

So the interface meets the condition required for a connected route to become ACTIVE.

However, the connected route still remains DIc and never becomes ACTIVE.

This confirms that the issue is not caused by the interface state.

【日本語】
ipipv6 インターフェースは RUNNING 状態です。

以下の出力を確認してください：

/interface ipipv6 print detail where name="dslite"

Rフラグ（RUNNING）が明確に表示されています。

つまり、connected route が ACTIVE になるための条件は満たしています。

それにも関わらず、connected route は DIc のままで ACTIVE になりません。

したがって、インターフェース状態が原因ではありません。

12

Then send a supout file to support, generated when the interface is running and route is not active. As far as I can see all the supouts you have sent has interface in non running state.

13

Are you posting LLM slop here?

14

Following your suggestion, I have generated a new supout.rif while the ipipv6 interface is confirmed to be RUNNING.

The file has been sent to MikroTik support for analysis.

At the time of capture:

  • interface is RUNNING (R flag present)
  • connected route exists but remains DIc
  • IPv4 traffic is still not working

So the issue persists even under the correct conditions.

【日本語】
ご指摘に従い、ipipv6 インターフェースが RUNNING 状態で

新しく supout.rif を取得し、サポートへ送付しました。

取得時点では：

・インターフェースは RUNNING（Rフラグあり）

・connected route は存在するが DIc のまま

・IPv4通信は動作しない

つまり、正しい条件でも問題は再現しています。

15

There is a discrepancy:

CLI shows ipipv6 interface as RUNNING (R flag),
but supout captures it as not running.

This inconsistency itself may indicate a bug.

Regardless of this, IPv4 connected route still remains DIc and traffic does not work.

Environment:

This is a DS-Lite (RFC6333) connection provided over NTT FLET'S (Japan).
IPv4 connectivity is only available via IPv4-over-IPv6 (AFTR).

The router must operate as a DS-Lite CPE in this environment.

【日本語】

状態に不整合があります。

CLIでは ipipv6 インターフェースは RUNNING（Rフラグあり）と表示されますが、
supout では non-running として扱われています。

この不一致自体が不具合である可能性があります。

また、この状態に関わらず、
IPv4 connected route は DIc のままで ACTIVE にならず、
通信も動作しません。

環境：

本環境は NTTフレッツ網（日本）の DS-Lite（RFC6333）接続です。
IPv4通信は IPv4 over IPv6（AFTR）でのみ提供されています。

このため、ルーターは DS-Lite CPE として正しく動作する必要があります。

16

Update:

The latest support reply still assumes the tunnel was never in RUNNING state.

However, the exact sequence captured is:

  1. /interface ipipv6 print detail where name="dslite"
    -> shows R flag (RUNNING)

  2. /ip route print detail where dst-address~"192.0.0."
    -> connected route still remains DIc

  3. /system sup-output
    -> generated immediately after the above state

Environment:
NTT FLET'S Japan, DS-Lite (RFC6333), IPv4 provided only via IPv4-over-IPv6 through AFTR.

So the issue being reported is:
the interface shows RUNNING, but the IPv4 connected route still does not become ACTIVE.

【日本語】

更新：

サポートからは「トンネルがRUNNINGになっていない」という前提で回答されていますが、
実際に取得した時系列は以下の通りです。

  1. /interface ipipv6 print detail where name="dslite"
    → Rフラグあり（RUNNING）

  2. /ip route print detail where dst-address~"192.0.0."
    → connected route は DIc のまま

  3. /system sup-output
    → 上記状態の直後に取得

環境：
NTTフレッツ網（日本）における DS-Lite（RFC6333）接続
IPv4は AFTR を経由した IPv4 over IPv6 のみで提供

つまり本件は：
インターフェースが RUNNING にも関わらず、
IPv4 connected route が ACTIVE にならない問題です。

17

Yo dawg, stop posting AI hallucinated crap in here and use your own brain to read the output of the said commands.

18

If there is an incorrect assumption in my analysis, please point it out with specific technical details.

もし私の内容に誤りがあるのであれば、具体的な技術的根拠とともにご指摘ください。

19

They were mentioned numerous times above.

20

Required RouterOS fix:

When an ipipv6 interface is RUNNING and an IPv4 address is assigned to it,
the connected IPv4 route must become ACTIVE.

Current behavior:

  • ipipv6 = RUNNING
  • IPv4 address = assigned
  • connected route = created
  • but route remains DIc
  • IPv4 packets are never sent

Expected logic:

if (interface.type == ipipv6 &&
interface.running == true &&
ipv4.address.assigned == true &&
connected.route.exists == true) {
connected.route.state = ACTIVE;
}

At the moment, RouterOS creates the route object but does not activate it.
This prevents practical DS-Lite CPE operation.

【日本語】

必要な RouterOS 修正内容:

ipipv6 インターフェースが RUNNING 状態で、
そこに IPv4 アドレスが設定されている場合、
connected IPv4 route は ACTIVE になる必要があります。

現状:

  • ipipv6 = RUNNING
  • IPv4アドレス = 設定済み
  • connected route = 生成される
  • しかし route は DIc のまま
  • IPv4 パケットが送出されない

期待されるロジック:

if (interface.type == ipipv6 &&
interface.running == true &&
ipv4.address.assigned == true &&
connected.route.exists == true) {
connected.route.state = ACTIVE;
}

現在の RouterOS は route object は作成するものの、
ACTIVE 化しません。
そのため DS-Lite CPE として実用できません。