Whilst IPv6 deployment will usually "just work", and may even just be handled by a broadband router and an ISP that do IPv6 (like AAISP), if you are setting up a network (e.g. large office, or multiple sites, etc) you have to consider things a tad more carefully.
This is especially important for an ISP like us, as we have to be able to understand the IPv6 addresses themselves if trying to debug the network when things break (and one thing that can break is DNS, or access to it).
Side track: We have had a couple of cases recently with support where a customer has had some issue which means he cannot get on-line properly. Usually with their machine or network. However, they have got on irc to ask for help! This is because the IPv6 just works. Always amusing someone using the Internet to ask for help because the Internet is not working.
Numbering the LAN
Each LAN will be a /64, that is pretty much defacto now. As an ISP we allocate people a /48 to deploy as they wish. If you have many sites you probably want to split the /48 in to parts, e.g. a /56 per site allowing 256 sites, and 256 LANs per site. This will depend a lot on how you manage sites now. If you have any sort of site numbering, you could perhaps use that as part of the address.
If the sites need independent BGP announced routing you will want to consider additional /48's. It seems you can get a /48 to propagate around the Internet to some extent. As long as someone announcing something bigger (e.g. a /32) can see all your /48's then the /48's themselves do not have to go everywhere in the Internet. It is also not nice to make lots of separate /48s in BGP if you can avoid it. As with IPv4 routing there is no guarantee of routeability of any block so you need to play nice if you want things to work.
This weekend we changed our office allocation to a /47, i.e. two adjacent /48s. This allows a single filter in access lists, but allows one /48 at each of the two independent sites we run, though we have the /32 from one site to cover any filtered routes. This means the choice of /48 is simple geography for us.
We have to then think of the LAN allocation. 65536 possible LANs in a /48.
I think the best advice here is try and be as logical as possible - if you have any existing site numbering scheme, see if that can fit in. If not, try and make one that works with the IPv6 allocations as well.
Hex and decimal
One of the interesting things we see a lot, and do ourselves, is the use of a decimal number from something else, put in to an IPv6 address in some way, but as hex.
e.g. if you had site number 42 (decimal), you may use :42: in the IPv6 Address, even though that is actually 66 (decimal) as the "42" is in hex.
Given that the only reason to use numbering from something else, such as a site number, protocol number, machine number, dialling code, etc, is for your own convenience, then I think this makes sense. You do not want to have to be doing hex/decimal conversions to see and use the "logic" you have created here.
Server addresses
If you have a server for some reason, then you will want it in DNS. You could use an automatic address, but that means change of DNS on change of Ethernet card or move to a new machine, etc. It seems logical to make a server address a fixed address.
What we came up with, and I would be interested in comments on, was using the protocol number in the IPv6 address. E.g a web server on port 80 includes 80 (hex) in the address. E.g. 2001:db8::80
In practice we almost always have multiple servers for anything at a site, usually labeled A, B, C, etc. So we chose to make the protocol and instance in the address.
e.g. the 3rd web server at a site is 2001:db8::80:3
Of course, this begs the questions, if we call that c.webserver then why not 2001:db8::80:C but there are cases where we go over F in lettering servers, and so that breaks. Numbering is fine, and maybe we should have 3.webserver rather than c.webserver anyway? Of course I is :9, J is :10, K is :11, up to Z being :26, even though "10" is 16 (decimal) :-)
Bear in mind that you can give a machine multiple addresses, so you could stick to this protocol based address numbering and allow services to move between machines while keeping addresses. e.g. 2001:db8::443:3 and 2001:db8::80:3 may indeed be the same machine (one for https and one for http). You could even ensure the services bind only to the address specified for them.
Automatic addresses
They work. As long as you don't change the Ethernet interface they are consistent. They can quite validly be what you use and what you put in DNS.
We are moving away from this for any servers (as above), but not sure it is a good or bad idea to use automatic addresses.
PC addresses
PCs on desks can, of course, get automatic addresses. We are not sure if this is the best choice or not. It helps a lot in renumbering but makes it hard to track for reverse DNS, etc.
We did think of matching some other scheme, such as peoples telephone extension numbers being part of the IPv6 address.
Privacy addresses
Arrrg! Who was so paranoid to invent this. I cannot even turn it off on my iPad. I have even set my LAN to use DHCPv6 and flag the router announcements as "Managed", and it still does privacy addressing. I have no hope of having sensible reverse DNS on access logs to our systems.
OK, yes, I can see why some people want this, but I can't see me using it (apart from the iPad).
EUI64
We would love a way to set the bottom 64 bits in a config, but leave the top 64 bits (as well as DNS and router) as automatic. This makes renumbering easy, and DNS would be a simple search replace if we did. But I don't know if that can be done on any PCs.
Names
Of course we all want to be clever. Guess who's site is 2620:0:1cfe:face:b00c::3 though we are surprised someone else is not using 6009:1e in their addresses...
So do we make our machines only use A B C D E F I Z S T O ?
We have managed ec-office (ec0f:f1ce), and faceless (face:1e55), and even boxless (b0c5:1e55).
I don't know if this is good or bad. If the words can be made obvious enough, maybe. What do people think?
IPv4 address based
One thing that we have been told, and I am inclined to agree with, is not to base static IPv6 addresses on IPv4 address. Don't make the machine with 203.0.113.123 use 2001:db8::203.0.113.123
For a start it does not help readability as it shows in hex (e.g 2001:db8::cb00:717b).
Secondly it will get out of step, and then be even less use and could cause more confusion.
Router address
The first address on an IPv6 LAN is special, as it is an anycast for the router. We have used that with no problem for that purpose.
However, it seems linux does treat it as special when accessing it. I am not 100% sure why (someone quote me an RFC). I.e. a machine accessing it should simply ND for it, and get the address. linux seems unwilling to answer a ping from such an address. Maybe something else is odd about it.
What we have tended to do is put a router address on a LAN as
In general you do not have to say the router address as it is set by router announcements advising the MAC to use. If using VRRP you the router announcements should announce the special VRRP MAC address to ensure fast switching. However, if manually configuring a box so that it does not get an automatic address then we are having to tell the box the router address. So we have to consider what address to use.
Using an address per service would be ideal if there was a way to get dhcpv6 to cooperate - it'll only hand out one address per machine (v4 dhcp has the same problem) so you lose central configuration and end up hard coding the entries on each machine.
ReplyDeletePrivacy addressing is evil but probably good the average home user who's paranoid. Without that they'd start demanding ipv6 NAT.. and as cluefull types we can switch it off (except on ipads).
Have you considered using something like macchanger I've used this to set the macs of my linux boxes to what I want the last bit of my ipv6 address to be, then let radvd do the rest, simple.
ReplyDeleteThe ifconfig command does let you set mac addresses to whatever you want so you can use this in a script if your distro doesn't have macchanger available.
With Linux's ability (assuming kernel genericness)to fill most hardware footprints this gives you the best and fastest ability to restore services in the event of hardware failure.
As your newly restored backup will simply just work on its new hardware whether this is a newly installed softbackup or a simple move of a hard disc from old hardware to new.
On a separate note, have you seen that PixelQI are looking to make an iPad 3 replacement screen that uses 100x less power than the current Apple standard screen. Now there's a reason the void your warranty if ever I saw one :)
I considered that, but it would force ff:fe in the address and I don't really want to change the MAC.
Delete"uses 100x less power" - so if the current one uses 1W, the new one uses -99W? :-)
ReplyDelete- Howard
I'm not seeing the Linux behaviour you describe - when I try and access 2001:8b0:104:119:: from a machine on 2001:8b0:104:119::/64, I see ND requests going out and being replied to, then the subnet router responding from its unicast address to the ping.
ReplyDeleteI don't, however, see NDs if the Linux box is configured as a router - but that makes sense, as it's responding locally.
I have a feeling the router may be, sensibly, tagging the ND responses in a way so that it knows it is anycast and that may be the issue. If I used that address as vrrp or a simple host address is probably should not tag as such. I think there is a flag in the ND reply. I may have remembered it wrong though :-)
DeleteWhy is there an issue with using privacy addresses? I can understand why reverse DNS is useful for servers but in most situations I don't see a particular need for it in transient devices, like laptops and iPads that connect to different LANs and different networks on a regular basis. We allow machines to use privacy addresses and don't have reverse DNS set up for clients on the LAN. It's been like that for a couple of years now. What problems should we expect to see as a result?
ReplyDeleteI like to have host names in my access logs on my systems, at least for our own machines, and that makes it impossible.
DeleteYou get an unauthorised access to a server from inside your LAN. If that's from a privacy address then you're hosed - the trail goes cold right there.
DeleteOr you want to monitor traffic levels. With privacy addresses that's made a lot harder (you could hack something using mac addresses if none of your traffic goes via internal routers I guess).
Someone reports malware from an address on your LAN. If you have privacy addresses enabled there's nothing you can do unless you can capture a packet in transit (and can find the MAC of the source machine).
Access to servers should only be possible via a VPN and with server specific credentials. If it is possible because you can plug into a port on the LAN you have more serious security issues.
DeleteI remember our IT department checking my laptop for malware after a report of unusual traffic from another user (it turned out to be nothing) and privacy addresses didn't seem to be a problem for them. While I am impressed with the skills in our IT department I am confident a less skilled team could have achieved a similar result.
Are running in a Windows environment Leo? I wouldn't be surprised if your client is registering its own IP details in DNS with your Windows DNS servers just as it does with IPv4 reducing the headache of privacy addressing as the forward and reverse entries are created/updated automatically when your client gets a different address.
ReplyDeleteAdrian, might something like this behaviour be possible in your Linux environment for your clients?
I did wonder. I was thinking we could do with DHCPv6, and that may be possible if we support sending temporary address records. The DHCP server could fill in DNS then. I do think people should always provide an option to turn it off!
DeleteDHCPv6 sending EUI-64 addresses? I'm somewhat surprised there's no option for that already given that there's currently no standard for SLAAC to update DNS.
DeleteCome to think of it the dhcp server wouldn't even have to send the address out in the simple case (no privacy gubbins) since it could just assume the client knew what it was doing and update DNS accordingly.
There is a Windows network but a quick check shows that the IPv6 address I'm using right now has no reverse DNS.
DeleteYour not the only one who thinks there should be an option to turn temporary addressing off, it's actually a requirement of meeting the RFC, not only that, but any device implementing temporary addressing is supposed to have it off by default.
Deletehttp://www.ietf.org/rfc/rfc4941.txt Section 3.6
You'd think, but Android ice cream sandwich does the on by default, no way to switch it off trick. Bloody annoying.
DeleteI've written an app that listens for new ipv6 addresses crossing the LAN, calculates what the name is (reverse on the EUI64 at the moment), and does a dynamic update of the reverse DNS. That mitigates some of the pain (at least I can see what the device is on traces).
Can't do much for the accounting on clueless though, unless I do a 'nat back to eui64' trick, which is so evil I'd probably instantly become a sith by using it...
The bit about ::0 being special is not just linux. It's the subnet-router anycast address, so in theory the use you want (vrrp router) should be quite doable.
ReplyDeleteSee http://tools.ietf.org/html/rfc4291#section-2.6.1
Server Addresses: 2001:8b0:xxxx:xxxx:10:1:1:12
ReplyDeleterather than 2001:db8:xxxx:xxxx:203.0.113.123
(colons rather than dots.)
Working OK for me at present.
Are there pit falls doing it this way?