Yes, I tried to learn this technology through the logs. Originally, I thought the reason was that I hadn't added an IPv6 network interface address. According to discussions in the OpenZiti community, the default address is 100.64.0.0. It seems that the failure might be due to an issue with the intercepted IPv6 address.
ERROR ziti-edge-tunnel:utils.c:31 run_command_va() cmd{ip route add 100.64.0.0/10 dev ziti5} failed: 512/0/Success
system(ip route add 100.64.0.0/10 dev ziti5) returned 512
INFO tunnel-sdk:ziti_tunnel.c:60 create_tunneler_ctx() Ziti Tunneler SDK (v1.0.2)
DEBUG tunnel-sdk:ziti_tunnel.c:320 ziti_tunneler_intercept() intercepting address[tcp:2768:8631:c02:ffc9::1308/128:80] service[svc]
DEBUG tunnel-sdk:ziti_tunnel.c:320 ziti_tunneler_intercept() intercepting address[tcp:2768:8631:c02:ffc9::1308/128:9000] service[svc]
INFO tunnel-cbs:ziti_tunnel_ctrl.c:727 on_service() starting intercepting for service[svc]
TRACE ziti-edge-tunnel:instance.c:272 to_address() IP address: 2768:8631:c02:ffc9::1308
INFO ziti-edge-tunnel:ziti-edge-tunnel.c:1291 on_event() =============== service event (added) - svc:5Av8PBOp0hdXWnyLwQPhW8 ===============
DEBUG ziti-sdk:ziti_ctrl.c:726 ctrl_paging_req() ctrl[www.ipv6test-ctrl.com] starting paging request GET[/current-identity/edge-routers]
VERBOSE ziti-sdk:ziti_ctrl.c:731 ctrl_paging_req() ctrl[www.ipv6test-ctrl.com] requesting /current-identity/edge-routers?limit=25&offset=0
VERBOSE ziti-sdk:ziti_ctrl.c:143 start_request() ctrl[www.ipv6test-ctrl.com] starting GET[/current-identity/edge-routers?limit=25&offset=0]
VERBOSE ziti-sdk:ziti_ctrl.c:143 start_request() ctrl[www.ipv6test-ctrl.com] starting GET[/current-api-session/service-updates]
VERBOSE ziti-sdk:ziti_ctrl.c:178 ctrl_resp_cb() ctrl[www.ipv6test-ctrl.com] received headers GET[/current-identity/edge-routers?limit=25&offset=0]
DEBUG ziti-sdk:ziti_ctrl.c:334 ctrl_body_cb() ctrl[www.ipv6test-ctrl.com] completed GET[/current-identity/edge-routers?limit=25&offset=0] in 0.211 s
DEBUG ziti-sdk:ziti_ctrl.c:351 ctrl_body_cb() ctrl[www.ipv6test-ctrl.com] received 1/1 for paging request GET[/current-identity/edge-routers]
DEBUG ziti-sdk:ziti_ctrl.c:363 ctrl_body_cb() ctrl[www.ipv6test-ctrl.com] completed paging request GET[/current-identity/edge-routers] in 0.211 s
VERBOSE ziti-sdk:ziti_ctrl.c:178 ctrl_resp_cb() ctrl[www.ipv6test-ctrl.com] received headers GET[/current-api-session/service-updates]
DEBUG ziti-sdk:ziti_ctrl.c:334 ctrl_body_cb() ctrl[www.ipv6test-ctrl.com] completed GET[/current-api-session/service-updates] in 0.212 s
VERBOSE ziti-sdk:ziti.c:1272 check_service_update() ztx[0] not updating: last_update is same previous (2024-06-18T00:42:42.610Z == 2024-06-18T00:42:42.610Z)
VERBOSE ziti-sdk:ziti.c:1302 ziti_services_refresh() ztx[0] scheduling service refresh 10 seconds from now
DEBUG tunnel-sdk:tunnel_udp.c:270 recv_udp() intercepted address[udp:100.64.0.2:53] client[udp:100.64.0.1:34960] service[ziti:dns-resolver]
Well, the 100.64/10 address is the default CIDR for IP addresses that the tunneler assigns for hostnames that appear in the intercept.v1 addresses list. This has no relationship at all to intercepting ipv6 IPs.
By the way, it looks like you are running multiple instances of ziti-edge-tunnel, all using the same dns CIDR range. This will be a problem because each ziti-edge-tunnel instance needs a unique IP address and range. Unless you're doing something special you probably only want to have one ziti-edge-tunnel running on a host. If you really do need multiple ziti-edge-tunnel processes then you'll need to give each one a unique dns IP range with the -d option.
The IPv6 address for the tun (ziti0) network interface should come from auto configuration on Linux. Here's how I start ziti-edge-tunnel:
ziti-edge-tunnel run -I "${HOME}/ziti/identities -d 100.64.10.1/24 -v6
And here's what my ziti0 device looks like:
$ ip addr show type tun
5: ziti0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet 100.64.10.1/32 scope global ziti0
valid_lft forever preferred_lft forever
inet6 fe80::de86:2618:a814:b6db/64 scope link stable-privacy proto kernel_ll
valid_lft forever preferred_lft forever
Notice that an IPv6 address has been assigned to the device (by Linux) in addition to the IPv4 address that ziti-edge-tunnel configured it with.
Thank you for your reply! I have reviewed the logs you sent me. You mentioned using the TCP protocol, and the logs indicate that it can intercept IPv6 destination addresses. In my logs, 53/UDP is enabled by default, and I'm unsure how to switch to the TCP protocol. In 'instance.c', the intercepted address is '100.64.0.2', not the IPv6 destination address as in intercept.v1.
Regarding multiple instances, when I interrupt with 'ctrl+z' and rerun in the Linux CLI, I encounter the 'ziti n+1' situation.
If the tunnel can intercept IPv6 addresses, then my source address should be automatically set to an IPv6 address by the Linux system, not an IPv4 address. 

