FortiOS 8.0.0 MAP-E rejects JPIX v6 Plus DHCPv6-PD prefix as “invalid end user prefix”

Hello Keisueke Mori, 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

Regards,

Regards,

Hello Keisuke and thank you for your patience!

I found this solution for your issue, can you tell us if it helps you, please?

MAP-E with DHCPv6-PD on FortiOS 8.0.0

Based on the provided Fortinet context, I can confirm only the following:

What the documentation shows

Fortinet documentation for MAP-E with DHCPv6-PD shows:

• MAP-E can operate in DHCPv6-PD environments
• The example uses:
  • MAP rule distribution server: rule.map.ocn.ad.jp
  • DDNS update server: ipoe-static.ocn.ad.jp

The documented CPE-side configuration is:

config system interface
    edit "port6"
        set vdom "root"
        set type physical
        set snmp-index 6
        config ipv6
            set ip6-mode delegated
            set ip6-allowaccess ping
            set dhcp6-prefix-delegation enable
            set ip6-delegated-prefix-iaid 1
            set ip6-upstream-interface "port6"
            set ip6-subnet ::1/64
            config dhcp6-iapd-list
                edit 1
                    set prefix-hint ::/56
                next
            end
        end
    next
end

And the VNE interface is configured as:

config system vne-interface
    edit "vne.port6"
        set interface "port6"
    next
end

MAP-E operation described by Fortinet

The Fortinet MAP-E documentation states that after IPv6 is configured on the FortiGate:

• The FortiGate sends a MAP rule request to the MAP distribution server
• It sends an AAAA query to get the IPv6 address of the MAP distribution server
• After the BMR request, the FortiGate receives:
  • IPv4 address
  • port set
  • BR IPv6 address
  • hostname of the address resolution server
• The VNE tunnel is then established

It also states:

• The address resolution server is actually a dynamic DNS
• The hostname is used so the FortiGate can maintain an IPv6 address when it changes
• The FortiGate updates the DDNS server with its IPv6 address whenever it changes

What cannot be confirmed from the provided context

The provided Fortinet context does not confirm:

• whether FortiOS 8.0.0 supports dynamic MAP-E specifically for JPIX “v6 plus”
• how vned selects a provider-specific MAP rule server
• whether rule.map.ocn.ad.jp is hardcoded or chosen from an internal provider profile
• whether the MAP rule server can be overridden in CLI
• what exact value is expected for bmr-hostname
• whether invalid end user prefix is tied to a supported-prefix/provider validation list
• whether this is a known defect versus an unsupported-provider limitation

Because that information is not present in the supplied context, I cannot verify those points.

What your symptoms do align with from the docs

From your description:

• DHCPv6-PD succeeds
• DNS resolution for the MAP/DDNS hostnames succeeds
• no BMR exchange occurs
• tunnel remains unbuilt
• vned reports invalid end user prefix

The Fortinet documentation does show that the MAP-E workflow depends on the FortiGate obtaining a valid end-user IPv6 prefix and then proceeding to MAP rule/BMR processing. However, the documentation does not define validation criteria for that prefix or provider-specific acceptance logic.

Conclusion

Conclusion: What can be stated confidently

From the provided Fortinet documentation, DHCPv6-PD for MAP-E is supported, and the documented examples use the OCN-related servers:

• rule.map.ocn.ad.jp
• ipoe-static.ocn.ad.jp

However, the context does not provide enough information to confirm JPIX “v6 plus” support, provider-selection behavior, CLI override capability, bmr-hostname expectations, or whether invalid end user prefix is a bug or unsupported-provider condition.

What the provided Fortinet context confirms

Based on the provided Fortinet documentation, FortiOS supports MAP-E and MAP-E can operate in DHCPv6-PD environments.

The documented DHCPv6-PD MAP-E example shows:

• A WAN interface using:
  • set ip6-mode delegated
  • set dhcp6-prefix-delegation enable
  • set ip6-delegated-prefix-iaid 1
  • set ip6-upstream-interface "port6"
  • set ip6-subnet ::1/64
  • set prefix-hint ::/56
• A VNE interface configured with:
  • config system vne-interface
  • edit "vne.port6"
  • set interface "port6"

The MAP-E support documentation also shows VNE tunnel configuration with:

config system vne-tunnel
    set status enable
    set interface 'wan1'
    set ssl-certificate "Fortinet_Factory"
    set bmr-hostname ********
    set auto-asic-offload enable
    set mode map-e
end

The documentation examples reference:

• rule.map.ocn.ad.jp
• ipoe-static.ocn.ad.jp

