Local registry rules: Why you don't own your IP

A Local Internet Registry assigns IPv4 and IPv6 networks to authorized organizations rather than owning the address space itself. This distinction drives the entire operational model for GARR-LIR: you get connectivity, but you do not get title. The rules are strict. Networks remain the property of the provider and must be returned if an organization changes providers. This conditional access model ensures that IP address distribution remains tightly coupled with active network participation and adherence to documented standards like RIPE-424.

Operationalizing these services requires more than simple allocation. The process demands detailed motivation for requests and strict compliance with DNS architecture, specifically the activation of reverse resolution on name servers following assignment. Institutions connecting to the GARR network receive support for both initial setup and ongoing maintenance, yet they bear the responsibility of proving their need for additional IPv6 allocations beyond the standard /48 network provided to medium to large infrastructures.

The Role of the Local Internet Registry in Global IP Governance

LIR Function as IP Address and ASN Allocation Intermediary

A Local Internet Registry functions as the assigned intermediary receiving blocks from Regional Internet Registries to assign IP addresses and Autonomous System Numbers to network service users. Unlike end-user assignments intended for internal infrastructure, LIRs primarily distribute address space to customers of the services they provide. This distinction defines the operational scope for most Internet Service Providers acting within the global hierarchy.

Entities receiving allocations must adhere to strict policies where static assignments of specific sizes require registration in RIR databases upon downstream request. Such compliance ensures global routing consistency while preventing fragmentation of the finite IPv4 pool. The technical architecture mandates that LIRs manage these resources rather than simply consuming them, creating a clear separation between provisioning entities and final users.

Speed often clashes with protocol here. Rapid deployment needs for expanding institutions frequently collide with the administrative burden of maintaining accurate registries. Operators must balance immediate connectivity demands against the rigorous documentation required by upstream registries. Assistance is available to help organizations navigate these complex allocation workflows to optimize their existing IPv4 resources effectively.

Consortium GARR-2 DNS Configuration and Domain Registration Workflows

Consortium GARR-2 mandates that entities registering a .it domain must operate at least two DNS servers, comprising a primary and a secondary unit. This strict redundancy requirement prevents single points of failure within the national naming infrastructure. Institutions connecting to the GARR network receive dedicated support for DNS configuration during both the initial service activation and ongoing maintenance phases. Operators must immediately notify the registry of any changes to their primary or secondary server addresses to maintain visible reverse resolution on the global Internet.

The workflow illustrates a tension between operational autonomy and strict compliance; while institutions manage their own zones, the networks remain the property of GARR and must be returned to GARR-LIR in case of a change of provider. Unlike general IP address assignments that focus on routing reachability, domain registration workflows demand synchronized database entries across multiple authoritative sources. This dual-layer verification ensures that resource ownership data remains accurate amid frequent infrastructure updates. Such procedural discipline protects the integrity of the local registry database against stale entries.

Validating Organization Data via Information Request and Modification Forms

GARR provides specific tools, including an Information Request Form and an Organization Data Modification Form, to enable corrections to registry data. Available forms include an Information Request Form and an Organization Data Modification Form. Network operators use these documents when contact details shift or when the legal entity holding the allocation changes.

Operators should direct completed forms to the LIR via email or call +06 4962 2000 for assistance. Accurate organizational data prevents routing leaks and ensures trust.

Mechanics of IPv4 and IPv6 Address Space Allocation

IPv6 /48 Allocation Standards for Medium to Large Infrastructures

Every authorized organization receives a dedicated IPv6 /48 network as the standard baseline for connectivity. This specific prefix length is considered sufficient for use in medium to large infrastructures. Unlike IPv4 allocations which are evaluated based on specific needs, the IPv6 model provides a standardized default block to ensure hierarchical efficiency. Technical guidelines specify that Local Internet Registries manage static assignments of /64 or larger prefixes for downstream recipients to maintain proper aggregation.

Executing IPv4 and IPv6 Requests via GARR-LIR Email Procedures

Initiating an IP address request requires sending the email in English to the GARR-LIR team with four specific data points. The message body must explicitly list the organization name, the type of network requested (IPv4 or IPv6), the technical motivation, and primary contact details. Operators should draft a thorough justification for the needed space, as detailed instructions for this narrative are found in document RIPE-424. The evaluation workflow follows a strict sequential logic to ensure registry accuracy:

1. GARR-LIR receives the submission and transmits the data for technical review.
2. If the outcome is positive, the team assigns the addresses and notifies the requester via email.
3. If the review is negative, staff contact the applicant to request further clarification.

Ownership Risks and Reversion Clauses in GARR Network Assignments

GARR retains strict legal title to all assigned blocks, requiring immediate return upon any provider transition. This reversion clause means institutions do not own their IPv4 or IPv6 resources but rather hold a conditional license tied to GARR connectivity. Operators planning infrastructure upgrades must distinguish between needing more space and changing upstream partners, as the latter triggers a mandatory network surrender. If a user deems an additional allocation necessary due to genuine growth, they must request it from GARR-LIR by specifying detailed technical reasons.

Operationalizing DNS Services and Reverse Resolution

Defining Primary and Secondary DNS Service Roles

Local Name Servers need reverse resolution activation the moment an IPv4 or IPv6 network assignment arrives. This primary server acts as the authoritative source for domain records, demanding precise configuration to keep global visibility intact. GARR supports this workflow by offering a secondary DNS service upon request, building a redundant layer that reliability depends on. The primary server holds the master zone file while the secondary server retrieves copies to answer queries if the primary becomes unreachable.

