No ads? Contribute with BitCoins: 16hQid2ddoCwHDWN9NdSnARAfdXc2Shnoa
Oct 192016

This is a bit of a thought experiment, so it may be not entirely correct (especially the maths – my probability theory is very rusty).

One of the lesser reasons for using the DNS rather than IP4 addresses is that typing mistakes are more easily caught – if you intend to type, but accidentally enter instead, you still have a valid IPv4 address. Whereas entering the domain name instead of will most likely get you an error instead of sending your secrets off to an unknown location on your network – unless you have a rather silly server naming convention of course!

But how likely are you to make a mistake typing in an IPv4 address? According to a random web site “out there”, the average accuracy of a typist is 92%, or an average of 8 typos per 100 characters. If we convert this into a probability, we get a probability of typing each character correctly as 0.92.

Given that typing IPv4 addresses is something that some of us have a lot of practice at, and in many cases we will notice typos before they become a problem, I’m going to arbitrarily declare that the probability of getting any character within an IPv4 address correct is 0.999. But to type in an IPv4 address correctly we have to get a maximum of 15 characters correct :-

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1 9 2 . 1 6 8 . 1 2 8 . 1 2 8

So the probability of getting all those characters right is 0.999 (first character) x 0.999 (second character) … Or 0.999^15.

And once you work that out, subtract it from 1 (to get the probability of making a mistake) and convert it into a percentage, there is an 11% chance of making a typo in an IPv4 address.

For an IPv6 address such as 2001:db8:ca2c:dead:44f0:c3e9:28be:c903, which has 38 characters (no I’m not doing that silly table for IPv6) – 100 * (1 – 0.999 ^ 38) – 32%.

Now whilst my calculations may be a bit off, the likelihood of entering an IPv6 address incorrectly is nearly three times higher than the risk of entering an IPv4 address incorrectly.

In other words, with IPv6 you really need a good working DNS solution just to keep the errors to manageable levels.


Oct 032015

One of the things that has been mildly irritating me about my little collection of Linux containers has been that in addition to the statically defined IPv6 addresses, there is also an automatically defined IPv6 address :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                                                              AUTOSTART  
apricot   RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  2001:db8:ca2c:dead:804a:bfff:fe83:f98d, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:65, 2001:db8:ca2c:dead::cafe     YES        
mango     RUNNING  2001:db8:ca2c:dead:6c42:24ff:fe7d:4e9, 2001:db8:ca2c:dead::a      YES        
peach     RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:68, 2001:db8:ca2c:dead::3a11     YES        
rhubarb   RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:69, 2001:db8:ca2c:dead::dead     YES  

Now this is hardly the end of the world, but it is not tidy and it is the sort of thing that may lead to problems down the road if servers are communicating on an address that is not reverse DNS registered. Or indeed when someone contacts a server on an address such as 2001:db8:ca2c:dead::3eb and the reply comes from 2001:db8:ca2c:dead:21e:a0ff:feb6:6a.

After any number of false starts, the answer is quite simple – use sysctl to turn off autoconfigured address from within the container; which doesn't make much sense logically – containers don't have a kernel of their own, so the global kernel should be the one that is tuned. However :-

for container in $(lxc-ls)
  echo net.ipv6.conf.eth0.autoconf = 0 >> /var/lib/lxc/$container/rootfs/etc/sysctl.conf

Does the trick (after a reboot)  :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                                                              AUTOSTART  
apricot   RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  2001:db8:ca2c:dead:18d9:99ff:fe28:3591, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  2001:db8:ca2c:dead::cafe                                          YES        
mango     RUNNING  2001:db8:ca2c:dead:2411:80ff:feb9:6600, 2001:db8:ca2c:dead::a     YES        
peach     RUNNING  2001:db8:ca2c:dead::3a11                                          YES        
rhubarb   RUNNING  2001:db8:ca2c:dead::dead                                          YES        

Except for the older containers 🙁 

I've obviously missed something, but fixing nearly half of the containers is a good start.

After attending to pending upgrades (some of my old containers were still running wheezy), and setting the network configuration to manual, one of the recalictrant containers (glanders) lost it's autoconfigured address. 

Two more containers lost their unwanted extra addresses after "fixing" their configuration. I'm not sure what was wrong with the old configuration, but after copying and modifying a recently created container configuration, they rebooted with just one IPv6 address. The last one was mango, but after an extra reboot, it also was fixed :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                      AUTOSTART  
apricot   RUNNING  2001:db8:ca2c:dead::3eb   YES        
chagers   RUNNING  2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  2001:db8:ca2c:dead::ba11  YES        
lyme      RUNNING  2001:db8:ca2c:dead::cafe  YES        
mango     RUNNING  2001:db8:ca2c:dead::a     YES        
peach     RUNNING  2001:db8:ca2c:dead::3a11  YES        
rhubarb   RUNNING  2001:db8:ca2c:dead::dead  YES        
Mar 242013