The service that you are seeing activity on port 53 is the tunneler's internal DNS server. It intercepts DNS packets as if they were a ziti service. So unless you are interested in the workings of the DNS server and its replies to clients, you can ignore the port 53 traffic.
In order to see the ipv6 intercept log messages you'll need to initiate a connection to the ipv6 address that you've associated with your service. When you do, you should see a "received segment" log message with the dst address matching your ipv6 intercept address. You should also see that the src address is ipv6:
[ 273.146] TRACE tunnel-sdk:tunnel_tcp.c:366 recv_tcp() received segment src[tcp:FDDE:3A82:F7EB:2329:F130:720E:B6DF:5656:38876] dst[tcp:2768:8631:C02:FFC9::1308:22] flags[SYN]
If you don't see the "received segment" message with the matching ipv6 dst address then I can only guess that there was a problem with setting up the route that directs packets to the tun interface. In this case please send the full log from ziti-edge-tunnel (from the time it was started to the time you tried intercepting the ipv6 address), as well as the output of ip -6 route show while ziti-edge-tunnel is running.
Thanks
Currently I use tunnel-c 1.0.2, ziti version 1.0.0, can't access it
My current process is to set the same ipv6 address and port in hostv1 and interceptv1, and then open tunnel-sdk-c to run. The browser cannot access the service by accessing [ipv6 address]:port. How do you achieve normal access?
Hi scareything，
I've sent you the log files (txt) from both the client and server to your email. Please refer to the second email titled "watch it."
Ok, I see another problem. The linux tunneler was receiving ipv6 packets and correctly associating them with an OpenZiti service, but it was unable to send ipv6 packets out through the tun interface. I have a fix that will be merged and released shortly...
edit:
ziti-edge-tunnel 1.0.3 is now available.
3 Likes
Hi scarething,
Access successful, thank you very much! 
1 Like
Hi scareything,
I failed to test IPv6 address access service in win-x64 environment. There is no interception of ipv6 addresses in the logs. There is a log showing that route addition failed.
Invalid IPV4 address [2768:8631:C02:FFC9::1308]
[2024-06-21T06:59:39.298Z] INFO tunnel-cbs:ziti_dns.c:292 new_ipv4_entry() registered DNS entry www.test.com -> 100.64.0.3
[2024-06-21T06:59:39.298Z] DEBUG tunnel-sdk:ziti_tunnel.c:321 ziti_tunneler_intercept() intercepting address[tcp:100.64.0.3/32:9000] service[svc]
[2024-06-21T06:59:39.298Z] DEBUG tunnel-sdk:ziti_tunnel.c:321 ziti_tunneler_intercept() intercepting address[tcp:2768:8631:C02:FFC9::1308/128:9000] service[svc]
[2024-06-21T06:59:39.298Z] DEBUG ziti-edge-tunnel:tun.c:381 tun_add_route() adding route: 100.64.0.3/32
[2024-06-21T06:59:39.298Z] DEBUG ziti-edge-tunnel:tun.c:381 tun_add_route() adding route: 2768:8631:C02:FFC9::1308/128
[2024-06-21T06:59:39.298Z] WARN ziti-edge-tunnel:tun.c:357 parse_route() invalid IPV4 route spec[2768:8631:C02:FFC9::1308/128]
[2024-06-21T06:59:41.052Z] TRACE ziti-edge-tunnel:tun.c:307 tun_read() starting read
[2024-06-21T06:59:41.052Z] TRACE tunnel-sdk:tunnel_udp.c:194 recv_udp() received datagram src[100.64.0.1:5353] dst[224.0.0.251:5353]
[2024-06-21T06:59:41.052Z] TRACE tunnel-sdk:tunnel_udp.c:218 recv_udp() no intercepted addresses match udp:224.0.0.251:5353
Hi scareything，
The macOS system attempted to access using an IPv6 address, but the logs indicate interception failure.