Thread border router 1.0.0

[Mary]

I am following the Thread Border Router example and have successfully loaded RaspPi_OT_Border_Router_Demo_v1.0.0-1.alpha.img onto the RaspberryPi 3B+.

I have loaded the NCP example onto a Nordic Semi nRF52840 development board, and connected it the the Raspberry Pi.  I have loaded the CLI example onto another development board.

I can successfully ping between the two Thread nodes, but not outside to my PC or to google as described in the example.

I am using nRF_SDK_for_Thread_and_Zigbee_v1.0.0

Rasp Pi:  border_router.conf

# Thread Network Configuration
thread_network_key="00112233445566778899AABBCCDDEEFF"
thread_channel="11"
thread_panid="0xABCD"
thread_xpanid="DEAD00BEEF00CAFE"
thread_network_name="NordicOpenThread"
thread_pskc="E00F739803E92CB42DAA7CCE1D2A394D"
thread_on_mesh_prefix="fd11:22::"

Rasp Pi: ifconfig:

pi@raspberrypi:/etc $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.72  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2600:XXXX:XXXX:96c0:ba27:ebff:fe94:7933  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::ba27:ebff:fe94:7933  prefixlen 64  scopeid 0x20<link>
        inet6 2600:xxxx:xxxx:96c0::5c5  prefixlen 128  scopeid 0x0<global>
        ether b8:27:eb:94:79:33  txqueuelen 1000  (Ethernet)
        RX packets 6104  bytes 545078 (532.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5457  bytes 1174736 (1.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


nat64: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 192.168.255.1  netmask 255.255.255.255  destination 192.168.255.1
        inet6 fdaa:bb:1::1  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::73b8:21d2:47dc:cf7  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4  bytes 304 (304.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


wpan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet6 fd11:22::540c:ed30:4494:6a9c  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::540c:ed30:4494:6a9c  prefixlen 64  scopeid 0x20<link>
        inet6 fe80::3bdd:44c5:d59c:102e  prefixlen 64  scopeid 0x20<link>
        inet6 fdde:ad00:beef:0:a610:e28d:369:454e  prefixlen 64  scopeid 0x0<global>
        inet6 2600:XXXX:XXXX:96c9:1000::1  prefixlen 68  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 1  bytes 56 (56.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 1371 (1.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

CLI node:

>ipaddr
2600:XXXX:XXXX:96c9:ee61:43f6:eb74:b3e8
fd11:22:0:0:29e0:308e:1b41:a566
fdde:ad00:beef:0:0:ff:fe00:fc00
fdde:ad00:beef:0:0:ff:fe00:6800
fe80:0:0:0:8803:5bb9:52c6:1591
fdde:add0:beef:0:35da:1ab0:72b9:2919

The suggested command on the CLI node to test

>ping 64:ff9b::0808:0808

returns nothing

The following (and many other combinations) also return nothing:

>ping 2600::XXXX:XXXX:96c9::0808:0808

>ping fdde:ad00:beef::0808:0808

But this one succeeds

>ping fd11:22::540c:ed30:4494:6a9c

returns "8 bytes from fd11:22:0:0:540c:ed30:4494:6a9c: icmp_seq=5 hlim=64 time=74ms"

The ipv6 prefixes do not seem to match on the Raspberry Pi and the CLI node:

RaspPi eth0:      inet6 2600::XXXX:XXXX:96c0:ba27:ebff:fe94:7933  prefixlen 64  scopeid 0x0<global>

RaspPi wpan0:  inet6 2600::XXXX:XXXX:96c9:1000::1 prefixlen 68 scopeid 0x0<global>
 

Is this correct?  If not, how to fix it?

Mary

[Piotr Szkotak]

Hi Mary,

At the first glance it looks fine.

Let's start from checking connectivity at the RPi.

1. Can you 'ping 8.8.8.8' from the Raspberry?

I see that you have global IPv6 connectivity. 

2. Can you 'ping6 2001:4860:4860::8888' from the Raspberry?

3. In case of CLI we can also try 'ping 2001:4860:4860::8888'?

 

Please let me know what is output of these three commands.

What provides network connection to the Raspberry? Is it the same as for your PC?

Kind Regards,

Piotr Szkotak

[Mary]

1.  Yes, I can ping 8.8.8.8 from Raspberry Pi

pi@raspberrypi:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=31.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=32.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=36.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=30.5 ms

2. Yes, I can ping6 from Raspberry Pi

pi@raspberrypi:~ $ ping6 2001:4860:4860::8888
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=58 time=31.5 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=58 time=32.3 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=58 time=30.5 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=4 ttl=58 time=31.6 ms

3. ping from CLI returned nothing

> ping 2001:4860:4860::8888
>

Raspberry Pi is connected to our office network via Ethernet cable, through a switch to our router.  

Raspberry Pi network configuration as reported by the router:

My PC is connected in similar fashion, though the same switch to the same router.

Mary

[Mary]

Several minutes later this appeared on the Rasp Pi:

15:37:51.000429 IP6 2600:xxxx:xxxx:96c9:1000::1.48378 > ff33:40:fdde:ad00:beef::1.47193: UDP, length 5

[Mary]

Is someone working on this? It's an important feature for our project.

[Piotr Szkotak]

These examples are precommissioned. The communication between CLI and NCP is fine.

In such case there is no need to perform commissioning.

I think that we need to split the communication issue into two parts:

1. Native IPv6 not working. (2600 prefix).

2. NAT64 communication not working (64:ff9b prefix).

Regarding the 1. I see that router assigned prefix /64 to the raspberry. If this is really true the Thread should not even obtain this prefix as it is too long. The Thread itself needs /64, meaning that the raspberry should get shorter one, e.g. /62 to bo able to exclusively give /64 to Thread.

We can confirm length of obtained prefix by checking the routing table on the raspberry with 'ip -6 route'.

There you will see 26xx prefix on eth0 with its length in a form:

2600:aaaa:bbbb:cccc::/64 dev eth0 proto ra metric 100 pref medium

/64 means we are out of luck.

In case of NAT64 the traffic on the raspberry is handled differently. There is additional nat64 interface involved. In this case the IPv6 packets go from wpan0 interface to nat64 where translation to IPv4 takes place and IPv4 packets go to the eth0 or wlan0 depending if wired or wireless connection is used.

In this case we should track packets when using 64:ff9b destination.'ping 64:ff9b::808:808' is excellent as the destination is in fact Google's 8.8.8.8 IPv4 address embedded in IPv6 address. I highly recommend pinigng 64:ff9b::0808:0808 from the CLI and checking IPv6 traffic on wpan0 and nat64 interfaces and IPv4 traffic on nat64 and eth0.

 

I would execute 'tcpdump -i wpan0 -nv icmp6 or icmp' and ping 64:ff9b::808:808 from CLI.

then tcpdump -i nat64 -nv icmp6 or icmp and ping again,

and tcpdump -i eth0 -nv icmp6 or icmp and ping the last time.

 

Kind regards,

Piotr

 

[Mary]

1. RaspPi

pi@raspberrypi:~ $ ip -6 route
64:ff9b::/96 dev nat64 metric 1024  pref medium
2600:xxxx:xxxx:96c0::/64 dev eth0 proto kernel metric 256  expires 1209485sec pref medium
2600:xxxx:xxxx:96c9:1000::/68 dev wpan0 proto kernel metric 204  pref medium
unreachable 2600:xxxx:xxxx:96c9::/64 dev lo metric 201  error -113 pref medium
fd11:22::/64 dev wpan0 proto kernel metric 256  pref medium
fdaa:bb:1::1 dev nat64 proto kernel metric 256  pref medium
fdde:ad00:beef::/64 dev wpan0 proto kernel metric 256  pref medium
fe80::/64 dev wlan0 proto kernel metric 256  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev wpan0 proto kernel metric 256  pref medium
fe80::/64 dev nat64 proto kernel metric 256  pref medium
default via fe80::e222:4ff:fe91:86b9 dev eth0 proto ra metric 1024  expires 1685sec hoplimit 64 pref medium

'tcpdump -i wpan0 -nv icmp6 or icmp' and ping 64:ff9b::808:808 from CLI.

<Nothing on RaspPi>

 tcpdump -i nat64 -nv icmp6 or icmp and ping again

<Nothing on RaspPi>

tcpdump -i eth0 -nv icmp6 or icmp and ping

<Nothing on RaspPi>

We will look into adjusting the prefix length at the router.

Mary

[Mary]

We have an AT&T router that assigned 64 bit prefixes.  We don't seem to be able to change that.  Is Thread configurable in this regard?  Is it possible to set it to use a longer prefix?

[Mary]

From this page

NoteWhen dealing with native IPv6 connectivity, make sure you use the DHCPv6 service, and not the popular Stateless Address Autoconfiguration (SLAAC) tool. This autoconfig tool will only provide a 64-bit long prefix that is not sufficient to delegate a new 64-bit long prefix for the Thread network.

Do they mean on the RaspPi?  Is the image I downloaded not already set up properly? How can I check?

[Piotr Szkotak]

The requirement is that /64 bit prefix needs to be passed to the Thread Network so the SLAAC mechanism is used for the address generation.

I am not aware of any exceptions in that matter.

In theory it should be possible to create additional local IPv6 network for Thread only and perform IPv6 to IPv6 translation (NAT66) to addresses from the global pool. It looks like a huge workaround and the fact that Thread nodes generate randomly their addresses with SLAAC which will not make things easier.

Please note that this is just a theoretical consideration, I am not aware of any attempts taken.

Typical solutions are sticking with NAT64 (with its limitation that the Thread node cannot be reached from the outside world as it does not have a globally reachable address) or contacting Internet Service Provider to provide shorter IPv6 prefix.

Your attempts with do not look good, did you wait after executing ping on the CLI? It can take some time to see any output on the Raspberrys terminal in case of tcpdump.

Is your configuration or image modified anyhow compared to the released versions?

Edit. Regarding your post that appeared when I was writing mine:

Image is configured correctly, paragraph you mentioned is about network equipment used at home or office.

Even if your ISP delegates you prefix that is good enough, lets say /56 the router you connect Raspberry to sometimes delegates /64 to the Raspberry even if it could delegate shorter one.

There are two ways of passing prefix to the next router/device, DHCPv6 is very configurable and can share specified address lengh and SLAAC which operates on fixed /64.

Usually this can be configured in the router panel. Bad news is that many devices provide limited configuration or even do not lack of proper support of these features. From our experience OpenWRT custom firmware provides good support in this regard.

To be honest issues with NAT64 bother me more as this is the configuration that works out of the box in all cases.

I'm wondering if this can be related to your ISP or the AT&T router.

Could you check setup with the different connection? Wi-Fi hotspot shared from the smartphone should be sufficient to check the NAT64.

When all fails also the previous release (0.11.0) can be checked as that border router is completely different since it is based on OpenWRT not the Raspbian.

Kind Regards,

Piotr

[Mary]

I re-ran the tcpdum/ping tests and waited a bit.  I only got a response (and yes, delayed) for the eth0 test.

pi@raspberrypi:/etc $ sudo tcpdump -i eth0 -nv icmp6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:39:00.763050 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 112) fe80::e222:4ff:fe91:86b9 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 112
        hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2600:xxxx:xxxx:96c0::/64, Flags [onlink, auto], valid time 1209600s, pref. time 1209600s
          route info option (24), length 24 (3):  2600:xxxx:xxxx:96c0::/60, pref=high, lifetime=1209600s
          rdnss option (25), length 24 (3):  lifetime 1200s, addr: 2600:1702:1d70:96c0::1
          mtu option (5), length 8 (1):  1500
          source link-address option (1), length 8 (1): e0:22:04:91:86:b9
15:39:01.489607 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ffbb:bcae: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:c895:87f1:1ebb:bcae
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489610 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ffe0:ea4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:ec1d:637f:b8e0:ea4
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489612 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff4d:341b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:95a6:eefe:9f4d:341b
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489614 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff83:1906: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:06c0:d987:6590:fb83:1906
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489616 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff29:3c7c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:3ddd:7acd:5029:3c7c
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489618 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff09:de88: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:7487:e816:d409:de88
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.491090 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff63:8caa: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:79a8:d89e:2e63:8caa
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.489602 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ffbb:bcae: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:c895:87f1:1ebb:bcae
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.489603 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ffe0:ea4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:ec1d:637f:b8e0:ea4
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490234 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff4d:341b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:95a6:eefe:9f4d:341b
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490237 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff83:1906: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:d987:6590:fb83:1906
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490239 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff29:3c7c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:3ddd:7acd:5029:3c7c
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490241 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff09:de88: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:7487:e816:d409:de88
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490242 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff63:8caa: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:79a8:d89e:2e63:8caa
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1

Similar messages appeared periodically after these.

No, I have not modified the RaspPi at all, except to install tcpdump.

I will try WiFi on the Pi.

[Piotr Szkotak]

Unfortunately these are not ICMP echo request / echo response packets we hoped to see.

Let's perform one more test related to the persistent storage that may cause some issues.

On the CLI:

>factoryreset

On the RPi:

sudo wpanctl dataset erase && sudo reboot

after it boots you can connect to the wifi with:

wifi_connect WIFI_SSID WIFI_PASSWORD

then on the CLI:

> panid 0xabcd
Done
> ifconfig up
Done
> thread start
Done
> state
child
Done
> ipaddr
fdde:ad00:beef:0:0:ff:fe00:6403
fdde:ad00:beef:0:eb88:663:f303:3605
fe80:0:0:0:840f:5266:381:6e2f
Done
> dns resolve ipv4.google.com fdaa:bb:1::1
> DNS response for ipv4.google.com - [64:ff9b:0:0:0:0:d83a:d5ee] TTL: 300
ping 64:ff9b:0:0:0:0:d83a:d5ee
> 8 bytes from 64:ff9b:0:0:0:0:d83a:d5ee: icmp_seq=1 hlim=51 time=61ms

Please let me know if your results are different than mine.

Which board revision is being used (0.9.0/0.9.2/0.10.0/0.11.0)?

If different than 0.9.2 we highly recommend using usb/hex with the native USB port instead of communicationg over the Segger USB port.

Kind regards,

Piotr 

[Mary]

I was not able to connect the RaspPi to our wifi network.

I tried this method first, as described here. Our network is hidden and does not appear in the list returned by iwlist wlan0 scan. I know the SSID and password and used that.

wifi_connect mynetwork mypassword

The network settings remain unchanged and the BorderRouter-AP was still present, and even after rebooting the RaspPi.

pi@raspberrypi:~ $ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.42.0.1 netmask 255.255.255.0 broadcast 10.42.0.255
inet6 fe80::ba27:ebff:fec1:2c66 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:c1:2c:66 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 3 overruns 0 frame 0
TX packets 2893 bytes 738594 (721.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I also tried the method described here. I modified /etc/wpa_supplicant/wpa_supplicant.conf as described in the "Hidden Networks" section.

Again, the network setting remain unchanged and the BorderRouter-AP was still present, and even after rebooting the RaspPi.

That was yesterday.

Today I ran the steps you suggested:

On the RPi:

sudo wpanctl dataset erase && sudo reboot

after it booted,  connected to the wifi with:

wifi_connect WIFI_SSID WIFI_PASSWORD

pi@raspberrypi:~ $ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.42.0.1 netmask 255.255.255.0 broadcast 10.42.0.255
inet6 fe80::ba27:ebff:fec1:2c66 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:c1:2c:66 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 222 bytes 51710 (50.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Still no wifi on the RaspPi

On the CLI:

> factoryreset

> panid
ffff
Done
> panid 0xabcd
Done
> ifconfig up
Done
> thread start
Done
> state
child
Done
> ipaddr
2600:xxxx:xxxx:96c9:749c:c6c0:3335:2885
fd11:22:0:0:a6f:3b1f:9593:a6db
fdde:ad00:beef:0:0:ff:fe00:5802
fdde:ad00:beef:0:3480:6ccc:eb32:87f3
fe80:0:0:0:707e:253d:f2ed:a6f8
Done
> dns resolve ip4.google.com fdaa:bb:1::1
> DNS response for ip4.google.com - Error 1: Failed

The board rev is 1.0.0 (as printed on the sticker).

Mary