|
||||
|
As per previous posts and discussions, my project to develop npd6 (Neighbor Proxy Daemon 6) is now advancing very rapidly. If you have a Linux gateway router terminating your ISP feed supporting IPv6, this may be just what you need. To summarise the problem it solves: your ISP has given you an /64 (or some [...] As threatened in article IPv6 neighbor proxy daemon – npd6 and the associated design ramblings here, the npd6 project now lives and breathes. EDIT: 22 July – The project has really taken shape. Version 0.3 is now useful enough to be considered a working beta version. Building is very simple – do please try it out [...]
EDIT: 22 July – The project has really taken shape. Version 0.3 is now useful enough to be considered a working beta version. Building is very simple – do please try it out and let me know of any issues, good or bad. And find it, eventually (Google, Bing et al – Thank You!) you do. Except when you don’t. Back in this post I wrote about a specific, but key, problem in implementing an IPv6 firewall/router on a Linux box, when attached to a “normal” ISP. What was the problem?In a nutshell, it was as follows. My ISP gives me a full IPv6 service, with a staticically allocated (i.e. fixed) global IPv6 address. They give me a /64, so I in turn have a full /64 to play with in my private net. Enough to network every dust particle in the house. (And this is one dusty house). As I found, not surprisingly the ISP does not let me advertise address space back to them regarding which devices in my private-but-globally-addressed network actually exist. Given that, I rather naively hoped that they would thus blindly forward anything that was addressed to my (global prefix + private part) network to me regardless, and treat my gateway device as, in effect, a sort of default route for my IPv6 prefix. So what must npd6 do in functional terms? See Neighbor Solicitations. EITHER respond to them directly OR respond via the existing mechanisms. Log activity. Report status. Receive Neighbor Solicitations The daemon needs to receive incoming neighbor solcitations from a designated port(s). I currently have no idea if this is an easy hook to make [...]
When in my IPv6 environment I perform a test ping to, say, Google, it seems to work great: ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8006::6a) 56 data bytes
64 bytes from 2a00:1450:8006::6a: icmp_seq=1 ttl=55 time=49.3 ms
64 bytes from 2a00:1450:8006::6a: icmp_seq=2 ttl=55 time=44.6 ms
.
.
.
Which is lovely. But I then ask myself how the ping6 command actually gets to know that name ipv6.google.com lives at IPv6 global address 2a00:1450:8006::6a. How is the domain name being resolved? And I find that I actually don’t know. I’m perfectly familiar with IPv4 DNS. So what’s going on here? I’m cheatingI discover, upon investigation, that in fact I’m “cheating”. By that I mean that my attempt to set up a “pure” IPv6 environment (albeit in parallel with IPv4) that does not rely upon or touch IPv4 in any way has not been achieved – It turns out that my DNS is currently entirely dependent upon the existing IPv4 infrastructure! And before going ahead and trying to rectify that, it’s actually rather educational to understand how it is actually working at all.
To recap:
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.
All of this has, so far, made use only of one network interface (in my case eth0) to set things up. However looking ahead to the next step I am aware that I will want devices inside my network (i.e. my workstations, etc.) to have IPv6 connectivity through this device I am setting up. In other words, this device must, as it does today for IPv4, act as a router. With IPv4 this is, at a basic level (so forgetting about firewalling and so on) very easy: enable IPv4 forwarding and away you go. For IPv6? A little more complicated…
|
||||
|
Copyright © 2012 ipsidixit.net - All Rights Reserved |
||||
Recent Comments