IP Assignment Best Practices

[mrballcb]

Hi all, I have setup a tunnel and things are working well.  My tunnel subnet is 2001:470:c:367::/64 and I have been allocated 2001:470:d:367::/64.  My ptp ip is of course 2001:470:c:367::2/64, and up until this point I have been using that for the IP of my mail and web server.
1. I feel it's better to leave the tunnel subnet out of the picture as far as public access and I should assign an IP somewhere in the allocated /64.  Yes or no?
2. As far as which IP to use out of that /64, do people typically use a random IP, use an easy to remember IP, or go through the steps of stateless autoconfiguration to pick the IP?  Since it's a server, I don't want it to change if I have to change the network card, or change server hardware, etc, so I wouldn't leave it in stateless autoconfiguration.  What's the norm for this ip selection?
3. I use my employer's public DNS which is ipv4 only for my domain, so as far as certification, I'm stuck at the point where I need reverse resolving DNS that is ipv6 accessible.  I don't think it's really wise to try to host dns within my tunnel, but do others do that?  With stablity?
4. Otherwise, do companies offer public ipv6 accessible dns?  Cost?

Regards...  Todd

[jimb]

Yes.  Use the routed /64 for your servers, etc.

IPv6 addresses for servers are really a preference thing.  Personally, I like using statically assigned low numbered IPv6s for servers since they're easy to type, etc.  I'd rather type 2001:db8:1234:456::10 than some long autoconfig address.

As for DNS, the RDNS doesn't have to be on an IPv6 DNS server.  You just need to create the appropriate "ip6.arpa" zone on your DNS server (HE will delegate "7.6.3.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa" to the name server you list, you just create a zone for it and populate it with PTR records just like IPv4 in-addr.arpas).  For parts of the cert which require an IPv6 DNS server, most people who do the tests do simply host them on their HE IPv6 network on their tunnel.  That's how I completed all the tests through sage.  I set up DNS, SMTP, HTTP servers on one of the hosts reachable via my tunnel.

I'm not sure about DNS providers who host IPv6 enabled servers.  I didn't bother since it was easier just to fire up BIND and set up a subdomain, and add my IPv6 name server to my domain's list of NSes on my registrar's web site, as well as an IPv6 NS glue record to do the Sage test, which my registrar (godaddy) allows.

[mrballcb]

Yes.  Use the routed /64 for your servers, etc.  IPv6 addresses for servers are really a preference thing.  Personally, I like using statically assigned low numbered IPv6s for servers since they're easy to type, etc.  I'd rather type 2001:db8:1234:456::10 than some long autoconfig address.

I was leaning towards that, thanks for the confirmation.

As for DNS, the RDNS doesn't have to be on an IPv6 DNS server.  You just need to create the appropriate "ip6.arpa" zone on your DNS server (HE will delegate "7.6.3.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa" to the name server you list, you just create a zone for it and populate it with PTR records just like IPv4 in-addr.arpas).  For parts of the cert which require an IPv6 DNS server, most people who do the tests do simply host them on their HE IPv6 network on their tunnel.  That's how I completed all the tests through sage.  I set up DNS, SMTP, HTTP servers on one of the hosts reachable via my tunnel.

Thanks for the clarification!  The way I read it, I thought that the DNS server had to be reachable via ipv6, not just resolving ip6.arpa PTR records.  I can see clearly now the rain is gone...

Regards...    Todd

[mrballcb]

3. I use my employer's public DNS which is ipv4 only for my domain, so as far as certification, I'm stuck at the point where I need reverse resolving DNS that is ipv6 accessible.  I don't think it's really wise to try to host dns within my tunnel, but do others do that?  With stablity?

I muddled some things in my description.  This is where I'll be picking up tomorrow:

*     2     Check to see that the nameservers associated with www.mrball.net have IPv6 AAAAs   
*    3    Check to see that the nameservers associated with www.mrball.net are IPv6 accessible

It's not RDNS, I have to set my NS records to an ipv6 address, which means I can't use my regular two ipv4-only dns servers.  I'm willing to do that for RDNS, but not for the active zone itself.  I'll have to use a different domain to get past this step of the cert I suppose.  If I'm misunderstanding, please do correct me.

[jimb]

Yeah.  I had a similar situation, my primary NS not being IPv6 enabled.  I just created a subdomain (ipv6.domain.com) and used that for the cert steps requiring IPv6 addressable DNS servers, and everything else really.

I don't really remember all the different tests in the cert though, and there's unfortunately no way to revisit them once you've completed them that I can see short of creating another account.  So I forget a lot of the details of what each step asks for.  This sometimes makes it difficult to answer questions. :P

[NewtonNet]

Hi Todd,