What the provided Fortinet context does not confirm

The provided context does not confirm any of the following:

• Whether api.enabler.ne.jp is supported by FortiOS MAP-E
• Whether JPIX v6 plus is supported
• Whether provider selection is automatic for JPIX
• Whether bmr-hostname changes the MAP-E rule distribution endpoint
• Whether 240b:10::/xx delegated prefixes are recognized as valid for JPIX MAP-E
• Whether there is a supported CLI method to manually override the provisioning or rule-distribution endpoint
• Whether the behavior you observed is a known defect versus an unsupported-provider limitation

Because your question asks for confirmation beyond what is present in the supplied Fortinet context, I cannot verify those points.

Conclusion

Conclusion: Fortinet context is insufficient to confirm JPIX-specific support

From the provided Fortinet documentation, I can confirm only that:

• MAP-E with DHCPv6-PD is supported in FortiOS
• The documented examples use OCN-related endpoints
• bmr-hostname exists in MAP-E VNE tunnel configuration

However, the provided context is insufficient to confirm:

• support for api.enabler.ne.jp
• support for JPIX v6 plus
• automatic provider selection behavior
• manual override of the provisioning endpoint
• validation of 240b:10::/xx prefixes

Thank you for checking the available documentation.

I understand that the public documentation does not contain enough information to determine the JPIX v6 Plus support status.

Since the issue appears to occur locally inside vned, before any connection to the MAP provisioning server is attempted, could you please check the following points with the FortiOS product or engineering team?

1. Is dynamic MAP-E for JPIX v6 Plus supported in FortiOS 8.0.0?
2. Is JPIX v6 Plus supported in any current FortiOS release? If so, from which FortiOS version/build?
3. How does FortiOS determine whether a delegated IPv6 prefix belongs to OCN Virtual Connect, JPIX v6 Plus, or another Japanese VNE provider?
4. What exact validation causes mape_rule_client_timer_func() to report:

invalid end user prefix

Is there an internal provider-specific IPv6 prefix table or allowlist used by the MAP-E client?

5. Is rule.map.ocn.ad.jp hardcoded for the current MAP-E implementation, or is the provisioning endpoint selected according to the detected VNE provider?
6. Is bmr-hostname unrelated to the MAP rule provisioning endpoint?

I manually configured:

bmr-hostname api.enabler.ne.jp

and the setting was accepted, but the MAP-E rule client continued to report:

fqdn=rule.map.ocn.ad.jp

Therefore, changing bmr-hostname does not appear to change the provisioning endpoint.

7. Is api.enabler.ne.jp supported as a MAP-E provisioning endpoint for JPIX v6 Plus?
8. If automatic JPIX provisioning is not supported, is there a supported CLI method to manually specify the provisioning endpoint?

Alternatively, is there a supported way to manually configure the MAP-E BMR/BR rule and CE IPv4 parameters without using dynamic provisioning?

9. If JPIX v6 Plus is currently unsupported, is this an intentional product limitation, a known defect, or a feature that has not yet been implemented?

If applicable, is there a Bug ID, feature request ID, or FortiOS version in which JPIX v6 Plus support was added or is planned?

For reference, a known-working router on the exact same physical connection receives the same DHCPv6-PD /56 prefix and successfully performs the following sequence:

DHCPv6-PD succeeds
→ the same 240b:10:xxxx:xxxx::/56 prefix is received
→ api.enabler.ne.jp is resolved
→ an IPv6 TCP/TLS connection to api.enabler.ne.jp:443 is established
→ MAP-E connectivity becomes operational

The FortiGate receives the same delegated prefix, but rejects it with invalid end user prefix before transmitting any TCP SYN.

This makes it appear that the failure occurs in FortiOS provider/prefix validation rather than in DHCPv6-PD, IPv6 connectivity, or DNS resolution.

I understand that my FortiCare contract has expired, so I am not requesting individual TAC troubleshooting. I am mainly trying to clarify the FortiOS product behavior and JPIX v6 Plus support status.

Any confirmation from the product or engineering team would be greatly appreciated.

I retested this issue after upgrading the FortiGate 100F to FortiOS 8.0.1 build0245.

The test was performed with the alternative router path fully disabled. The secondary interface was administratively down, its physical link state was confirmed as down, and the corresponding IPv6 route was removed.

The WAN interface retained its static IPv4 mode. Only its IPv6 configuration was temporarily changed to the documented DHCPv6-PD delegated configuration:

