Provide auto-provisioning of AFTR for DS-Lite for both RFC6334 and Japanese Market

Blind link back:

Currently auto-configuration is not possible. LUCI prompts to enter AFTR manually.

Can you share dhcp6 response in pcap format. I.e if aftr header is present.

I do not get any DHCPv6 responses. In Japan routers implement a different approach. See the second link in my question.

I am to arachnophobic to read it,
RFC requires ports and gateway in dhcpv6 option. If there is other mechanism you need to show real life packet with config data, probably opening github bug report

I captured ICMPv6 and DHCPv6 traffic from my ISP and couldn't find any specific protocol information advertised by the ISP side. Looking at most common Japanese routers configuration documentation, it is obvious that the manufactures hardcode the AFTR domain names in their configuration pages. So, OpenWrt configuration can do the same - provide three choices for DS-Lite AFTR address:

  • transix (hardcode
  • Cross Pass (hardcode
  • Other - requires manual entry of AFTR address.

If ISP provides DS-Lite tunnel service the names and are resolved by the DNS server advertised by the DHCP server in response to udhcpc solicitation.

This change seems like a simple update to the LUCI interface.

Here is a link to a network configuration instructions of one of the popular Japanese routers supporting DS-Lite.

Reading 2 languages you could point out in English which corner of specification is missing in OpenWRT, or which blurred line from RFC is drawn to one or other side in actual JP implementation...

Nothing is missing in the implementation of the DS-Lite protocol. I was suggesting to add a convenience feature to the LUCI Web interface to configure AFTR values for specific types of Japanese DS-Lite providers, namely transix and Cross Pass.

Ask your provider to add AFTR name to DHCP response?

As I see the code today - this is freely editable. There are no included names, but you can add your own under the ds-lite page.

You do have ds-lite installed in openwrt/luci, right?

You need to live in Japan to understand why I am requesting this change :slight_smile: If it was as simple as asking your provider, then there would not be a problem. Unfortunately Japanese ISPs are in cahoots with the router manufactures and they tell customers just go and buy DS-Lite compatible routers. Also the configuration of ISP providers is not freely available on internet, even if one searches the Japanese side of the internet. Even for a technical person it is not easy to dig out this information. In my personal case I know what to do, just trying to promote the usage of OpenWrt in Japan and help people to save money on hardware.

The change should be as simple as adding two selection items in


or some HTML form - I am not that familiar with the LUCI design structure.

It is up to you to make pull request with 100 lines to add for the rest of the world split in similarly sized markets.

1 Like

OK, I will try to do it.

I am not that familiar with LuCI.ui framework and ran into a problem displaying selected value from form.ListValue in form.Value. The function .write() sets a new value of the form.Value, that can be confirmed by .load() but .cfgvalue() does not show it.
What is the trick here? How can I make the selected value be displayed in the other field? Here is the part of the code that I am trying to introduce.

 renderFormOptions: function (s) {
    var peerAddrType = s.taboption(
      _("DS-Lite AFTR address type"),
    peerAddrType.value("", _("Custom Address"));
    peerAddrType.value("", _("Transix (Japan only)"));
    peerAddrType.value("", _("Cross Pass (Japan only)"));

    var peerAddr = s.taboption(
      _("DS-Lite AFTR address"),
    peerAddr.rmempty = false;
    peerAddr.datatype = 'or(hostname,ip6addr("nomask"))';

peerAddrType.onchange = function(ev) {
  var section_id = this.section.section;
  var selectedValue = this.formvalue(section_id);
  console.log("Before peerAddr.cfgvalue:", peerAddr.cfgvalue(section_id));
  console.log("Before peerAddr.load:", peerAddr.load(section_id));
  peerAddr.write(section_id, selectedValue);
  console.log("After peerAddr.cfgvalue:", peerAddr.cfgvalue(section_id));
  console.log("After peerAddr.load:", peerAddr.load(section_id));

On the other hand, there is a very simple solution without showing hardcoded addresses. The change requires only three additional lines of code:

    o.value("", _("Transix (Japan only)"));
    o.value("", _("Cross Pass (Japan only)"));
    o.default = "";

which will translate in the following interface changes:

Image 1

Screenshot 2024-05-20 102437

Image 2

Screenshot 2024-05-20 102507

Image 3

Screenshot 2024-05-20 102539

Image 4

Screenshot 2024-05-20 102601

Image 5

Do you think this change is OK to submit the pull request?

The proposal was implemented.