Excellent questions - they've recently been in my mind too so it's been good to hear your (and others') thoughts on them.

1. I feel it's better to leave the tunnel subnet out of the picture as far as public access and I should assign an IP somewhere in the allocated /64.  Yes or no?

I think I am right in saying given that the tunnel is a point-to-point connection then, by definition, it contains only two interfaces in the subnet. Hence, any other interface - whether that be another interface on your machine or another device on your network, ought to sit in a different subnet to that of the tunnel. Of course, things would work either way but in terms of keeping things clean and portable it makes sense to 'stick to the rules'.

2. As far as which IP to use out of that /64, do people typically use a random IP, use an easy to remember IP, or go through the steps of stateless autoconfiguration to pick the IP?  Since it's a server, I don't want it to change if I have to change the network card, or change server hardware, etc, so I wouldn't leave it in stateless autoconfiguration.  What's the norm for this ip selection?

I've allowed some of the clients on my LAN (true clients - e.g. a laptop used for web browsing in the lounge) to construct their own addresses through stateless autoconfiguration (using radvd on my Linux server to announce the prefix to use) however as jimb touched on this does end up with unwieldy lengthy addresses. Hence, for machines/infrastructure with more of a service role I've been manually specifying addresses that are as short as possible, and ideally with some intuitive meaning in them.

For example, my main server has always sat at 192.168.0.50 hence I've given it a ::50 IPv6 address because it means something to me. Given that the server fulfils multiple roles - web, mail, DNS etc I've actually been giving it multiple addresses so that I can use the specific address for a specific service - handy if I want to move service to another box (just move the address with it - I don't then need to modify anything else such as DNS entries) and also convenient when capturing traffic on the network as it helps make streams easier to identify.

Another case in point is my homemade cat feeder - IPv6 enabled of course(!) - it has a ::feed address for obvious reasons! Childish I know, but it does help remembering what's what.

3. I use my employer's public DNS which is ipv4 only for my domain, so as far as certification, I'm stuck at the point where I need reverse resolving DNS that is ipv6 accessible.  I don't think it's really wise to try to host dns within my tunnel, but do others do that?  With stablity?

I had similar thoughts - my DNS is hosted at zoneedit.com who, whilst they support AAAA records don't support access to their servers over IPv6. I was hesitant to set up my own (IPv6-accessible) DNS server here on my residential connection as whilst my server only hosts domains for personal use (for myself and a few friends) it has got to the stage where uptime and accessibility is, from my perspective, as important as any commercial offering as I don't want to let anyone down - myself included!

However, it then dawned on me that most resolvers these days apply some intelligence in determining where to fetch records from given a choice. It is my understanding that they typically measure the response times for each authoritative server. Hence given that my own DNS server, running over the tunnel, would undoubtedly be the slowest of the bunch it would likely see less than its fair share of queries over the long term thus general performance for those accessing my services ought not to be impacted. It does mean though that I could continue with the HE certification as the tests are only after a single native-IPv6 path through the DNS to be available, and forces me to learn a bit about BIND in the process!

All that said, having just checked the DNS config for mrball.net I see that you appear to have gone down this route already so you're clearly one step ahead!

Apologies for the rambling - if you got this far you deserve a medal.

Mathew

[snarked]

For those machines which are servers, I assign them a "low address" of the form "...::domain:host" (I have multiple domain names).  The "host" part i keep the same for all of the same function (e.g. all mail servers get a "3", all primary DNS servers get a "1", usenet gets a "4", etc.)  This also keeps the 5th quad (bits 65-80) as all zero while stateless autoconfiguration has one or more one-bits in that range.  Hosts using stateless autoconfig. regardless of domain are not meant for incoming, so they don't need an easily rememberable assignment, nor do they need an assignment in their domain like for servers.

In this plan, domain = 0 is for certain gateway functions and for outbound queries from the servers not tied to particular domains.

Lastly, there is one function where I don't follow the pattern:  SSH.  The SSH address, which has ONLY the SSH port in use (which may or may not be 22), is definently outside of the patterns - to prevent casual address+port scanning.  As of this time, all port scanning seems to be IPv4 only.  For those hiding an SSH port by means of "port knocking," the knocking port may be at yet a different address.

Granted that "security by obscurity" isn't really a solution, but IPv6 is so vast and sparse, it certainly helps.

[jimb]

@newton: One way to avoid any impact on your primary domain is to simply use a subdomain and delegate it to some IPv6 server reachable on your HE IPv6 address space.  That's what I did.

@snarked: yikes.  You use different ports for knocking and SSH itself on different servers?  You must need to keep a list!   :P

[snarked]

@snarked: yikes.  You use different ports for knocking and SSH itself on different servers?  You must need to keep a list!

Not only different ports, but different IP addresses too.  As long as they're served by the same firewall, the addresses need not be the same (and for me, it's not).

Some people have suggested a "double knock."  I have found that unnecessary.  A single knock with a small timeout is usually sufficient - especially when the default action for unreachable ports and strange things is to tarpit the offender.  For TCP, I use the built-in tarpit function, and for everything else, I tarpit using a "recent" list (iptables/ip6tables style).

[jimb]

@snarked: yikes.  You use different ports for knocking and SSH itself on different servers?  You must need to keep a list!

Not only different ports, but different IP addresses too.  As long as they're served by the same firewall, the addresses need not be the same (and for me, it's not).

