IPv6 – What to expect from your ISP and what you need to make use of it

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×1023 IPv6 addresses (or about 7 with 23 zeros). This vast number illustrates the enormous address space IPv6 provides.

An illustrations of the IPv6 network allocation concept, highlighting the vast address space and ISP distribution process. Let me know if you'd like any modifications!

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

What is the new Internet of Things or IoT An explanation of what the Internet of Things (IoT) and how it becomes part of your world

What is the Internet of Things or IoT for short?

In this article we’ll look at IoT or Internet of Things in the following contexts:

Introduction

For many years people have been using the internet to communicate and share with other people. With advances in computers making them so small and cost effective, now we are seeing more and more machines joining the internet to communicate with each other and interacting with people. While not new, the Internet of Things is fast growing in popularity with many new opportunities to have machine to machine collaboration improve how things work.

Both in and around the home, in manufacturing, in freight and logistics, aerospace, and many more industries IoT (Internet of Things) or M2M (Machine to Machine) communication using the Internet is opening doors.

Internet of Things and your home

what is the internet of things or iot

Google home mini when connected to your home automation allows you to talk to your home.

Imagine driving home in your car. Your car is telling your house where it is and who’s in the car. Your about 15 minutes away and the house starts getting ready for your arrival. It’s cold so it turns on the heating. It turns on the oven to start cooking the roast. All the time sending back messages to the car which in a Siri like manner lets you know what the house is doing.

When your about 50 meters away the garage doors open ready for your arrival. As you pull into the garage, the house alarm turns off and the doors unlock.

This is made possible because the car has a GPS and is connected to the Internet via the 4G phone network. Many of the appliances in the house have small computers in them that communicate to the main controller in the house. All these Things are using the Internet to communicate with each other to make your life more enjoyable.

Internet of things in the hospitality industry

A hotel has sensors that show how much beer is flowing and when. These sensors send the information to the cloud where it’s stored and matched with the sales data from the cash registers. At the same time it’s taking in information from temperature and humidity sensors that also send information to the cloud.

Over time it learns that the weather impacts on what customers buy and can start to predict what will be needed. Along with stock levels, the information is sent through to the brewers and the freight logistics systems so enough stock can be sent to the hotel in anticipation.

IoT in Physical security

Raspberry Pi with camera attached

Raspberry Pi with camera attached

Physical security is another area of growth with IoT.  Remote camera’s that sense people and regognise the faces they see is now achievable with simple of the shelf products like the Raspberry Pi with a camera module attached. When added to a home or office automation system brings even more benifit. Add some movement sensing to a camera it only needs to operate when something is there to check.

Internet of Things in Utilities sector

This is an area of significant size in the whole of the IoT industry. For us the most exiting part is the ability to see more detail of in home and in office electricity useage. As one of the biggest costs, electricity is something most people have an interest in reducing. The more data that can be collected the better the decissions are.

Conclusion

I don’t think anyone can really work out how many things are already connected to the Internet today, however many experts in the field like Gartner have suggested in 2020 there will be some 5.8 billion devices connected to the Internet. Our small team has already connected thousands of things to this Internet of Things.

IoT Systems Design are able to assist with bringing your ideas to life. Get in touch using our contact page here.

IoT Systems Design Pty Ltd is born We're going to help get the things in the world connected

About IoT Systems Design

IoT Systems Design

Today we set up IoT Systems Design Pty Ltd, a company focused on helping customers get the most out of the Internet of Things or IoT. The Internet of Things has been around for a while with the last few years becoming a buzz word.

What is the Internet of Things?

It’s devices like washing machines, fridges, microwaves, cars, trucks, trains, weather sensors, and a whole lot more all connecting to the internet to transmit data and receive data to make decisions. It could be an irrigation system that has sensors to know temperature, humidity, soil moisture level and using servers on the internet control irrigation systems to provide just the right amount of water and other nutrients.

With a team of different skilled specialists, we can help with the design and implementation of almost any automated Internet of Things solution for your business.

IoT Systems Design founder has a long and strong history with technology spending many years as a senior engineer with companies like Electronic Data Systems (EDS), Hewlett Packard (HP) and others. This strong grounding in well disiplined corportate practice along with an inovative approach he leads his company with a very strong focus on his clients success.

Get in touch

Get in touch for a free 4 hour initial analysis to see what possibilities exist
No Obligation