layer3 - add support for RFC 8925 #298

New Issue

niXXda · 2024-01-17T18:16:56+01:00

niXXda commented

2024-01-17 18:16:56 +01:00

Enable users to deploy so called 'IPv6-mostly networks' where IPv6-only capable hosts no longer request DHCP leases if there is a working NAT64 mechanism in place. This reduces IPv4 resource usage and needed DHCP pool sizes.

jkimmel commented

2024-01-17 19:07:16 +01:00

Gute Idee. Openwrt Doku ist noch etwas sparsam bei dem Thema, aber ich habe ein paar slides gefunden:

https://ripe87.ripe.net/wp-content/uploads/presentations/8-IPv6-mostly_on_OpenWRT.pdf

Seite 17: PREF64

config dhcp 'lan6'
    option interface 'lan6'
    …
    option ra_pref64 '64:ff9b::/96'

Seite 22: Setting up DHCP Option 108

config dhcp 'lan'
    option interface 'lan'
    list dhcp_option '108,0:0:7:8'
    …

Gute Idee. Openwrt Doku ist noch etwas sparsam bei dem Thema, aber ich habe ein paar slides gefunden: https://ripe87.ripe.net/wp-content/uploads/presentations/8-IPv6-mostly_on_OpenWRT.pdf Seite 17: **PREF64** ```uci config dhcp 'lan6' option interface 'lan6' … option ra_pref64 '64:ff9b::/96' ``` Seite 22: **Setting up DHCP Option 108** ```uci config dhcp 'lan' option interface 'lan' list dhcp_option '108,0:0:7:8' … ```

jkimmel commented

2024-01-22 03:37:31 +01:00

Wir müssen noch einmal genauer überlegen, wie wir das mit dem WKP (Well-Known Prefix) handhaben.

RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators, Section 3.1: Restrictions on the Use of the Well-Known Prefix:

The Well-Known Prefix MUST NOT be used to represent non-global IPv4
addresses, such as those defined in RFC1918 or listed in Section 3
of RFC5735. Address translators MUST NOT translate packets in
which an address is composed of the Well-Known Prefix and a non-
global IPv4 address; they MUST drop these packets.

Aktuell werden auf manchen Translators auch unsere internen IPv4 Adressbereiche (10.50.0.0/16, 10.83.0.0/16) verfügbar gemacht, was ausdrücklich nach RFC 6052 so nicht gedacht ist.

Man müsste also ein anderes Translation Prefix wählen. RFC 8215 - Local-Use IPv4IPv6 Translation Prefix schlägt vor, dafür ein 64:ff9b:1::/48 zu verwenden und daraus ein passenden /96 Prefix heraus zu schneiden.
Wir sollten dabei darauf achten, dass das Prefix möglichst Checksum Neutral bleibt. Das RFC gibt auch Beispiele dazu, wie das geht.

Daher grob meine Idee:

Vermutlich wäre das schlauste weiterhin das WKP 64:ff9b::/96 beizubehalten, aber es RFC 6052 -konform zu betreiben.
Zusätzlich dazu können wir dann ein zweites Prefix aus 64:ff9b:1::/48 nutzen und das Routing und die Übersetzung ins interne Netz und Internet dort bereitstellen.
Man müsste noch einmal die Kompatibilität mit Clientgeräten prüfen. (ra_pref64 Option, z.B.)
Wir brauchen auch einen weiteren DNS64 Dienst, der auf das neue Prefix umsetzt