GARR-LIR functions as an intermediary that primarily assigns address space to users of its own network services, distinct from broader ISP roles Network Service Integration. Your DNS setup directly impacts how allocated resources function within the wider internet system because of this specific relationship. Registering a .it domain remains impossible without two functioning servers, halting service deployment entirely.

Updating GARR-LIR regarding changes to primary or secondary DNS entries prevents invisible reverse resolution, which breaks email deliverability and trust verification. Maintaining independent primary infrastructure offers control but demands strict synchronization with the backup secondary service. Neglecting this coordination creates a single point of failure that redundancy protocols aim to prevent.

Configuring GARR-LIR DNS Records and Reverse Resolution

Submit the specific hostname and IP address for both primary and secondary machines to GARR-LIR to initialize zone files. Registration of a .it domain strictly requires at least two distinct DNS servers to ensure redundancy, making this configuration step mandatory. Operators must maintain immediate communication regarding any infrastructure changes, as failing to update these records means reverse resolution will not be visible on the global Internet.

The technical mechanism relies on the primary server holding the master zone while the secondary provides necessary fault tolerance through zone transfers. Most institutions function as the primary type of organization that assigns address space to their own users, making local DNS accuracy vital for service continuity. External validation fails completely if the primary server becomes unreachable and the secondary is not correctly synchronized or reported.

Execute the update process effectively by following these operational steps:

• Identify the exact machine names serving as your primary and secondary Name Servers.
• Email the corresponding IPv4 or IPv6 addresses to the GARRLIR administration team.
• Verify that your secondary server successfully retrieves zone data from the primary source.
• Confirm global visibility using standard dig queries after GARR-LIR processes the change.
• Document the timestamp of submission for internal tracking purposes.

This approach ensures your network remains reachable while adhering to RIPE compliance standards. Administrative overhead increases because every IP change requires manual reporting to maintain synchronization. Neglecting this protocol breaks the chain of trust required for email delivery and service discovery.

Mitigating Resolution Failures via Immediate DNS Update Protocols

Sudden reverse resolution outages occur instantly when operators modify Name Server IPs without notifying GARR-LIR. The registry cannot publish updated delegation records until receiving immediate manual confirmation of your primary and secondary DNS endpoints, creating this visibility gap.

• Delayed reporting leaves IPv4blocks unreachable for inbound mail validation.
• Global resolvers continue querying obsolete IP addresses until the registry updates zone pointers.
• Service interruption persists regardless of local server correctness if upstream delegation remains stale.
• Mail servers reject incoming messages when reverse lookups return errors or time out.

Rapid local reconfiguration often clashes with the slower global propagation of trust anchors. This process relies on explicit operator intent to maintain continuity unlike automated systems that might detect drift.

Total dependency on human speed rather than protocol timers represents the hidden cost of this manual step. Institutions receiving support for configuration must prioritize this notification to prevent invisible network partitions. Global coordination of these unique identifiers ensures one functional Internet, yet relies on local diligence to remain effective.

Executing Domain Registration and Resource Requests

Implementation: GARR-LIR Email Request Protocols for IPv4 and IPv6

Submit the email in English to initiate your IPv4 or IPv6 resource acquisition. This mandatory workflow requires four specific data points: your organization name, the requested network type, a detailed motivation, and primary contacts. Unlike end-user allocations, these requests undergo strict evaluation to confirm justified need before assignment. Note that GARR retains ownership of all assigned networks, requiring their return upon any provider change.

1. Compose your message specifying whether you seek IPv4 scarcity-based blocks or standard IPv6 space.
2. Include a strong technical justification, as ISP/LIR distinctions often dictate policy adherence levels.
3. Await the confirmation email that signals the start of the GARR-LIR evaluation process.

Successful validation results in direct assignment notification, while incomplete submissions trigger a clarification loop. For .it domain registration, ensure you maintain at least two DNS servers to satisfy registry requirements. The structural difference between ISP and end-user requests means your motivation must align with specific operational realities rather than general curiosity. This email-first protocol ensures that every allocated address serves a verified production necessity within the community.

RIPE-424 Compliance Checklist for Network Motivation Details

Draft your motivation statement using specific technical metrics to satisfy RIPE-424 allocation policies. This approach prevents rejection during the GARR-LIR evaluation phase.

1. Quantify your current IPv4 utilization rate with exact percentages from your monitoring systems.
2. Define the subnetting plan for the requested block to demonstrate efficient aggregation.
3. Distinguish your entity status, as ISP or end user classifications trigger different documentation requirements.
4. Reference the official RIPE-424 guidelines to ensure your justification aligns with regional scarcity principles.

Registering a .it domain simultaneously requires proof of two operational DNS servers. The limitation here is strict: vague motivations force the LIR to request clarification, pausing your assignment indefinitely. Precise technical data accelerates this workflow notably.

Executing Additional IPv6 Allocations Beyond Standard /48 Assignments

Organizations requiring space beyond the standard /48 must submit a detailed justification to GARR-LIR. This procedure follows the same outline as IPv4 addresses, demanding precise technical motivation.

1. Compose an email in English specifying the organization and IPv6 network type.
2. Provide a strong explanation for the additional allocation need, as standard blocks serve medium infrastructures.
3. Include primary contact details for immediate follow-up during the evaluation phase.
4. Await the assignment notification or request for clarification from the registry team.

The evaluation ensures efficient address usage while maintaining RIPE NCC compliance. However, static assignments of /64 or larger trigger specific registration requirements if publication is requested downstream registration. Operators often overlook that failing to document this downstream need initially delays future database updates. InterLIR recommends preparing your subnetting plan before contact to simplify approval. Clear documentation accelerates the process notably.