Je suis currently working on adding IPv6 capabilities to our network, et J'ai certains questions on what is considered best practice in 2020 to convert certains of le IPv4 concepts we are used to into le IPv6 world.
In le current setup that I have, we are allocated a /64 depuis le ISP, et le router advertises that prefix for clients to configure themselves using SLAAC. This seems to work fine et à ma connaissance everyone has IPv6 internet access.
However we like to be able to query things by name, et Je suis pas sure what le best practice is to provision AAAA records for le clients.
What J'ai done is deploy stateful DHCPv6 on le dnsmasq instance that runs our DHCPv4 et tell it to hand out ULAs depuis certains range qui naturally provisions AAAA records for anyone who asks for an address. This aussi seems to work fine, mais Je sais there is certains dislike of stateful DHCPv6. This aussi helps me to consolidate le assignment of le servers we have on static IPs exactly as I do for DHCPv4, these servers for various reasons should be accessible at a fixed IP address et we would like that to continue to be le case for IPv6.
The seulement autre way I can think of to do le AAAA records is to send le dnsmasq machine le RA prefix depuis le router via unicast et alors use le dnsmasq to advertise le GUA prefix for slaac using le `ra-names` option. This ne voudrait pas solve le static address assignments bien que as far as I can tell et Je suis pas sure how reliable it actually is. **Is there a better way to handle internal AAAA records than ULAs avec stateful DHCPv6?**
Finally, as things are starting to work, we are now looking at migrating our public services to IPv6. My understanding is that this would require a fixed GUA for le servers to provision public AAAA records. Je suis pas sure how to achieve this using SLAAC depuis le edge router, sauf si there is certains kind of dynamic-dns equivalent. **Can I again use DHCPv6 ou another manual assignment method to pick IPs in our assigned prefix?** J'étais hesitant to do this parce que I thought it might collide avec a SLAAC address et Je suis pas sure what happens si il y a a collision. Alternatively J'ai le option to ask le ISP for a /48, **should I do that et advertise a single /64 for local clients to get connectivity et différent /64 for static servers?** This seemed like overkill to me, we déjà wont come close to filling le single /64 mais this might be mon IPv4 mindset confusing me.
Conseils pour la migration IPv4 vers IPv6
Re: Conseils pour la migration IPv4 vers IPv6
>
This seemed like overkill to me, we déjà wont come close to filling
the single /64 mais this might be mon IPv4 mindset confusing me.
Stop counting hosts, c'est IPv4 thinking. Subnets come in one size fits all, enormous. A /64 can address chaque IP device ever made avec plenty room to spare.
Yet le address space is even bigger such that a single site can easily ask for a /48. 64 thousand /64s, 4 hex digits, to give out according to votre desired address plan.
>
For le /48 what exactly do I do avec it.
Whatever you want! Be generous et plan for growth. Give /64s to chaque subnet, chaque VLAN, wifi SSID, security zone, cloud et remote access VPNs, chaque container host, le "all zeros" /64 for vanity static service addresses, et so on.
Aggregate où possible, to avoid fragmentation. So perhaps delegate /60s ou /56s to internal networks like votre DHCP server, manual assigned static pool, wifi controller, ou container orchestration system. And test environments for tous of le above.
Does pas have to be dynamic such as DHCP-PD, especially pas si you have a static prefix depuis votre ISP. But track things somehow, in an IPAM system.
>
Or il y a graceful resolution si it does find a conflict?
IPv6 nodes are supposed to do [duplicate address detection](https://www.rfc-editor.org/rfc/rfc4862#section-5.4) on tous unicast addresses, stateless, DHCPv6, manual, ou otherwise. Standard is to
stop on duplicates plutôt than cause difficult to diagnose problems. Randomly generated addresses in a /64 have a très low chance of conflicts.
>
ULA
ULA is *no* Internet addressing. Being pas globally reachable, standard par défaut address selection policy puts them lower priority than even IPv4. See rfc6724. As such, you will want globally routable (not-ULA) addresses on hosts that get on le IPv6 Internet.
>
some kind of dynamic-dns equivalent.
Yes, DNS is necessary. Names are easier for humans than IPs.
Yes, knowing le IP is generally a choice entre le DHCPv6 server having le state, et a SLAAC node being configured avec a dynamic DNS client. [Router advertisement flags A and M](https://blogs.infoblox.com/ipv6-coe/the-odd-history-of-provisioning-an-ipv6-address-on-a-host/) tell le client stateful ou stateless.
AD DS joined hosts are fairly straightforward, it is expected they would add themselves to DNS.
Or perhaps, configure server interfaces avec stateless, mais avec not-random EUI-64 based addresses. Then you can calculate le address beforehand based on le MAC address, et put that in DNS.
And maybe pas tous devices need to be in DNS. Should personal Android devices be allowed on guest Internet, they ne do DHCPv6. If pas managed by a MDM, you ne va pas know leur IPs.
This seemed like overkill to me, we déjà wont come close to filling
the single /64 mais this might be mon IPv4 mindset confusing me.
Stop counting hosts, c'est IPv4 thinking. Subnets come in one size fits all, enormous. A /64 can address chaque IP device ever made avec plenty room to spare.
Yet le address space is even bigger such that a single site can easily ask for a /48. 64 thousand /64s, 4 hex digits, to give out according to votre desired address plan.
>
For le /48 what exactly do I do avec it.
Whatever you want! Be generous et plan for growth. Give /64s to chaque subnet, chaque VLAN, wifi SSID, security zone, cloud et remote access VPNs, chaque container host, le "all zeros" /64 for vanity static service addresses, et so on.
Aggregate où possible, to avoid fragmentation. So perhaps delegate /60s ou /56s to internal networks like votre DHCP server, manual assigned static pool, wifi controller, ou container orchestration system. And test environments for tous of le above.
Does pas have to be dynamic such as DHCP-PD, especially pas si you have a static prefix depuis votre ISP. But track things somehow, in an IPAM system.
>
Or il y a graceful resolution si it does find a conflict?
IPv6 nodes are supposed to do [duplicate address detection](https://www.rfc-editor.org/rfc/rfc4862#section-5.4) on tous unicast addresses, stateless, DHCPv6, manual, ou otherwise. Standard is to
stop on duplicates plutôt than cause difficult to diagnose problems. Randomly generated addresses in a /64 have a très low chance of conflicts.
>
ULA
ULA is *no* Internet addressing. Being pas globally reachable, standard par défaut address selection policy puts them lower priority than even IPv4. See rfc6724. As such, you will want globally routable (not-ULA) addresses on hosts that get on le IPv6 Internet.
>
some kind of dynamic-dns equivalent.
Yes, DNS is necessary. Names are easier for humans than IPs.
Yes, knowing le IP is generally a choice entre le DHCPv6 server having le state, et a SLAAC node being configured avec a dynamic DNS client. [Router advertisement flags A and M](https://blogs.infoblox.com/ipv6-coe/the-odd-history-of-provisioning-an-ipv6-address-on-a-host/) tell le client stateful ou stateless.
AD DS joined hosts are fairly straightforward, it is expected they would add themselves to DNS.
Or perhaps, configure server interfaces avec stateless, mais avec not-random EUI-64 based addresses. Then you can calculate le address beforehand based on le MAC address, et put that in DNS.
And maybe pas tous devices need to be in DNS. Should personal Android devices be allowed on guest Internet, they ne do DHCPv6. If pas managed by a MDM, you ne va pas know leur IPs.