The above links to an interesting browser which allows zooming and selection of different data sets. It’s worth a look if you’re into that sort of thing. Although it’s rather surprising that it doesn’t like IPv6 addresses!

The most controversial thing about this map of the Internet gathered during 2012, is that it was produced with the aid of a botnet or in other words this researcher stole the resources they needed. Which is obviously wrong – no matter how good the cause – but now that it has been done, there is no reason not to look at the results (whilst wrong this isn’t really evil).

The first interesting discovery here is that this anonymous researcher managed to write a simple virus that would load the Internet scanner onto many devices with default passwords set – admin accounts with “admin” as the password, root accounts with “root” as the password, etc. You would have thought that such insecure devices would have been driven off the Internet by now, but it turns out not to be the case – there are at least 420,000 of them!

You could even argue that the owners of such machines are asking to have their devices controlled by anyone who wants to. Perhaps a little extreme, but certainly some people think so or this Internet survey wouldn’t exist.

But now the results. If you look at the default settings in the browser above, you will encounter large swathes of black squares where apparently nothing is in use. The trouble is that whilst it is true that an IP address that is pingable, or has ports open is “in use”, there is no guarantee that an IP address that is just registered in the DNS is in use or not, and finally unregistered IP addresses that do not appear to do anything may very well still be in use.

Essentially the whole exercise hasn’t really said much about how much of the Internet address space is in use, although that is not to say that the results are not useful.

One special point to make is that many of the large black squares that appear unused, are allocated to organisations that may very well want to have proper IP addresses that are not connected to the global Internet. That is not wrong in any way – before the wide spread adoption of NAT, it was common and indeed recommended that organisations obtain a public IP address before they were connected to the Internet to avoid duplicate network addresses appearing. And an organisation that legitimately obtained an old “class A” has no obligation to return the “unused” network addresses back to the unallocated pool. And even if they did, it would not make a big difference; we would still run out of addresses.

The answer to the shortage of IPv4 addresses is IPv6.


Sep 292012

Just like previously, please read the disclaimerbefore proceeding; I ain’t no CCIE! Several points before diving off into the configuration :-

  1. Somewhat surprisingly, the most difficult part of getting IPv6 up and running was not the configuration nor the process of switching ISP to one that supported native IPv6. The most difficult part was acquiring a version of IOS that was not riddled with bugs related to (I think) running IPv6 over PPP. If you are undertaking this task, I would suggest making sure you have a very recent version of IOS – the one I am now running was released in July 2012.
  2. If you need a UK ISP that supports IPv6 for customers, I would suggest AAISP.
  3. Throughout this document, I am using the IPv6 documentation network 2001:db8/32, or more specifically 2001:db8:face/48. That doesn’t guarantee that I know what I’m talking about, but at least it doesn’t guarantee that I know nothing … as would be the case if I were using some random real IPv6 address.
  4. None of the following should interfere with anything you might be doing with IPv4. With the exception of times when I reloaded the router out of frustration, and occasionally to load a new firmware, my IPv4 connectivity was up and running continuously.

Before starting you need an IPv6 address to configure; unless you have a large internal network it doesn’t make sense to start playing with a ULA address. So get an allocation from your ISP. If you have a half-reasonable ISP, they will allocate you something like 2001:db8:face/48 which will give you 65536 different subnets to play with – perhaps slightlyover the top for a home network! To start with, you need to configure the router itself to enable IPv6 :-

ipv6 source-route
ipv6 general-prefix MYISP 2001:db8:face::/48
ipv6 unicast-routing
ipv6 cef

This basically enables IPv6 routing (with no routing protocols – only static and learnt routes) and configures a “general prefix” with the network details of what your ISP has provided you with. This can be used later to configure addresses in a way that means that changing ISP isn’t quite so painful, and in a way that is less error prone – typing in IPv6 addresses is a lot more prone to typos than IPv4 addresses. Once that is done, it is time to look at IPv6 security … normally people suggest getting everything working first, but as I am more of a security geek than a networking geek, I would suggest security comes first. This is not a great deal different to IPv4 security except that forgetting about NAT makes things simpler :-

ipv6 inspect routing-header
ipv6 inspect name ipv6-allowed-out icmp
ipv6 inspect name ipv6-allowed-out tcp
ipv6 inspect name ipv6-allowed-out udp
ipv6 inspect name ipv6-allowed-out ftp

This basically defines what traffic is allowed out (assuming it’s applied appropriately to an interface). Nothing really odd here … basically everything is allowed out, and I ask the router to inspect for routing information that might be available. The next bit is the incoming ACL :-

ipv6 access-list access-to-servers
 permit icmp any any
 permit tcp any host 2001:db8:face:f00d::c0:ffee eq 22
 deny ipv6 any any log

Several key points about this ACL :-

  1. All IPv6 ACLs are “extended”.
  2. All IPv6 ACLs are named rather than numbered.
  3. The ICMP bit looks a little permissive, but ICMP is very much more required for a functioning IPv6 network than an IPv4 network. It can be tuned down somewhat, but you need ICMP for your network to work.
  4. The rule that allows access to my server on port 22 does not allow the use of the previously defined general-prefix. Come on Cisco, do the right thing here!

And another ACL for access to the router’s SSH port :-

ipv6 access-list authorised-v6
 permit ipv6 2001:db8:face::/48 any
 deny ipv6 any any

And we might as well apply that last ACL right away :-

line vty 0 4
  ipv6 access-class authorised-v6 in

Now we have the basics ready, we can start to configure interfaces. Before you start, it is worth figuring out what network addresses to use. IPv6 does of course allow the possibility of using wildly inappropriate hexspell words as network address, or you could be very sensible and come up with an appropriate allocation scheme.  For larger networks, it is well worth reserving a large swathe of networks (such as 0000-7ffff) for someone to come along later to create a “better” scheme … as somebody who has dealt with a large IPv4 network where the original allocation scheme was somewhat suboptimal, I firmly believe that later network administrators should have the freedom to change the scheme in the light of more experience. You will often encounter the assumption that the host part of a network is always 64 bits (or the network mask is always /64). Whilst this is not a requirement at all, there are popular features of IPv6 that only work on a network that size such as address auto-configuration (SLAAC). In practice this means that you should always create networks with a /64 netmask, unless you have a very good reason not to (for instance when configuring statically configured links between routers). Even if you have no intention of allowing address auto-configuration. As a minimum, you will need two networks – one for the external interface, and one for the internal interface(s). As you may have guessed, we have already specified what the internal network is: 2001:db8:face:f00d/64, and I will use 2001:db8:face:1ced/64as the external interface. The first interface to configure is the internal network :-

interface Vlan101
 ipv6 address MYISP 0:0:0:F00D::1/64
 ipv6 enable 
 ipv6 nd prefix 2001:db8:face:f00d::1/61
 ipv6 nd router-preference High

The command to give the network and the interface an address requires a little explanation. First of all, we’re lucky enough to be able to use the “general-prefix” that we defined earlier. This “general-prefix” is merged with the unusual looking address that follows it :-

MYISP general-prefix 2001 db8 face
Address to merge 0 0 0 F00D::1/64
Result 2001 db8 face F00D::1/64

This provides the interface with an address. The next command simply enables IPv6 on the interface. The ipv6 nd prefix command tells the router what “prefix” to advertise to clients wishing to autoconfigure (using SLAAC).

As an aside, the whole topic of managing IPv6 addresses on clients is worth an article on its own – auto-configuration sounds like a good option (and indeed may be a good choice), but there are situations where you would prefer to not allow auto-configuration. And not all clients work equally well with all options.

The next command (ipv6 nd router-preference High) is a weak attempt to guard against false Router Advertisement messages – advertising this router as a High preference one may prioritise it’s use over any other mysterious routers that appear on this network. In practice, it is necessary to block RA messages from non-router ports using a switch feature such as ipv6 nd raguard. Once this interface is configured, you may well start to see IPv6 hosts with the command show ipv6 neighbours. And onto the configuration of the outside interface :-

interface Dialer0
 ipv6 address MYISP ::1ced:0:0:0:1/64
 ipv6 enable
 no ipv6 nd ra suppress
 ipv6 inspect ipv6-allowed-out out
 ipv6 traffic-filter access-to-servers in
 ipv6 virtual-reassembly in

This starts off in much the same way as the previous interface configuration, but in this case I also :-

  1. Explicitly enable RA messages on the interface with no ipv6 nd ra suppress. This is to ensure that the RA messages get out to the ISP’s router on the “other end”.
  2. Uses ipv6 inspect ipv6-allowed-out out so that IPv6 traffic is allowed out (and any associated packets are allowed back in again!).
  3. Uses ipv6 traffic-filter access-to-servers in to allow any unsolicited IPv6 traffic necessary in.
  4. Uses ipv6 virtual-reassembly in to use Cisco’s VFR feature to protect against fragmentation attacks.

Note that I have statically configured the address on this interface. Some ISPs require this, and some require that the interface is set to auto-configuration (ipv6 address autoconfig or ipv6 address dhcp). The last step is to configure a default route :-

ipv6 route ::/0 Dialer0

Some misconceptions I’ve come across through googling for tips and assistance :-

  1. There are plenty of examples which show internal interfaces configured with ipv6 nd prefix XXX in addition to the interface address. As far as I can see (and as demonstrated by my home network actually networking), there is no need to specify this prefix unless you are advertising multiple prefixes on an interface, or doing something even stranger.
  2. Examples often include ipv6 nd ra interval ${some-value}, which as far as I can see is somewhat unnecessary except that the default value of 200s means that connected hosts may take a while to spot the router.
  3. There are plenty of examples for setting up IPv6 with a tunnel within IPv4 where the IPv6 MTU is set to some value lower than the default such as ipv6 mtu 1280. Tuning the MTU for native IPv6 should not be necessary, and even if it is, the right value would be somewhat higher.

And of course, if anyone believes I’ve done something wrong, please let me know!

Facebook Auto Publish Powered By :

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.