Tayga as NAT64 only, not router

[Dick Visser]

On 28 February 2012 15:24, Dick Visser <visser at terena.org> wrote:
>
> Any ideas?

I managed to get things working in the end, and dedicated a /27 for testing.
But now my problem is that because of IPv6 hosts changing their
addresses too quickly, that range is quickly consumed up:


root at pavlov:~# tayga -d
starting TAYGA 0.9.2
Using tun device nat64 with MTU 1500
TAYGA's IPv4 address: 192.87.38.2
TAYGA's IPv6 address: 2001:610:148:ffff:b0b0:0:c057:2602
NAT64 prefix: 2001:610:148:ffff:b0b0::/96
Dynamic pool: 192.87.38.32/27
assigned new pool address 192.87.38.52 (2001:610:148:b0b0:d1b7:7544:3e47:ca97)
assigned new pool address 192.87.38.53 (2001:610:148:b0b0:7041:dcc5:8c8d:ec7d)
assigned new pool address 192.87.38.40 (2001:610:148:b0b0:b1d7:c290:2a6a:a3e9)
assigned new pool address 192.87.38.54 (2001:610:148:b0b0:d841:b61e:5b4c:c219)
assigned new pool address 192.87.38.37 (2001:610:148:b0b0:165a:5ff:fede:1a94)
assigned new pool address 192.87.38.39 (2001:610:148:b0b0:295e:19a9:ee9e:e847)
assigned new pool address 192.87.38.58 (2001:610:148:b0b0:9924:6611:916:9b60)
assigned new pool address 192.87.38.35 (2001:610:148:b0b0:cc4c:9354:4d79:ce52)
assigned new pool address 192.87.38.60 (2001:610:148:b0b0:1ccd:2e40:b73c:a9fc)
assigned new pool address 192.87.38.44 (2001:610:148:b0b0:4d8c:ee5c:9801:e452)
assigned new pool address 192.87.38.55 (2001:610:148:b0b0:1829:8495:6024:8414)
assigned new pool address 192.87.38.33 (2001:610:148:b0b0:b8e8:34e9:3f44:90d)
assigned new pool address 192.87.38.50 (2001:610:148:b0b0:c8c2:8759:64cb:b1c3)
assigned new pool address 192.87.38.36 (2001:610:148:b0b0:3030:378f:6410:2d53)
assigned new pool address 192.87.38.61 (2001:610:148:b0b0:7972:dbd2:7c63:7e09)
assigned new pool address 192.87.38.59 (2001:610:148:b0b0:3d80:5abc:9719:706a)
assigned new pool address 192.87.38.38 (2001:610:148:b0b0:75b2:5d5c:bd21:d1fc)
assigned new pool address 192.87.38.62 (2001:610:148:b0b0:accc:c880:3c1a:47ee)
assigned new pool address 192.87.38.48 (2001:610:148:b0b0:79f7:e121:f91f:f43)
assigned new pool address 192.87.38.42 (2001:610:148:b0b0:e51e:ce06:5899:77be)
assigned new pool address 192.87.38.56 (2001:610:148:b0b0:3858:f9c1:18d0:da8e)
assigned new pool address 192.87.38.41 (2001:610:148:b0b0:c0:27a7:8436:6892)
assigned new pool address 192.87.38.49 (2001:610:148:b0b0:7952:3ac9:97b9:4d09)
assigned new pool address 192.87.38.47 (2001:610:148:b0b0:acdb:ea18:3f8b:402)
assigned new pool address 192.87.38.57 (2001:610:148:b0b0:397f:83c7:ead8:ec64)
assigned new pool address 192.87.38.63 (2001:610:148:cafe::2)
assigned new pool address 192.87.38.34 (2001:610:148:b0b0:80c2:2ec1:9a39:d5ea)
assigned new pool address 192.87.38.43 (2001:610:148:b0b0:4d6:f53e:e01d:2cbf)
assigned new pool address 192.87.38.45 (2001:610:148:b0b0:a41d:967a:146b:28df)
assigned new pool address 192.87.38.46 (2001:610:148:b0b0:b4c0:21cf:cf9:3852)
assigned new pool address 192.87.38.51 (2001:610:148:b0b0:c5d6:c688:eff2:2c40)

At this point I see the (documented) behaviour:

# If no unassigned addresses remain in the dynamic pool (or no dynamic pool is
# configured), packets from unknown IPv6 hosts will be rejected with an ICMP
# unreachable error.

I guess adding a MASQUERADE step using a large enough RFC1918 block is
the only way out here?



-- 
Dick Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands