ipsidixit.net

IPv6 – Proxy the neighbors (or come back ARP – we loved you really)

March 24, 2010

After three articles, where am I with my venture in to IPv6? What have we really achieved so far? Well, in functional terms, not so very much yet!!

To recap:

• Here I covered a lot of ground, getting basic IPv6 running on a Linux gateway box connected to an ISP providing native IPv6, while remembering stuff like the need to set up a firewall.
• Here I looked at the issue of IPv6 firewall logging
• And here I looked at the need to set up a default route out of the gateway device pointing back towards the internet.

And what can I now actually do? Well……. from the gateway box I can ping out successfully to any IPv6 device on the Internet. In other words, logged in to the device in green on this diagram, I can ping out of eth0 over the Internet. And from an IPv6 device on the Internet I can successfully ping towards my green box, using the address of eth0. So I can ping from the Internet to (these are of course made-up addresses!) 123::456.

However if from my remote Internet location I ping instead the IPv6 address of eth1 (here 123::789) does it work? I might expect it to: after all, eth1 has a global IPv6 address on it, not a private address. So surely I can ping it?

Needless to say, as it stands I cannot. Here we look at why not – in the process covering an important element of turning our gateway device in to an IPv6 router (which, grand though it sounds, is exactly what we are doing here!) which receives very little coverage elsewhere on the Internet. In fact when researching this I came to a conclusion that the vast majority of folks who have dabbled with IPv6 in the domestic environment have terminated their ISP IPv6 connection on their workstation, and very few have gone the step further and used a device as a gateway to a home network!!

How to get through the gateway –  or Come back ARP, all is forgiven

So when I ping 123::789 what stops it working? The first thought is: firewall. We’re blocking it, right? A quick trip to the shorewall6 log (glad we set that up, eh?) shows us: nothing. Nowt. Zilch. Nada. Surprisingly, we’re not dropping the ping. (In fact the firewall config we set up in the first of these articles contains enough already to allow, from a firewall perspective, for this ping to succeed.)

So we now run tcpdump on eth0 to see just what is going on. Here’s an example:

From the remote host

From my remote IPv6 host I do and see:

ping6 2a01:e35:8b25:7ea0::22

PING 2a01:e35:8b25:7ea0::22(2a01:e35:8b25:7ea0::22) 56 data bytes

From 2a01:e35:8b25:7ea0::1 icmp_seq=1 Destination unreachable: Address unreachable

From 2a01:e35:8b25:7ea0::1 icmp_seq=2 Destination unreachable: Address unreachable

From 2a01:e35:8b25:7ea0::1 icmp_seq=3 Destination unreachable: Address unreachable

.

.

.

Which doesn’t tell me a lot.

On the gateway

On my gateway, from tcpdump, I see:

tcpdump -i eth0 -v ip6

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

08:51:35.315038 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:1a68 > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:e35:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

08:51:36.315002 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:1a68 > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:e35:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

08:51:37.315001 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:1a68 > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:e35:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

What does this tell me?

So the ping is reaching the gateway device alright. Sort of. Well, not really. But there’s something going on there! What we see in that tcpdump trace is the ISP’s router to which I’m connected is sending me a Neighbor Solicitation for the ::22 address (i.e. the global IPv6 address of my eth1 interface on the “far side” of my gateway which I’m trying to ping) While I’m not keen to draw too many parallels and comparisons with IPv4, it is useful to do so here: A Neighbor Solicitation is, at least as we see it here, pretty much analogous to a good ol’ ARP Request. The ISP is saying to us “I think this address is somewhere over with you – Please confirm and let me know how to reach it”. Which is great, except for the glaring fact that we appear to ignore this NS (Neighbor Solicitation) and hence the ping fails.

So you can guess we need to set something up on the gateway that tells it to reply to such a NS. (Kinda vaguely analogous to a Proxy ARP, if you’re familiar with that)

IPv6 Proxy

A couple of steps here. Firstly the system needs to be told globally to perform the required IPv6 proxying, and we then need to enable it for specific addresses.

proxy_ndp

In the /etc/sysctl.conf file add a line:

net.ipv6.conf.all.proxy_ndp = 1

To set this dynamically (without a reboot) you can also do:

sysctl -w net.ipv6.conf.all.proxy_ndp=1

Neighbor proxy

Then perform:

ip -6 neigh add proxy 2a01:e35:8b25:7ea0::22 dev eth0

Note that here the IPv6 address is the address of the interface on the private side of the gateway (eth1 for me). The end part “…dev eth0″ is to say “Proxy that address from this interface”.

You also, of course, will need to make such configuration permanent. Numerous approaches to that: I settled upon adding this from the interface-up scripts in /etc/network/if-up.d/ but there are so many other methods too. Pick yours.

(Interestingly, I have yet to discover any way at all to display the list of proxied neighbors added in this manner! I’ve looked pretty hard, but there appears to be no way I can find to have them listed. There must be a way, but I can’t find it.)

Success!

And the ping now works, with a tcpdump like this now showing to us:

09:18:18.644817 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:1a68 > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:e35:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

09:18:18.868550 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::240:63ff:fef5:f93c > fe80::207:cbff:fea5:1a68: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2a01:e35:8b25:7ea0::22, Flags [solicited]

destination link-address option (2), length 8 (1): 00:40:63:f5:f9:3c

09:18:18.868958 IP6 (hlim 56, next-header ICMPv6 (58) payload length: 64) ipsi6 > 2a01:e35:8b25:7ea0::22: ICMP6, echo request, length 64, seq 5

09:18:18.869107 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:e35:8b25:7ea0::22 > ipsi6: ICMP6, echo reply, length 64, seq 5

Which has 4 elements:

1. The same sort of Neighbor Solicitation we had previously.
2. This time we send back a Neighbor Advertisement for the ::22 address
3. With that done, the ping itself can come to us (the ICMP6 echo request)
4. And we of course respond to the ping with ICMP6 echo reply.

Conclusions and summary

In the world of IPv6, with no ARP or NAT, life is different. Devices which in IPv4 are thought of as private (both in terms of addressing and functionality) are now, at least from the perspective of addressing, public. We need to make sure that if we want “The World” to be able to reach them, we must in turn tell the world about them. Hence the need for IPv6 neighbor proxying. And, thinking ahead a little, the need to take our firewalling ever more seriously. If I make the addresses of a “private” workstation globally reachable I’d better make sure that it’s protected…

The last point to make is about scalability: do we really need to add an “ip -6 neigh add proxy” for each private device we wish to be able to reach from the Internet? If there are only a few devices (as in the typical home network) then it may well be easiest to do this. However in situations where the private side of the network has many IPv6 addresses which need to be globally reachable, other solutions may be more appropriate and manageable, but will not be covered here. Here we’re trying to get a small home network IPv6 enabled, not migrate a corporation to IPv6. If you really want to get in to the area of automating these functions you need to read up on implementations of Neighbor Discovery Protocol,  look at “zeroconfig” networking, Apple’s Bonjour service, and so on..

There will come a time when such automation will be required at the domestic level, with the eventual proliferation of networked devices. But for now we keep it simple and statically configure the required addresses.