This document intends to provide information on how IPv6 works especially around ISP’s and their customers. Its sources are RFP’s and APNIC guidelines.

The stand-out is we need to stop being conservative about how many numbers are being given, instead focusing on future proofing networks to provide growth. As an indicator, If we distribute all IPv6 addresses evenly across the Earth’s surface, each square meter would have approximately 6.67×10²³ IPv6 addresses (or about 7 with 23 zeros). This vast number illustrates the enormous address space IPv6 provides.

Also important is DNS as each number in a block should have a reverse lookup to a name. This should be delegated based on the size of the assigned block (/48, /56, /64) so not to add extra administrative load on the ISP.

A difference between IPv4 and IPv6 is DHCP. With IPv4 you can use private address space eg 192.168.1.35, however IPv6 is so large that only public numbers are recognised. From an ISP perspective, this means issuing number ranges to customers.

Question:

Is there a documented standard on how to split up ipv6 for example an ISP gets /32, they provide their customers with /48 for business and /56 for personal and the smallest single subnet is /64?

Answer:

Yes, there are documented best practices and recommendations for IPv6 address allocation, especially for ISPs, which have been standardized by organizations such as the Internet Engineering Task Force (IETF). One of the main documents for IPv6 address allocation recommendations is RFC 6177 (Address Allocation for IPv6). Here’s a summary of the common practices:

1. ISP Allocation (Typically /32):
   • ISPs are commonly assigned a /32 prefix, which provides 2^16 (65,536) possible /48 subnets.
   • The /32 assignment is large enough to support hierarchical allocation for customers, allowing ISPs to subdivide it further as per their customer requirements.
2. Customer Allocation:
   • Business/Enterprise Customers (Typically /48):
     • RFC 6177 and related documents recommend that ISPs allocate a /48 to business and enterprise customers.
     • A /48 allocation gives each business customer 65,536 possible /64 subnets, which is generally more than sufficient for enterprises needing multiple subnets across different departments or locations.
   • Residential/Personal Customers (Typically /56 or /64):
     • For residential or personal customers, a /56 or /64 is usually recommended.
     • A /56 provides 256 /64 subnets, which is adequate for most home users who may want multiple subnets (e.g., for separate IoT networks, guest networks, etc.).
     • Some ISPs may choose to allocate only a single /64 to residential customers, especially if they don’t anticipate the need for multiple subnets. However, this can limit future flexibility and is generally less preferred.
3. Smallest Subnet Size (Typically /64):
   • /64 Subnets as the Standard Smallest Subnet:
     • According to IPv6 standards (RFC 4291), /64 is the standard subnet size for IPv6.
     • A /64 subnet provides the full 64 bits of host addressing space, which is important for certain IPv6 functionalities, such as Stateless Address Autoconfiguration (SLAAC) and Neighbour Discovery Protocol (NDP).
     • /64 is also often the smallest practical subnet size due to hardware and protocol constraints that rely on a /64 boundary for operations.

Summary of Recommended IPv6 Allocation Practices:

• ISP Allocation: Typically /32 or larger.
• Business/Enterprise Customers: /48 (or larger, if justified).
• Residential Customers: /56 (or /64 if only a single subnet is needed).
• Smallest Subnet Size: /64.

These allocations are designed to support scalability and flexibility for future growth, as IPv6 has a vastly larger address space than IPv4. ISPs are encouraged to err on the side of providing larger allocations, as this minimizes the need for renumbering and ensures sufficient address space for customers’ potential needs.

Question:

What are the recommendations for reverse DNS of IPv6?

Answer:

1. Use the IP6.ARPA Domain

• IPv6 reverse DNS lookups use the ip6.arpa domain, where each nibble (4-bit segment) of the IPv6 address is represented in reverse order.
• For example, the IPv6 address 2001:db8::1 would have a reverse DNS entry of:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.8.d.0.1.0.0.2.ip6.arpa

2. Allocate Reverse DNS Zones Based on Prefix Length

• IPv6 address spaces are typically allocated in blocks like /32, /48, /56, and /64, so it’s important to set up reverse DNS zones based on the delegated prefix length.
• For example, if an ISP has a /32 block, it can delegate individual /48 or /56 reverse DNS zones to customers, allowing customers to manage reverse DNS entries for their assigned addresses.

3. Delegate Control of Reverse DNS for Customer Prefixes

• When an ISP provides a prefix to a customer (such as a /48 or /56), best practice is to delegate control of the reverse DNS entries to the customer.
• The ISP can delegate the appropriate part of the ip6.arpa zone to the customer’s DNS servers, which enables the customer to manage PTR records for individual addresses within their prefix.
• For example, for a customer with a /48 prefix, the ISP would delegate the first 48 bits in reverse nibble format to the customer’s DNS, allowing them to create entries under their allocated block.

4. Using Dynamic DNS for SLAAC and DHCPv6 Addresses

• If the ISP or network assigns IPv6 addresses dynamically, such as with SLAAC (Stateless Address Autoconfiguration) or DHCPv6, consider using Dynamic DNS (DDNS) to update reverse DNS entries in real-time.
• This helps maintain accurate reverse DNS records, especially in environments with frequently changing IPv6 addresses.

