Policy Active Proposals


Details
  • Ref. Name:AFPUB-2018-V6-002-DRAFT01
  • Submitted:14 March 2018
  • Versions: 1.0
  • Amends: CPM art 6.8
  • Obsoletes:
  • Author:
    - Jordi Palet Martinez, jordi.palet[at]theipv6company.com  The IPv6 Company

 

1.0 Summary of the Problem Being Addressed by this Policy Proposal

When the policy was drafted, the concept of assignments/sub-assignments did not consider a practice very common in IPv4 which is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs.

In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common.

Likewise, the policy failed to consider the use of IP addresses in hotspots, or the use of IP addresses by guests or employees in Bring Your Own Device (BYOD) and many other similar cases.

Finally, the IETF has recently approved the use of a unique /64 prefix per interface/host (RFC8273) instead of a unique address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are “isolated” from other users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on their devices with a unique address for each one (within the same /64).

 

2.0 Summary of how this proposal addresses the problem

Section 2.6 (General Definitions/Assignment), explicitly prohibits such assignments, stating that “Assignments... are not to be sub-assigned to other parties”.

This proposal clarifies this situation in this regard and better define the concept, particularly considering new uses of IPv6 (RFC 8273), by means of new text at the end of whatever text is available at the IPv6 PI assignments policy.

 

3. Proposal

New Paragraph at the end of 6.8 of the CPM, as follows:

Current Proposed

6.8 PI Assignments

(at the end of the section, precedent text unchanged by this proposal)

6.8 PI Assignments

(at the end of the section, precedent text unchanged by this proposal)

The fact that a unique address or even a unique /64 prefix is non-permanently provided to third parties, on a link operated by the original receiver of the assignment, shall not be considered a sub-assignment. This includes, for example, guests or employees (devices or servers), hotspots, and point-to-point links or VPNs. The provision of addressing for permanent connectivity or broadband services is still considered a sub-assignment. Only the addressing of the point-to-point link itself can be permanent and that addressing can't be used (neither directly or indirectly) for the actual communication.

 

4. Revision History

Date Details

20 March 2018

Version 1: AFPUB-2018-V6-002-DRAFT01

Initial Draft Posted to rpd

 

5. References

A similar proposal has been discussed in the RIPE region and is waiting for forum chairs to declare consensus.

 

The Problem Being Addressed by this Proposal

In the DNS, a lame delegation is a DNS misconfiguration error. If a given DNS nameserver is designated as an authoritative server for a domain name, but does not return authoritative data for that name when queried, this is considered a lame delegation.

This could be due to the nameserver not having authoritative data for the DNS zone, or simply not responding at all.

DNS misconfigurations such as this have an operational impact on the global DNS as they cause additional unnecessary queries compared to having no delegations at all. However, the end result to a DNS client is ultimately the same: No data is found.

Also see:

A large number of the reverse DNS delegations from the AFRINIC database are misconfigured in this way.

 

Ref. Name:
AFPUB-2017-DNS-001-DRAFT-02

Versions:2.0 

Status: Pending Board Ratification

Obsoletes: CPM 3.0 - The Policy Development (PDP)

Author:

  • D. Shaw [daniel at afrinic.net]
  • A. Phokeer [amreesh at afrinic.net]
  • N. Goburdhan [nishal at pch.net]
  • J. Engelbrecht [jaco at jacoengelbrecht.eu]
Submitted:
22 November 2017

 Revision History

Date

Details

22 Nov 2017

Version 2.0
Second Draft AFPUB-2017-DNS-001-DRAFT02

A complete rewrite of the text to simplify and clarify. Neither the intent, nor the actions and results of the proposal have changed.

The text is simply now confined to a brief problem statement and the desired end result.

  • Removed all text to do with background, terminology, explanations, impact of the problem, motivations and possible implementation details.
  • Trimmed down policy statement to make it simple and clear.

15 Mar 2017

Version 1.0
First Draft AFPUB-2017-DNS-001-DRAFT01

Page 7 of 19