Roadshow TCP/IPv4 to include IPv6?

[Belxjander]

Is it road mapped or possible to update Roadshow to include IPv6?

I'm currently stuck in the situation of needing an external raspberry pi to translate from IPv4 to IPv6 in connecting my sam440 to the outside world more and more...

Is this possibly already road mapped so a redundant request?

[duga]

Your ISP should provide you with an IPv4 address for your LAN, behind your modem/gateway. WAN side = IPv6, LAN side = IPv4.

[Belxjander]

I'm asking as a true/false about this option even being roadmapped,

As I'm aware of the ISP situation here in Japan has various VDSL and FTTH setups usually involving 1-3 different IPv4/IPv6 devices ( LAN IPv4 is gated to IPv6 in some cases ).

So direct IPv6 support seems to be something to look at now, for a proper solution to be planned and included.

[chris]

I mentioned this years and years ago. Sooner or later, IPv6 will be required for Internet access, at least to parts of the Internet. The IPv4 address pool is running out, and if you can't lookup and access IPv6 addresses you can't access IPv6-only hosts. A gateway between the IPv4 Amiga and the IPv6 Internet isn't really a solution (can it magic up IPv4 addresses for IPv6-only hosts?).

[duga]

A gateway between the IPv4 Amiga and the IPv6 Internet isn't really a solution

Yes it is. IPv4 on the LAN side and IPv6 on the WAN side.

[chris]

A gateway between the IPv4 Amiga and the IPv6 Internet isn't really a solution

Yes it is. IPv4 on the LAN side and IPv6 on the WAN side.

Can it magic up IPv4 addresses for IPv6-only hosts?

[Belxjander]

I've been working on this a little on and off and generally I'm stuck with IPv4 hosts only as accessible with the RPI only bridging over IPv6 as a transparent means of access.

I'm looking at completely replacing the RPI with a different SBC and seeing what I essentially need,
however it looks like I'll have my sam440 relegated to being LAN isolated.

As the ISP I use has changed (NTT FTTH Broadband replacing the older VDSL from Jupiter Communications),
this has also changed the IPv6 requirements from "possibly in the future" to "I am using this now".

So if any IPv6 (hell... bsdsocket.library as IPv4 stack Interface front-end, and other libraries for actual network stack operations?) solutions can be made to work natively, I think that would be preferred?.

Can this be queued up as a "want to have" for when any developer can get to it and make it happen?.

[Elwood]

Sorry to tell you that, if I remember correctly, IPV6 as well as WLAN require a complete rewrite of the stack. So it's a 3 years work at least.
Then I don't know how this can happen in a reasonable timeframe.

[Belxjander]

Well then ..

Yes / No, Is the Roadshow stack as it is now internally modular in design?

Would there be any significant portion of code retained should the stack have any developer "split" it into modules with the bsdsoet.library becoming a more generic front-end redirecting to modules as required?

or is that also a multi-year rewrite requirement?

Can any update replacement work start with a DiskIO equivalent NetworkIO library using the existing "NetInterface" variation of DOSdrivers?

Could that be a practical first step towards WLAN + multiple network protocols in parallel use of sana devices?

[vox]

Sorry to tell you that, if I remember correctly, IPV6 as well as WLAN require a complete rewrite of the stack. So it's a 3 years work at least.
Then I don't know how this can happen in a reasonable timeframe.

If its 3 years work we better get starting it already.

Internet wizard needs to be more autoconfig oriented, stack cant handle 1MBit so even if x1000/x5000/Tabor drivers appear they will not be reaching max speed, plus IPv6 ... Seems this should be a priority.