ip addressipv6
I have a /96 block of IPV6 addresses and i'm wondering how i could some how find the next address (Since ipv6 addresses can contain numbers and letters). I know the first address could be in numbers but i've yet to find out how i could really find in some kind of order for that amount of addresses
E.G: What technique could i use to make sure i'll actually be able to use all of the addresses
First and foremost, there is nothing to fear from being on a public IP allocation, so long as your security devices are configured right.
What should I be replacing NAT with, if we don't have physically separate networks?
The same thing we've been physically separating them with since the 1980's, routers and firewalls. The one big security gain you get with NAT is that it forces you into a default-deny configuration. In order to get any service through it, you have to explicitly punch holes. The fancier devices even allow you to apply IP-based ACLs to those holes, just like a firewall. Probably because they have 'Firewall' on the box, actually.
A correctly configured firewall provides exactly the same service as a NAT gateway. NAT gateways are frequently used because they're easier to get into a secure config than most firewalls.
I hear that IPv6 and IPSEC are supposed to make all this secure somehow, but without physically separated networks that make these devices invisible to the Internet, I really can't see how.
This is a misconception. I work for a University that has a /16 IPv4 allocation, and the vast, vast majority of our IP address consumption is on that public allocation. Certainly all of our end-user workstations and printers. Our RFC1918 consumption is limited to network devices and certain specific servers where such addresses are required. I would not be surprised if you just shivered just now, because I certainly did when I showed up on my first day and saw the post-it on my monitor with my IP address.
And yet, we survive. Why? Because we have an exterior firewall configured for default-deny with limited ICMP throughput. Just because 140.160.123.45 is theoretically routeable, does not mean you can get there from wherever you are on the public internet. This is what firewalls were designed to do.
Given the right router configs, and different subnets in our allocation can be completely unreachable from each other. You do can do this in router tables or firewalls. This is a separate network and has satisfied our security auditors in the past.
There's no way in hell I'll put our billing database (With lots of credit card information!) on the internet for everyone to see.
Our billing database is on a public IPv4 address, and has been for its entire existence, but we have proof you can't get there from here. Just because an address is on the public v4 routeable list does not mean it is guaranteed to be delivered. The two firewalls between the evils of the Internet and the actual database ports filter out the evil. Even from my desk, behind the first firewall, I can't get to that database.
Credit-card information is one special case. That's subject to the PCI-DSS standards, and the standards state directly that servers that contain such data have to be behind a NAT gateway1. Ours are, and these three servers represent our total server usage of RFC1918 addresses. It doesn't add any security, just a layer of complexity, but we need to get that checkbox checked for audits.
The original "IPv6 makes NAT a thing of the past" idea was put forward before the Internet boom really hit full mainstream. In 1995 NAT was a workaround for getting around a small IP allocation. In 2005 it was enshrined in many Security Best Practices document, and at least one major standard (PCI-DSS to be specific). The only concrete benefit NAT gives is that an external entity performing recon on the network doesn't know what the IP landscape looks like behind the NAT device (though thanks to RFC1918 they have a good guess), and on NAT-free IPv4 (such as my work) that isn't the case. It's a small step in defense-in-depth, not a big one.
The replacement for RFC1918 addresses are what are called Unique Local Addresses. Like RFC1918, they don't route unless peers specifically agree to let them route. Unlike RFC1918, they are (probably) globally unique. IPv6 address translators that translate a ULA to a Global IP do exist in the higher range perimeter gear, definitely not in the SOHO gear yet.
You can survive just fine with a public IP address. Just keep in mind that 'public' does not guarantee 'reachable', and you'll be fine.
2017 update
In the past few months, Amazon aws has been adding IPv6 support. It has just been added to their amazon-vpc offering, and their implementation gives some clues as to how large scale deployments are expected to be done.
To add one of the security benefits of NAT back in, they are now offering an Egress-only Internet Gateway. This offers one NAT-like benefit:
Which provides a layer of defense-in-depth, in case a misconfigred firewall rule accidentally allows inbound traffic.
This offering does not translate the internal address into a single address the way NAT does. Outbound traffic will still have the source IP of the instance that opened the connection. Firewall operators looking to whitelist resources in the VPC will be better off whitelisting netblocks, rather than specific IP addresses.
Routeable does not always mean reachable.
1: The PCI-DSS standards changed in October 2010, the statement mandating RFC1918 addresses was removed, and 'network isolation' replaced it.
The "Unique Local Address" is exactly what you're looking for. fc00::/7 gives you enough bits that if you generate a random number instead of just picking one the chances of collision are small.
Does this mean I'll need extra protections so my router would not automatically start advertising these private IPv6 addresses to the world?
The RFC that covers these ULAs (RFC4193) specifically states that these numbers should not be routed on the internet, though two peers may mutually agree to pass certain prefixes. Unless Comcast decides to unilaterally route these (unlikely in the extreme) you should have no worries about route advertisement.
Assuming I will never, ever, tie that IPv6 address into the real internet (a router will NAT & firewall it), can I ignore the RFC to an extent and go with fc00::4:0/120?
Don't assume that. For instance, Comcast is currently doing IPv6 trials and they're passing out /64's to end-users (slide 5); not just the single address they're doing with IPv4. This means that their now-running IPv6 testers have the option of running with globally routeable addresses, but firewalled by their router, or do some kind of NAT with either link-local or unique-global-addresses.
However, running without any kind of address translation is not as insane as it sounds. Keep in mind a few points.
Running without a firewall is still just as insane as it sounds, though. Happily, you can do firewalling without having to NAT.
Second question, what's this link-local thing?
Think of it as able to reach anything in the current broadcast domain, and can not be routed. Like NetBEUI-of-old. In fact, if your home network is completely flat you can use these addresses instead of Unique Local Addresses.
Third question, what is scope id for?
It's used for two different things, which makes it annoying to describe:
Thing 1: Multicast. It defines how far the multicast packet is intended to reach.
Thing 2: (What I think you're referring to) This is used on a URI as a way of defining which interface to use. It's used primarily with link-local addresses. It should never be used in conjunction with CIDR notation, so the two syntaxes should never be combined.
Best Answer
What do you mean by find the next address? Do you mean find the next block?
If you are using a /96 mask then your interface identifier part will be 32 bits in length.
In the standard colon delimited notation each colon delimited block represents 16 bits of the address, so if your block is:
2001:db8:0:0:0:9:0:0/96
The next block would be:
2001:db8:0:0:0:a:0:0/96
(i.e. you simply add one to the 6th field of the address)
If you want to calculate the next address within a block you simply add one to the address, sticking to the block range which would be from 2001:db8::9:0:0 to 2001:db8::9:ffff:ffff. Address 2001:db8::9:0:0 is reserved for the subnet router anycast address and cannot be assigned to an interface.
All addition would be simple hexadecimal integer arithmetic. The "letters" in the address are actually just hexadecimal digits.
One thing I would add is that a /96 block would be smaller than the recommended link addressing size of a /64. There is still debate around this but the current recommendation would be to stick with a /64 for each network segment unless you have a pressing need to do otherwise.