Re: [RFC net-next 15/15] Documentation: networking: add ipxlat translator guide

[Daniel Gröber]

On Mon, Apr 06, 2026 at 10:50:44PM +0800, Xavier Hsinyuan wrote:
> >+    $ ./tools/net/ynl/pyynl/cli.py --family ipxlat --json '{"ifindex": $IID, \
> >+        "config": {"xlat-prefix6": "'$HEX_ADDR'", "prefix-len": 96} }'
> Should this be like:
> $ python3 /extends/pyynl/cli.py --spec ipxlat.yaml --do dev-set --json \
> '{"ifindex": "'$IID'", "config": {"xlat-prefix6": \
> {"prefix":"'$ADDR_HEX'", "prefix-len": 96}}}'

Indeed, the JSON is just wrong and --do dev-set is missing. However
`--family ipxlat` works for me and looking at the code is basically the
same as specifying --spec.

Could you try this:

    $ JSON='{"ifindex": '"$IID"', "config": {"xlat-prefix6": { "prefix": "'$ADDR_HEX'", "prefix-len": 96}}}'
    $ ./tools/net/ynl/pyynl/cli.py --family ipxlat --do dev-set --json "$JSON"

> >+Address Translation
> >+-------------------
> >+
> >+The ipxlat address translation algorithm is stateless, per RFC-ADDR_, all
> >+possible IPv4 addressess are mapped one-to-one into the translation prefix,
> >+optionally including a non-standard "suffix". See `RFC-ADDR Section 2.2
> >+<https://datatracker.ietf.org/doc/html/rfc6052#section-2.2>`_.
> >+
> >+.. _RFC-ADDR: https://datatracker.ietf.org/doc/html/rfc6052
> >+
> >+IPv6 addressess outside this prefix are rejected with ICMPv6 errors with
> >+the notable exception of ICMPv6 errors originating from untranslatable
> >+source addressess. These are translated to be sourced from the IPv4 Dummy
> >+Address ``192.0.0.8`` (per I-D-dummy_) instead to maintain IPv4 traceroute
> >+visibility.
>
> Would it help to add a few example? For instance,
>  - Interface ipxlat0 with prefix6=64:ff9b::/96.
>  - A IPv6 packet with src=64:ff9b::192.0.2.1 dst=64:ff9b::198.51.100.1,
>    was send to ipxlat0.
>  - Then a IPv4 packet with src=192.0.2.1 dst=198.51.100.1 was received from
>    ipxlat0.

I worry once we start with that we're really just re-stating what's already
extensively documented in the RFCs.

How about a reference to RFC 7915 Appendix A? This has a full bidirectional
end-to-end example of how translation operates:
https://datatracker.ietf.org/doc/html/rfc7915#appendix-A

Admittedly using a /96 prefix (which the appendix doesn't) would make it
easier to grok whats going on. Not sure that's reason enough to get into
more detailed examples here.

WDYT?

Thanks,
--Daniel