by Craig Miller
IPv6 is still a different networking protocol
Last post I mentioned how IPv6 is a double edge sword, you can take advantage of it, and that so can others.Because IPv6 is a new (widely used) protocol, subnets may not be aligned with existing IPv4 . In fact, implementing IPv6 in your network is an excellent time to rethink your network topology and simplify it. Therefore, there is a good chance that the path to a distant server does not take the same path using IPv6.
Think of it like the subway, there is usually more than one way to arrive at your destination. And they don't all arrive at the same time.
A different path, a different set of rules
There can be local advantages as well, for example, what if there is a firewall in the way of getting to the server down the hall. Depending on how new the IPv6 network is, there may not be firewall rules yet applied, and the path is wide open. Of course, if this is your network, you should not leave the network in this state for long. It isn't only the good guys trying to get to your server down the hall.Networking Old School, firewalls
Just like the old days, before there was NAT (Net Address Translation), there were firewalls with ACLs (Access Control Lists), which controlled the flow of traffic. Contrary to popular belief, NAT is not a firewall. Sure, when done cleanly, NAT only allows traffic to be initiated in one direction. But because NAT munges things up so bad, most NATs have one or more static port forwards configured (think: holes in your firewall). And that is just the explicit forwarding. UPnP (Universal Plug and Play) is a protocol which allows any host on the inside of NAT to open holes (reverse port forwards). Suddenly your clean NAT implementation is as good as Swiss Cheese.Before there was NAT there were firewalls, and they are just as good at IPv6 as they were for IPv4. IPv6 is a different protocol, it requires a different set of rules. And because the addresses are different, you can't just cut and paste the IPv4 rules. Be thoughtful when setting up firewall rules.
IPv6 Goodness, using the auto-generated link-local address
But there are other good reasons to use the separateness of IPv6. Say for example, you turn up a new server, but for what ever reason it didn't pick up an IPv4 address from your DHCP server. You could spend a couple of weeks trolling around for the IPv4 auto-configuration address (one of 65,000) in 169.254.0.0/16.But with IPv6, every interface is assigned a link-local address. This starts with FE80::/10 (RFC 2462) And every IPv6 node registers for the all-nodes multicast address FF02::1. So if you have another machine on the same link (think: subnet), you can ping the all-nodes multicast address, and watch the multiple returns. Because the link-local address is significant on each link, one must append the interface using the %interface scope notation (RFC 4007).
~$ ping6 ff02::1%eth0 -c 2 PING ff02::1%eth0(ff02::1) 56 data bytes 64 bytes from fe80::211:24ff:fee1:ebc8: icmp_seq=1 ttl=64 time=0.116 ms 64 bytes from fe80::224:a5ff:fef1:7ca: icmp_seq=1 ttl=64 time=0.459 ms (DUP!) 64 bytes from fe80::203:93ff:fe67:6362: icmp_seq=1 ttl=64 time=3.17 ms (DUP!) 64 bytes from fe80::225:31ff:fe02:cecb: icmp_seq=1 ttl=64 time=6.01 ms (DUP!) 64 bytes from fe80::211:24ff:fee1:ebc8: icmp_seq=2 ttl=64 time=0.061 msYou did note the MAC address of that new server, right? The IPv6 link-local address is formed from the MAC address, which should be unique on the link. And because you did note the MAC address, you can now just ssh to the server using its link-local address.
:~$ ssh fe80::203:93ff:fe67:6362%eth0
cvmiller@fe80::203:93ff:fe67:6362%eth0's password:
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
cvmiller@myserver:~$
No IPv4 needed!
No comments:
Post a Comment