Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

Tayga as NAT64 only, not router

 

 

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


visser at terena

Feb 28, 2012, 6:24 AM

Post #1 of 6 (2325 views)
Permalink
Tayga as NAT64 only, not router

Hi
I am in the process of setting up an IPv6 only network, and finally
gave up on Ecdysis because it kept crashing the VM that it ran on.
Next candidate is Tayga, but I'm having some trouble getting things to
work there as well.

I have set-up a couple of things:

VLAN20: IPv6 only, 2001:610:148:b0b0::/64, gateway
2001:610:148:b0b0::1. Does DHCPv6+RA etc.
VLAN6: IPv4 network, 192.87.38.0/24.

I designated 2001:610:148:b0b0:ffff::/96 as our NAT64 prefix.

I have a VM running Ubuntu 10.04, which has two interfaces, one in each VLAN.

All the examples for Tayga seem to assume that the Tayga box itself
acts as the router for IPv6 clients.
In my set-up this is not the case, our Cisco does that.

So stuff like "(replace with your router's IPv4 address)" does not
make sense for my set-up.
I suspect my set-up could actually be rather simple, but I can't wrap
my head around it.

Any ideas?


I did mail the maintainer several weeks ago but did not get a response...


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


bjorn at mork

Feb 28, 2012, 6:39 AM

Post #2 of 6 (2257 views)
Permalink
Re: Tayga as NAT64 only, not router [In reply to]

Dick Visser <visser [at] terena> writes:

> Hi
> I am in the process of setting up an IPv6 only network, and finally
> gave up on Ecdysis because it kept crashing the VM that it ran on.
> Next candidate is Tayga, but I'm having some trouble getting things to
> work there as well.
>
> I have set-up a couple of things:
>
> VLAN20: IPv6 only, 2001:610:148:b0b0::/64, gateway
> 2001:610:148:b0b0::1. Does DHCPv6+RA etc.
> VLAN6: IPv4 network, 192.87.38.0/24.
>
> I designated 2001:610:148:b0b0:ffff::/96 as our NAT64 prefix.
>
> I have a VM running Ubuntu 10.04, which has two interfaces, one in each VLAN.
>
> All the examples for Tayga seem to assume that the Tayga box itself
> acts as the router for IPv6 clients.
> In my set-up this is not the case, our Cisco does that.
>
> So stuff like "(replace with your router's IPv4 address)" does not
> make sense for my set-up.
> I suspect my set-up could actually be rather simple, but I can't wrap
> my head around it.

The Tayga box needs to be a router, but you only need to route the IPv6
and IPv4 NAT64 prefixes through it. I.e.

on the Cisco router:
add static routes for your NAT64 prefix and the IPv4 addresses you are
going to translate it to, pointing to your Tayga box

on the Tayga box:
add default IPv4 and IPv6 routes pointing to your router
set up Tayga as if it was the only router in the network



Bjørn


visser at terena

Mar 16, 2012, 11:51 AM

Post #3 of 6 (2189 views)
Permalink
Re: Tayga as NAT64 only, not router [In reply to]

On 28 February 2012 15:24, Dick Visser <visser [at] terena> 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] pavlo:~# 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


andy at nosignal

Mar 18, 2012, 3:15 PM

Post #4 of 6 (2133 views)
Permalink
Re: Tayga as NAT64 only, not router [In reply to]

On 16 Mar 2012, at 18:51, Dick Visser wrote:

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

Or using a stateful NAT64 (*vomit in mouth*) gateway ? Have you considered this ? Is the software availability good ?

I ask because, well, if each v6 client will consume a v4 address on the 64 gateway, this does not help us sidestep the v4 exhaustion issue very cleanly. :-)

Andy


bjorn at mork

Mar 19, 2012, 1:50 AM

Post #5 of 6 (2183 views)
Permalink
Re: Tayga as NAT64 only, not router [In reply to]

Andy Davidson <andy [at] nosignal> writes:
> On 16 Mar 2012, at 18:51, Dick Visser wrote:
>
>> I guess adding a MASQUERADE step using a large enough RFC1918 block
>> is the only way out here?
>
> Or using a stateful NAT64 (*vomit in mouth*) gateway ? Have you
> considered this ? Is the software availability good ?

Won't tayga + masquerading equal stateful NAT64? Is there any better
solution? Somehow I don't see any advantages to doing this in one step
instead of two simple ones.

> I ask because, well, if each v6 client will consume a v4 address on
> the 64 gateway, this does not help us sidestep the v4 exhaustion issue
> very cleanly. :-)

Only the ones actually needing access to the v4 Internet.

By implementing a few application specific solutions on IPv6 (like http
proxy and smtp gateway) and agressivily filtering unwanted IPv4 traffic,
you can easily keep that number considerably lower than "all clients".


Bjørn


visser at terena

Mar 19, 2012, 3:47 AM

Post #6 of 6 (2148 views)
Permalink
Re: Tayga as NAT64 only, not router [In reply to]

On 16 March 2012 19:51, Dick Visser <visser [at] terena> wrote:
> # 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?

I added masquerading using 192.168.0.0/18 and that works fine.
DHCPv6 runs, DNS server does DNS64.
I've opened up our wireless network to allow everyone access to it.

Windows 7 and OSX 10.7 work fine right out of the box.
But iOS 5.1 cannot connect - anyone else had any luck with iphones and
IPv6 only networks?
I remember that with the latest iOS4 phones it did work....

DIck



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

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.