Wir müssen noch einmal genauer überlegen, wie wir das mit dem *WKP* (Well-Known Prefix) handhaben. [RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators, Section 3.1: Restrictions on the Use of the Well-Known Prefix](<https://datatracker.ietf.org/doc/html/rfc6052#section-3.1>): > The Well-Known Prefix MUST NOT be used to represent non-global IPv4 > addresses, such as those defined in [RFC1918](https://datatracker.ietf.org/doc/html/rfc1918) or listed in Section 3 > of [RFC5735](https://datatracker.ietf.org/doc/html/rfc5735#section-3). Address translators MUST NOT translate packets in > which an address is composed of the Well-Known Prefix and a non- > global IPv4 address; they MUST drop these packets. Aktuell werden auf manchen Translators auch unsere internen IPv4 Adressbereiche (`10.50.0.0/16`, `10.83.0.0/16`) verfügbar gemacht, was ausdrücklich nach RFC 6052 so nicht gedacht ist. Man müsste also ein anderes Translation Prefix wählen. [RFC 8215 - Local-Use IPv4IPv6 Translation Prefix](https://datatracker.ietf.org/doc/html/rfc8215) schlägt vor, dafür ein `64:ff9b:1::/48` zu verwenden und daraus ein passenden `/96` Prefix heraus zu schneiden. Wir sollten dabei darauf achten, dass das Prefix möglichst `Checksum Neutral` bleibt. Das RFC gibt auch Beispiele dazu, wie das geht. Daher grob meine Idee: - Vermutlich wäre das schlauste weiterhin das *WKP* `64:ff9b::/96` beizubehalten, aber es RFC 6052 -konform zu betreiben. - Zusätzlich dazu können wir dann ein zweites Prefix aus `64:ff9b:1::/48` nutzen und das Routing und die Übersetzung ins interne Netz und Internet dort bereitstellen. - Man müsste noch einmal die Kompatibilität mit Clientgeräten prüfen. (`ra_pref64` Option, z.B.) - Wir brauchen auch einen weiteren DNS64 Dienst, der auf das neue Prefix umsetzt

jkimmel commented

2024-01-22 03:39:04 +01:00

https://mailarchive.ietf.org/arch/msg/behave/neViYve8FjxIhbqkKutSa4Q_nQs/

Das Problem wurde auch auf der IETF Mailingliste diskutiert.

https://mailarchive.ietf.org/arch/msg/behave/neViYve8FjxIhbqkKutSa4Q_nQs/ Das Problem wurde auch auf der IETF Mailingliste diskutiert.

ChristianD commented

2024-01-30 18:10:21 +01:00

Gerne optional aktivierbar machen wie es aktuell bei SNAT schon der Fall ist aber bitte nicht dauerhaft default an.

ChristianD commented

2024-04-07 19:11:07 +02:00

Ich hab gerade versucht 108 mit dnsmasq in einen Bastelnetz (weit außerhalb unserer Firmware) einzurichten.

Mein sowieso schon sehr zickiges Handy Realme RMX3363 (es mag sich auch in keine WLANs verbinden wenn gar kein v4 da ist) verbindet sich nicht mehr zum WLAN sobald 108 angeschaltet ist. Honor 8 mit Android 7 connectet holt sich aber dennoch eine v4 (vermutlich zu alt?) ansonsten habe ich gerade nichts mehr zum testen da /edit mit Fedora 39 problemloses connecten holt sich aber eine v4.

Wollte diese Erfahrung nur mal festhalten das es auf der Welt u.U. Handys gibt die solche WLANs dann gar nicht mehr wollen (auch wenn es sehr nach kaputten Handysoftware klingt)

Ich hab gerade versucht 108 mit dnsmasq in einen Bastelnetz (weit außerhalb unserer Firmware) einzurichten. Mein sowieso schon sehr zickiges Handy Realme RMX3363 (es mag sich auch in keine WLANs verbinden wenn gar kein v4 da ist) verbindet sich nicht mehr zum WLAN sobald 108 angeschaltet ist. Honor 8 mit Android 7 connectet holt sich aber dennoch eine v4 (vermutlich zu alt?) ansonsten habe ich gerade nichts mehr zum testen da /edit mit Fedora 39 problemloses connecten holt sich aber eine v4. Wollte diese Erfahrung nur mal festhalten das es auf der Welt u.U. Handys gibt die solche WLANs dann gar nicht mehr wollen (auch wenn es sehr nach kaputten Handysoftware klingt)

Sign in to join this conversation.