Re: [Snac] where/how to document NAT64 (and DNS64)?

[Michael Richardson <[e-mail]>]

Ted Lemon <[e-mail]> wrote:
    > I think Michael was talking about the stub network router
    > advertisement, which is /sent/ by the stub router. FWIW, it’s no
    > problem to get ICMP messages in user land. My implementation does this
    > both on MacOS and Linux with no trouble.

Ditto, but I'm speaking about RPL (RFC6550), which uses ICMPv6 messages everywhere,
and sends/receives RAs as well.
On Linux, turning off kernel processing of RA amounts to two or three
sysctls, depending upon exactly what you want.

For RIOT/Zephyr/Contiki/etc. based IoT devices... well, if you want to
process something you wind up writing some code in the "kernel"

I think that bigger question that this thread is asking is whether or not the
stub router has to implement the NAT64.  Is there some involvement with a
state machine that requires it?

a) should it only enable it when it knows/thinks/suspects that there is no
   IPv6 uplink?

b) or should it always implement/announce NAT64 and let the devices decide
   what works better for them?

c) is there a way to detect if there even is an IPv4 uplink?  DHCPv4 has this
   fault that it can't not announce a default route.
   Do we even care here?

An advantage of (b) is that we don't have to turn it on/off.

The stub router just says, "here is some IPv6 places I can get to,
here is a way that I think works for IPv4 places, you figure what's good for you"

Each path is just a different IPv6 route.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-