5. Avoid Individual PTR Records for Each IPv6 Address When Possible

• Due to the sheer size of the IPv6 address space, manually creating individual PTR records for each address can be impractical and unnecessary.
• For large blocks like /64 (with a virtually unlimited number of host addresses), it may be more practical to create PTR records only for key hosts or services and skip PTR records for less critical devices.

6. Document Reverse DNS Procedures and Prefix Delegations

• Documenting how reverse DNS is handled, especially with multiple delegations (e.g., from ISP to enterprise, then possibly to department level), helps keep the reverse DNS structure organized.
• Clear documentation of delegated blocks and DNS zones helps ensure consistency and allows different teams or organizations to manage their respective reverse DNS zones independently.

7. Automation and Bulk PTR Management

• Given the size of IPv6 address space, automate the creation of PTR records wherever possible, especially if managing large address ranges.
• Tools for bulk PTR creation can help efficiently manage reverse DNS for common address patterns (e.g., standard naming conventions for devices within an enterprise).

Example for Delegating a /48 Prefix Reverse Zone

If an ISP has allocated a /48 prefix (e.g., 2001:db8:1234::/48) to a customer, it could delegate control of the corresponding reverse DNS zone (4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa.) to the customer’s DNS servers, allowing the customer to create reverse DNS entries like:

• 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa → example-hostname.com

Summary

• Use ip6.arpa domain with reversed nibbles.
• Delegate reverse DNS for customer prefixes (e.g., /48 or /56).
• Implement DDNS for dynamic IPv6 addresses.
• Limit PTR records to key addresses, automating when feasible.
• Document delegation procedures and automate bulk management where possible.

These recommendations help manage the complexity of IPv6 reverse DNS while ensuring that key addresses remain accessible for reverse lookups.

Question:

At what point is an end user expected to maintain such databases

Answer:

In IPv6, end users are generally expected to manage reverse DNS (rDNS) only when they are allocated a significant and semi-permanent prefix by their ISP or provider, such as a /48 or /56 prefix. Here are some guidelines on when end users might be expected to maintain their own reverse DNS database:

1. Business or Enterprise Users with a /48 or /56 Prefix

• When a business or enterprise customer receives a /48 or /56 prefix, they often have multiple subnets or a network with devices requiring identifiable hostnames. In this case, managing reverse DNS records can be beneficial for internal management, troubleshooting, and remote connectivity.
• For these users, ISPs often delegate reverse DNS control, allowing the business to manage PTR records for individual addresses within their allocation.
• Enterprises that run services (such as web, mail, or other public services) often prefer maintaining rDNS to ensure these services have properly mapped PTR records.

2. Service Providers (e.g., Hosting, Cloud Providers)

• ISPs or hosting providers who lease IPv6 space to customers, especially for virtual or dedicated servers, often delegate rDNS for specific IP ranges to customers.
• Customers leasing dedicated or virtual servers are generally expected to manage their own rDNS if they want specific hostname mappings for each server or service.

3. Residential Users with Dynamic or Single /64 Allocations

• For typical residential customers, especially those assigned /64 or smaller prefixes, the expectation to manage reverse DNS is generally low to none.
• If an ISP provides dynamically assigned addresses (e.g., through DHCPv6 or SLAAC), reverse DNS management is typically handled by the ISP, often through Dynamic DNS (DDNS), which updates PTR records in real-time as addresses change.
• For static IP assignments in residential contexts, ISPs may allow users to request specific reverse DNS entries for public-facing IPs (e.g., for a home server) but usually do not expect users to manage a full reverse DNS database.

4. When IPv6 PTR Records are Unnecessary

• For large organizations or residential networks where most devices do not require unique reverse DNS (e.g., IoT devices or internal-only systems), maintaining PTR records is often unnecessary.
• Users can opt to manage PTR records only for critical services or hosts that need clear reverse DNS identification (e.g., mail servers, publicly accessible services), while other devices may not have PTR records at all.

Practical Approach for End Users

• ISPs Provide the Framework: ISPs are responsible for delegating and automating rDNS management up to the end user’s allocated prefix.
• End Users Configure Key PTR Records Only: End users are encouraged to configure PTR records only for critical services or devices that need consistent reverse DNS entries.
• Automation Tools: For end users with larger address blocks, using automation tools or dynamic DNS solutions can simplify rDNS management without requiring manual PTR updates.

Summary

End users are expected to maintain reverse DNS databases primarily in business or enterprise scenarios, or when they lease server space from hosting providers. For typical residential users, ISPs manage rDNS, and minimal maintenance is expected. Automation tools help larger end users manage rDNS when needed.

Question:

Are there any references to documented standards and/or guidlines?

Answer:

Yes, there are several authoritative documents and guidelines that discuss IPv6 reverse DNS (rDNS) delegation, best practices, and expectations for end users. Here are some key standards and guidelines:

1. RFC 3596 – DNS Extensions to Support IP Version 6

