Jun 052019
 

On previous occasions (yes that does mean more than once) I have messed around with the network configuration of containers to get :-

  1. A consistent behaviour.
  2. A fixed IPv4 address with no DHCP configuration (this one is easy).
  3. A fixed IPv6 address with no autoconfigured global addresses (this one has been tricky)

This turns out to be relatively easy providing that you configure the addresses within the container rather than within the container configuration. At least it looks good to go so far (I’ve been mistaken in the past).

The container configuration is quite simple :-

lxc.net.0.type = veth
lxc.net.0.flags = down
lxc.net.0.link = br0

Note that the bridge interface (br0) may be different. Also note that there is no lxc.net.0.ipv4.address, lxc.net.0.ipv4.gateway, lxc.net.0.ipv6.address, or lxc.net.0.ipv6.gateway.

The configuration within the container is dependent on what userland you are running, but for Debian (and Ubuntu if you’re not using Netplan) :-

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.0.0.34/16
    gateway 10.0.0.1

iface eth0 inet6 static
    address 2001:0db8:cafe:dead:0000:0000:0000:3eb/64
    scope global
    gateway 2001:0db8:cafe:dead:0000:0000:0000:0001
    privext 0
    accept_ra 0
    autoconf 0

Not sure quite which options are required but having all of “privext 0”, “accept_ra 0” and “autoconf 0” does mean no additional autoconfigured IPv6 addresses.

(And no the part number of this post isn’t anything more than a joke)

Oct 092018
 

And yes that includes me

For those who don’t know, RFC1918 is the Internet standard that allocates the addresses used for private networks – 10/8, 192.168/16, or 172.16/12. 

And in reference, specifically :-

To minimize the risk it is strongly recommended that an organization using private IP addresses choose randomly from the reserved pool of private addresses

(Apologies for the incorrect spelling above; it’s a quote from an American source)

This was reinforced to me yesterday whilst I was working from home, and I had trouble with a site-to-site VPN joining my network to work’s. As it happens there was no addressing conflict, but I had to install many routes more than should be necessary.

And I keep seeing this sort of thing; joining multiple networks when everybody is using 10/8 is a continual game of chicken – when are we going to find ourselves in conflict? 

Of course there is a “fix” for this – NAT. The real fix of course is to use global IPv6 addresses even for devices and networks that will never be on the global Internet.

The Window
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 192.168.67.52, but accidentally enter 192.168.67.53 instead, you still have a valid IPv4 address. Whereas entering the domain name wombar.example.com instead of wombat.example.com 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.

dam-ip6

Oct 032015
 

A newer post has more information (and more reliable information).

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  10.0.0.34  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  10.0.0.32  2001:db8:ca2c:dead:804a:bfff:fe83:f98d, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  10.0.0.31  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  10.0.0.30  2001:db8:ca2c:dead:21e:a0ff:feb6:65, 2001:db8:ca2c:dead::cafe     YES        
mango     RUNNING  10.0.0.35  2001:db8:ca2c:dead:6c42:24ff:fe7d:4e9, 2001:db8:ca2c:dead::a      YES        
peach     RUNNING  10.0.0.33  2001:db8:ca2c:dead:21e:a0ff:feb6:68, 2001:db8:ca2c:dead::3a11     YES        
rhubarb   RUNNING  10.0.0.40  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)
do
  echo net.ipv6.conf.eth0.autoconf = 0 >> /var/lib/lxc/$container/rootfs/etc/sysctl.conf
done

Does the trick (after a reboot)  :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                                                              AUTOSTART  
---------------------------------------------------------------------------------------------------------
apricot   RUNNING  10.0.0.34  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  10.0.0.32  2001:db8:ca2c:dead:18d9:99ff:fe28:3591, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  10.0.0.31  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  10.0.0.30  2001:db8:ca2c:dead::cafe                                          YES        
mango     RUNNING  10.0.0.35  2001:db8:ca2c:dead:2411:80ff:feb9:6600, 2001:db8:ca2c:dead::a     YES        
peach     RUNNING  10.0.0.33  2001:db8:ca2c:dead::3a11                                          YES        
rhubarb   RUNNING  10.0.0.40  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  10.0.0.34  2001:db8:ca2c:dead::3eb   YES        
chagers   RUNNING  10.0.0.32  2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  10.0.0.31  2001:db8:ca2c:dead::ba11  YES        
lyme      RUNNING  10.0.0.30  2001:db8:ca2c:dead::cafe  YES        
mango     RUNNING  10.0.0.35  2001:db8:ca2c:dead::a     YES        
peach     RUNNING  10.0.0.33  2001:db8:ca2c:dead::3a11  YES        
rhubarb   RUNNING  10.0.0.40  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.

 

WP2FB Auto Publish Powered By : XYZScripts.com

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.

Close