Some people have suggested a "double knock."  I have found that unnecessary.  A single knock with a small timeout is usually sufficient - especially when the default action for unreachable ports and strange things is to tarpit the offender.  For TCP, I use the built-in tarpit function, and for everything else, I tarpit using a "recent" list (iptables/ip6tables style).

Yeah I don't go that far.  I just have a port knock with a relatively small timeout, and also run fail2ban behind it.  If they manage to knock and find the SSH port, they get two tries, then the IP goes into hosts.deny.

[NewtonNet]

@newton: One way to avoid any impact on your primary domain is to simply use a subdomain and delegate it to some IPv6 server reachable on your HE IPv6 address space.  That's what I did.

Hi jimb,

Yes - I had considered that, and this may stupid, but I thought it was kind of 'cheating' to do so!  ;) To be honest, I think deep down I probably just wanted an excuse to go the whole hog!

Mathew

[bombcar]

@snarked: yikes.  You use different ports for knocking and SSH itself on different servers?  You must need to keep a list!

Not only different ports, but different IP addresses too.  As long as they're served by the same firewall, the addresses need not be the same (and for me, it's not).

Some people have suggested a "double knock."  I have found that unnecessary.  A single knock with a small timeout is usually sufficient - especially when the default action for unreachable ports and strange things is to tarpit the offender.  For TCP, I use the built-in tarpit function, and for everything else, I tarpit using a "recent" list (iptables/ip6tables style).

Yeah I don't go that far.  I just have a port knock with a relatively small timeout, and also run fail2ban behind it.  If they manage to knock and find the SSH port, they get two tries, then the IP goes into hosts.deny.

This can be dangerous - you're basically giving control of your firewall to unknown outside entities.

I just make sure SSH is secure, passwords are long, and keys are good, and they can try to get in all they want.

[jimb]

@snarked: yikes.  You use different ports for knocking and SSH itself on different servers?  You must need to keep a list!

Not only different ports, but different IP addresses too.  As long as they're served by the same firewall, the addresses need not be the same (and for me, it's not).

Some people have suggested a "double knock."  I have found that unnecessary.  A single knock with a small timeout is usually sufficient - especially when the default action for unreachable ports and strange things is to tarpit the offender.  For TCP, I use the built-in tarpit function, and for everything else, I tarpit using a "recent" list (iptables/ip6tables style).

Yeah I don't go that far.  I just have a port knock with a relatively small timeout, and also run fail2ban behind it.  If they manage to knock and find the SSH port, they get two tries, then the IP goes into hosts.deny.

This can be dangerous - you're basically giving control of your firewall to unknown outside entities.

I just make sure SSH is secure, passwords are long, and keys are good, and they can try to get in all they want.

What is?  Port knocking or fail2ban?  I could see how fail2ban could be abused if you don't properly filter source addresses, but otherwise it's not a big deal.  You can put exclusions in its config too so it never bans a particular IP range.

Tarpitting on a single "bad" packet perhaps is a bit extreme.  I don't do that though.  :P

[bombcar]

Port knocking is a cute toy; but you can get a significant amount of its advantage simply from the vast size of the IPv6 address space.

fail2ban is more dangerous; I used to use it but I was bit by it a few times - for example, if you have 7 or 8 SSH keys loaded, you may get banned because SSH just tries each key, one after the other, and most systems limit it to 5 goes.

[jimb]

Port knocking is a cute toy; but you can get a significant amount of its advantage simply from the vast size of the IPv6 address space.

fail2ban is more dangerous; I used to use it but I was bit by it a few times - for example, if you have 7 or 8 SSH keys loaded, you may get banned because SSH just tries each key, one after the other, and most systems limit it to 5 goes.

Sure you could do that too.  Add a random IPv6 to your box, have SSH listen on that instead of the 'main' IPv6 (where perhaps www or whatever is pointing).  But this is for IPv4 too.  And the port knock would provide yet another layer in case they find your IPv6 by say, sniffing your traffic.  They might not catch the port knock, but only see your much longer lasting SSH session.  Anyway, defense in depth!  :P

fail2ban works based on the logfile.  I use identity keys all the time and it doesn't seem to have a problem.  Like I said, you can put exceptions in.  You might have had a bad fail2ban configuration which matched a bit too loosely on the log entries.  I'd think you could tailor it to only match true failed logins.  Mine is actually set to ban on two.  But of course my local LAN is excepted.  :)