• This RFC defines the ip6.arpa domain and the method of mapping IPv6 addresses to reverse DNS records. It specifies how IPv6 addresses are represented in reverse, using nibbles (4-bit segments) of the IPv6 address in the reverse domain.
• Reference: RFC 3596

2. RFC 4193 – Unique Local IPv6 Unicast Addresses

• This RFC defines unique local addresses (ULAs) in IPv6 and provides recommendations on reverse DNS for ULA space. ULAs are often used in private networks, and reverse DNS is generally not required or expected for ULA addresses unless the organization has specific internal requirements.
• Reference: RFC 4193

3. RFC 5855 – Nameservers for IPv4 and IPv6 Reverse Zones

• This RFC provides guidelines for operating reverse DNS zones for both IPv4 and IPv6. It discusses the delegation of in-addr.arpa for IPv4 and ip6.arpa for IPv6, covering the hierarchical structure of DNS for these zones.
• Reference: RFC 5855

4. RFC 6177 – IPv6 Address Assignment to End Sites

• This RFC, a key document on IPv6 address allocation, recommends prefix sizes for end sites and the level of flexibility that ISPs should provide to customers. It suggests that end users receiving a larger allocation (like /48 or /56) may be responsible for managing their reverse DNS zones.
• Reference: RFC 6177

5. Best Current Practice (BCP) 20 – RFC 1912: Common DNS Operational and Configuration Errors

• Although RFC 1912 is an older document primarily focused on IPv4, it includes foundational DNS practices that are also applicable to IPv6, such as reverse DNS importance, PTR record management, and proper delegation practices.
• Reference: RFC 1912

6. ARIN, RIPE, APNIC, and Other RIR Guidelines on IPv6 Delegation

• The Regional Internet Registries (RIRs) like ARIN (American Registry for Internet Numbers), RIPE NCC (Réseaux IP Européens Network Coordination Centre), and APNIC (Asia-Pacific Network Information Centre) provide additional guidelines on IPv6 delegation, including reverse DNS.
• For example, RIPE’s document “IPv6 Address Allocation and Assignment Policy” recommends that ISPs delegate reverse DNS for customer prefixes (e.g., /48) if the customer has an identifiable need.
• APNIC IPv6 Guidelines: APNIC IPv6 Addressing
• RIPE IPv6 Policy: RIPE IPv6 Address Allocation and Assignment Policy

7. IETF IPv6 Operations (v6ops) Working Group Documents

• The IETF’s IPv6 Operations Working Group (v6ops) regularly publishes best practice recommendations for IPv6 deployment, including guidance on reverse DNS. Their recommendations often address operational best practices for ISPs and enterprises, including reverse DNS expectations.
• IETF v6ops Working Group: v6ops WG

Summary of Recommendations from These Documents

• ISPs: Allocate reverse DNS zones to business or enterprise customers (typically with a /48 or larger prefix) and delegate control for these zones if needed.
• Enterprise Customers: Manage reverse DNS for public-facing or critical infrastructure, especially if they receive dedicated IPv6 space.
• Residential Users: Reverse DNS delegation is generally not expected unless required for specific services; the ISP typically manages dynamic rDNS updates.
• PTR Records: Create PTR records for essential devices or services, particularly those that require identifiable reverse DNS mappings, to avoid unnecessary PTR record management in very large IPv6 address spaces.

By following these standards and guidelines, ISPs, businesses, and end users can effectively manage reverse DNS, balancing operational needs with the vast address space of IPv6.

Question:

RFC 6177 makes mention that getting ipv6 number resources should be easy or similar. Is that correct?

Answer:

Yes, RFC 6177 emphasizes that obtaining IPv6 address space should be relatively straightforward. The document revises earlier IPv6 allocation policies to address concerns about the scarcity of IPv4 and to promote the adoption of IPv6 by making address space more accessible.

Here’s what RFC 6177 states regarding the ease of obtaining IPv6 address resources:

1. Ease of Allocation:
   RFC 6177 suggests that IPv6 address allocation policies should be flexible, allowing end sites to easily obtain sufficient IPv6 address space without restrictive requirements. This contrasts with IPv4, where conservation measures are strict due to limited address availability.
2. Encouragement for Adoption:
   By recommending that address space allocations be more accessible, RFC 6177 aims to promote IPv6 deployment by reducing barriers that may discourage organizations from adopting IPv6.
3. Customer Prefix Size Recommendations:
   The document recommends that ISPs allocate enough IPv6 space (e.g., /48 for businesses or /56 for residential users) to meet current and foreseeable future needs, again emphasizing ease and adequacy of allocation over restrictive conservation.
4. RIRs and Address Management:
   RFC 6177 encourages Regional Internet Registries (RIRs) to facilitate IPv6 address requests without imposing overly complex criteria, making IPv6 resources more readily available to network operators and end sites.

So, yes, RFC 6177 does advocate for making IPv6 address allocation “easy,” aiming to simplify processes and encourage widespread IPv6 adoption.

References:

https://www.apnic.net/about-apnic/corporate-documents/documents/resource-guidelines/ipv6-guidelines

https://datatracker.ietf.org/doc/html/rfc3596

https://datatracker.ietf.org/doc/html/rfc6177