IPv6
Put the home network in a private, FC::/7, IPv6 network. The 8th bit is a 1 for private and 0 for reserved per RFC4193. Therefore, the private IPv6 RFC1918 like addressing is FD::/8. This network was deployed with FD00::0/120 [FD00:0000:0001:0001:0000:0000:0000:0000]/120. I made the nodes end in the same number in hex as the device current ending last octet IPv4 node number.
The IPv6 address space used, a /120, helped to magnify and prove how some devices that support IPv6 cannot get a IPv6 address using SLAAC; Stateless Address Autoconfiguration. SLAAC requires the user subnet is a /64 or short mask. The client can configure its own address based on the router advertisement (RA). The client can learn the network its on, a /64 or shorter mask, that is in the router advertisement that has the router IPv6 address as the gateway address, and then assign its own node based on its MAC address. If the mask is longer then /64 like a /120, this is not possible and some clients cannot join the network. After the testing was completed with the /120 network, the network was converted over to a /64. All hosts created IPv6 addresses.
RA – router advertisement message format from RFC 4861
The client identifier, node portion of the IPv6 address, would then be created from the MAC address that is assigned to host, and for this example 0200:1234:5678. The first step of EUI-64 conversion is to split the MAC address in half and place FF:FE in the middle, which results in 0200:12FF:FE34:5678. Then the seventh bit will be flipped, in this case the first 8 bits is 00000010 (0x02). Next, the seventh bit is flipped and the bit becomes 0, resulting in 00000000 (0x00); this gives a final host identifier result of 0000:12FF:FE34:5678. When the prefix and the host identifier are brought together, it results in an IPv6 address that is used for Host of FD00:0000:0001:0001:0000:12FF:FE34:5678, which can be shortened to FD00:0:1:1::12FF:FE34:5678.
The NAT64 IP range in RFC 6147 is 64:ff9b::0/96. It doesn't matter what range you use in your private network. As long as the router destination static NAT to inet from zone trust/internal and the bind DNS server dns64 section match exactly.
The IPv4 address of the destination resource embedded by the DNS64 server and destination address translated from the DNS64 IPv4 address at the Firewall, or Internet router, is converted from decimal to hex. To convert 97.17.53.254, convert 97 to hex; 61. Then 17 is 11. 53 is 35. 254 is fe. So the hex value is 611135fe or 6111:53fe. It is then appended to the 64::ff9b::/96 network number; 64:ff9b::6111:53fe.
A PC does a DNS lookup for a name to the PC configured DNS server; DNS64 server. The DNS64 server gets the AAAA record if it exists. If the AAAA response is empty, it then requests the IPv4 A record and then converts the result into a hex value and puts it in the 64:ff9b::0/96 IPv6 address. This response goes back to the PC doing the name to IPv6 lookup. Then the PC sends the towards the IPv6 address. When the packet arrives art the firewall, the firewall does a destination NAT converting the IPv6 address back to an IPv4 address that was embedded in the IPv6 packet by the DNS64 server.
In the second step, the first response to the recursive lookup made by the DNS64, if it gets a IPV6 address, the DNS64 server responds to the PC query with the AAAA IPv6 record IPv6 address. If the private network does not have IPv6 connectivity to the Internet, the User Computer will fail accessing the resource or web site. The private network requires ALL IPv6 NAT6 to 4.
Therefore, even if the DNS64 server gets a IPv6 address, it must ignore it and get the IPv4 record so it can embed the IPv6 address in the response to the User Computer. Then when the User computer sends its request towards the web site using the IPv6 address from the DNS64 server, the firewall/router will be able to translate the IPv6 address with the embedded IPv4 address to the web site IPv4 address and forward the User Computer request towards the website IPv4 address. To be sure the DNS64 server ALWAYS embeds the IPv4 IP, the ‘exclude’ stanza is configured in the DNS64 bind configuration file.
This is why the DNS64 stanza IPv6 network number must match the firewall/router NAT64 device configured destination NAT network exactly.
When configuring the destination and source NAT’s, it is required to configure both source and destination addresses in the groups. Otherwise, some NAT services may be unresponsive. If the destination static NAT to the inet does not have a source address of any IPv6 address at minimum, it will evaluate all IPv6 and IPv4 breaking IPv4 destination NAT hosting services still on IPv4 in the private network.
When planning, does the printer, Wireless Access Point, Servers, other PC’s, Apple TV box, and set top boxes all support IPv6 addressing.
SRX210HE2-PoE 12.1X46.65.4
set security forwarding-options family inet6 mode flow-based
set security nat source pool ipv6pool address 45.27.250.243/32 to 45.27.250.243/32
set security nat source rule-set trust-to-untrust from zone trust
set security nat source rule-set trust-to-untrust rule nat64-src-nat1 match source-address fd00::/120
set security nat source rule-set trust-to-untrust rule nat64-src-nat1 match destination-address 0.0.0.0/0
set security nat source rule-set trust-to-untrust rule nat64-src-nat1 then source-nat pool ipv6pool
set security nat static rule-set nat64-vlan-trust from zone trust
set security nat static rule-set nat64-vlan-trust rule ipv6-clients1 match source-address ::/0
set security nat static rule-set nat64-vlan-trust rule ipv6-clients1 match destination-address 64:ff9b::/96
set security nat static rule-set nat64-vlan-trust rule ipv6-clients1 then static-nat inet
set security nat proxy-arp interface ge-0/0/0.0 address 45.27.250.243/32 to 45.27.250.246/32
set security nat natv6v4 no-v6-frag-header
You do not have to setup your own DNS64 server as shown below. You can simply assign Internet DNS servers where you NAT64 converting the DNS IPv4 address to your NAT64 IPv6 address. The firewall doing the NAT64 will convert back to IPv4 on the way out to the Internet when your client or PC does a DNS lookup. The following are DNS IPv6 addresses you can configure in your ‘o’ flag DHCPv6 server settings or statically assign to your clients. The IPv6 address is based on the firewall NAT64 configuration with 64:ff9b::/96. Then the Internet DNS servers IPv4 address are conveted from IPv6 to IPv6 and embedded in the 64:ff9b::/96 IPv6 address.
Google DNS64 converted NAT64 IP
64:ff9b::808:808
OpenDNS DNS64 converted NAT64 IP
64:ff98::d043:dcdc
64:ff98::d043:dede
Or, to set up your own DNS using Bind9 DNS Server you can configure the following.
acl "trusted" {
192.168.0.0/24;
127.0.0.0/24;
fd00::/120;
};
options {
forwarders {
8.8.8.8;
8.8.4.4;
listen-on-v6 port 53 { ::1; fd00::5; };
allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
dns64 64:ff9b::/96 {
clients { any; };
exclude { ::/0; };
break-dnssec yes;
};
};
If there is DNS domains hosted as authoritative on this DNS server, the IPv6 ‘AAAA’ records will need to be created in additional to the IPv4 ‘A’ records for the IPv6 clients. If the servers are outside the firewall, on the Internet in this example, the records will need to be converted into the NAT64/DNS64 format so the firewall will convert the IPv6 address to an IPv4 address on the way out to the server. And place the ‘AAAA’ records first in the file above the ‘A’ records. Bind does a lookup to see if there is a ‘AAAA’ first before it responds with the ‘A’ record.
This is an example conversion as outlined above in converting an IPv4 address to a IPv6 address.
Convert each octet of the IPv4 address 54.192.82.145, 54, 192, 82, 145, to 36, c0 ,52, 91, and add the prefix 64:ff98:: to get 64:ff98::36c0:5291. Then enter the AAAA in bind.
host AAAA 64:ff98::36c0:5291
host A 54.192.82.145
Any IT Telecom Architecture and Design Architect will advise migrating to IPv6 from IPv4 utilizing “Dual-Stack”; all the network interfaces have an IPv4 address and an IPv6 address. You are also likely to find out that about 80%, or maybe even less, of all your server and device interfaces can support dual stack. You are also likely to discover DHCPv6 can provide most, but not all, devices an IPv6 address which can be registered in DNS. A host with IPv6 must have a DNS entry. It is extremely difficult to remember all those 128 bit long HEX addresses. A bit more difficult than those 32 bit decimal IPv4 addresses.
In spite of the challenges with dual stack, it is still the best approach. And it is much easier to depend on DNS lookups for your migration than any NAT or tunneling mechanisms that also have the potential to degrade application performance or cause odd behaviors in the application. Tunneling and NAT for IPv4 to IPv6 migration should be the last resort for those non-complaint arduous server and device interfaces.
The migration must also include a “IPv6 Readiness Review” Plan. It is imperative to identify every application and interface in the network and confirms that all support IPv6 addressing. Plans then need to be made to migrate with this knowledge. It will be much easier to plan when knowing the obstacles and knowing where you have to use the NAT or Tunnel (really encapsulation) technology. And do not forget that an interface now gets a multitude of IPv6 addresses and each are for different uses.
For IPv6 stateful, DHCPv6 managed and other flags, the interface will receive a global or site scoped routed IPv6 address. It will also have a link local address that is used to get this address and if on a router, used for all the IGP routing protocols. It can also get Multicast IPv6 addresses. So this can impact DNS if the devices or servers register their name in DNS. How many and what addresses does it register? All devices should be tested as part of the Readiness Review process.
Complete the Routed network Readiness Review first. Then while you are conducting your Readiness Review on the rest of the network, which is likely 90% of the total Readiness Review, go ahead and dual stack all your routers and all their protocols. Then begin migrations a few systems at a time. DNS will assist in the migration. Just be sure you have very very fast DNS servers to handle (2) lookups for those ‘waiting migration’ IPv4/IPv6 dual stack systems. The IPv6 lookup is first and if no AAAA record, the IPv4 record is requested. You should find that both DNS requests are sent form the device at the same time.
Below is a digram illustrating the DNS dual stack migration lookup process.