config system interface
    edit "x1"
        config ipv6
            set ip6-mode delegated
            set dhcp6-prefix-delegation enable
            set ip6-delegated-prefix-iaid 1
            set ip6-upstream-interface "x1"
            set ip6-subnet ::1/64
            config dhcp6-iapd-list
                edit 1
                    set prefix-hint ::/56
                next
            end
        end
    next
end

The VNE interface was configured in MAP-E mode with api.enabler.ne.jp specified as the BMR hostname.

A packet capture confirmed that the complete DHCPv6-PD exchange succeeded:

DHCPv6 Solicit
DHCPv6 Advertise
DHCPv6 Request
DHCPv6 Reply

The FortiGate successfully obtained and applied the delegated prefix:

end user ipv6 prefix: 240b:10:ef2a:d900::/56
interface ipv6 addr: 240b:10:ef2a:d900::1

However, the vned debug output repeatedly reported:

Map-e rule client (state: init)
invalid end user prefix 240b:10:ef2a:d900::/56

The error was repeated approximately every five seconds.

The VNE diagnostic status remained as follows:

bmr rule ipv6 prefix: ::/0
bmr rule ipv4 prefix: 0.0.0.0/0
Map-e rule client: state=init
reply_code=0

No MAP-E tunnel was established.

In addition, even though api.enabler.ne.jp was explicitly configured as the BMR hostname, the debug output showed that FortiOS selected the following OCN endpoints:

fqdn=rule.map.ocn.ad.jp
fqdn=ipoe-static.ocn.ad.jp

No connection to api.enabler.ne.jp was observed during the test.

This appears to reproduce the same behavior originally reported on FortiOS 8.0.0. The issue is still reproducible on FortiOS 8.0.1 build0245.

Could Fortinet please confirm the following?

1. Is the JPIX v6 Plus delegated prefix range 240b:10::/xx supported by the FortiOS MAP-E VNE implementation?

2. Why is the valid delegated /56 prefix rejected as an invalid end user prefix?

3. Why does FortiOS select the OCN rule-distribution and DDNS endpoints even when api.enabler.ne.jp is explicitly configured?

4. Is bmr-hostname intended to select the MAP rule-distribution provider, or is provider selection performed internally using a fixed prefix/provider table?

5. Is this behavior a known defect or an unsupported-provider limitation?

6. Is a fix planned for a future FortiOS 8.0.x release?

7. Is there a supported workaround that allows JPIX v6 Plus MAP-E to operate without using the OCN provisioning endpoints?

The configuration was rolled back after the test, and both IPv4 and IPv6 connectivity recovered normally.

Hello Keisuke,

Hope you are doing well :) Thanks for all these informations, I found those answers to your questions, hope it helps!

What the provided Fortinet context confirms

Based on the provided Fortinet documentation:

• FortiOS supports MAP-E
• MAP-E can operate in DHCPv6-PD environments
• In the documented MAP-E DHCP-PD examples, the FortiGate shows:
  • delegated IPv6 prefix learned successfully
  • WAN IPv6 address derived from that prefix
  • MAP-E rule client and DDNS client operation
  • use of:
    • rule.map.ocn.ad.jp
    • ipoe-static.ocn.ad.jp
• The documented diagnostics include fields such as:
  • end user ipv6 prefix
  • interface ipv6 addr
  • bmr rule ipv6 prefix
  • bmr rule ipv4 prefix
  • tunnel br
  • Map-e rule client
  • Map-e DDNS client

What the provided context does not confirm

The provided context does not confirm any of the following:

• support for JPIX v6 Plus
• support for api.enabler.ne.jp
• whether 240b:10::/xx is a supported delegated prefix range for MAP-E
• why invalid end user prefix is triggered internally
• whether bmr-hostname controls MAP rule-distribution endpoint selection
• whether provider selection is based on an internal prefix/provider mapping
• whether this is a known defect
• whether this is an unsupported-provider limitation
• whether a fix is planned for any future FortiOS 8.0.x release
• whether there is a supported workaround for JPIX v6 Plus MAP-E that avoids the documented OCN endpoints

Conclusion

Conclusion: Current documentation is insufficient to confirm JPIX-specific MAP-E behavior

From the available Fortinet context, I can only confirm that FortiOS MAP-E with DHCPv6-PD is documented, and that the documented examples use the OCN-related endpoints rule.map.ocn.ad.jp and ipoe-static.ocn.ad.jp.

Your specific questions about:

• JPIX v6 Plus support
• 240b:10::/xx prefix acceptance
• api.enabler.ne.jp support
• bmr-hostname behavior
• internal provider-selection logic
• defect status, workaround, or planned fix

are not answered in the provided context.