Dear Working Group, I announced too many weeks ago that a small group was looking into the IPv6 policy, as it is today, why it is what it is, and whether the underlying assumptions that the policy is based on are still valid.
After taking way too long (apologies - lots of good excuses, but
this really shouldn't have dragged so long), I present you document
with a very personal view on the IPv6 address policy, coming from me,
Kurt Kayser and Sander Steffan (.txt and .pdf).
This is not a task force document, this is not a formal WG document,
and this is not an official RIPE document (though it might make a labs
article). It is intended as a personal look at 24-odd years of IPv6
policy... and to spur discussion and further work on some areas
that feel "in the rough".
We'll present about this next week, picking some points as starting
points for "shall we do something here? if yes, what? and who?" -
but this is not about *me*, but about the commounity - *you*. Anyone
is free and welcome to start a discussion and work on aspects we brought
up - or on other aspects.
Gert Doering
-- long-time IPv6 policy geek
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Preamble At RIPE83, the new APWG chairs suggested an overhaul of the IPv6 address policy - both policy text and policy itself, if needed. Some WG members volunteered to look into the part âwhy is the current policy the way it is? Are the fundamental motivations still valid?â... and this is a starting document for further discussions in the WG. This document is not a formal WG document, nor a product of a formal task force, but a personal view of the authors. Authors Gert Döring, Kurt Kayser, Sander Steffann Scope We have focussed exclusively on IPv6 policy. This does not mean that policies about other resources, such as ASNs, wonât benefit from a closer look. But that is out of scope for this document. Underlying assumptions and motivations The following underlying assumptions, goals and drivers went into the IPv6 policy, as it is now - not commenting on the merits of either point here. Discussion follows, grouped in a somewhat topical way, in the next sessions. * It should be easy to get IPv6 address space. * RIPE IPv6 address policy should encourage IPv6 rollout, not get in the way. * Aggregation is very important, both inside an ISP network and for the global routing system * Conservation of IPv6 address space is a desirable criteria, but at the same time it is acknowledged that the IPv6 address space is very large, so allocation and assignments can be more liberal (âwastiveâ) than for IPv4 * Implementation of allocation and assignment policies should be easy, and require less paperwork and bureaucracy than for IPv4 * Use of N:1 NAT (ISPs assigning single IPv6 addresses to customers) is seen as undesirable * âSpecial Networksâ exist that need stable IPv6 addresses which must not be tied to any particular uplink provider - namely, Anycast root DNS servers and IXP exchange fabrics (some need to be seen in the global routing system, others just need to be unique) * âRenumbering networks is hardâ * âMultihoming needs to be done with BGPâ (due to lack of widely accepted IETF alternatives) * IETF failed to deliver on ânewâ multihoming solutions, so a certain - limited - number of companies exist that need address space not tied to a specific upstream provider, but can be announced over multiple providers or taken from upstream A to upstream B when changing contracts. Evaluation Looking into each of these - partially conflicting - goals and assumptions in more detail: âSimplicity, encouragement, aggregation, discourage N:1 NATâ The end result of forming policy for these goals is: * ISPs can give end users a whole network block, up to a /48 per end site, without needing justifications (generally a /56 is recommended for SoHo end users, which is still 256 subnets of IETF-recommended size /64) - and most ISPs that provide IPv6 connectivity to end users seem to assign a /56, so the policy works. * Unlike IPv4, end customers are not encouraged to use NAT to work around address shortage, and also do not need to come back regularly because they need more addresses due to network growth. * RIPE LIRs can get a /29 address block from the RIPE NCC without needing any justification, so receive sufficient address space for 0.5 Million /48 assignments, or about 134 Million /56 assignments. Less, if internal aggregation is needed, but still sufficient for all but the largest service providers. * Most RIPE LIRs will not come back to the RIPE NCC to ask for more address space for a long time - or not at all. * If a RIPE LIR needs more than a /29, the need for internal network aggregation is taken into account when judging allocation size based on number of /56s needed (numerically, the algorithm used is âHD ratioâ) Most general assumptions leading there are still valid and the existing IPv6 policy seems to reasonably balance these needs. Especially the âeasy to operate, little bureaucracy, encourage IPv6 usageâ part is still important. Items under discussion: * 2.7 Utilization & 2.8 HD-Ratio are seen as âtoo complicatedâ * the wording (âbits to the left of the efficiency measurement unitâ) could be less scientific, and easier to understand * it does take into account that âlarger networks with multiple levels of aggregationsâ can not be as efficient as âsmaller networksâ, so there is a mathematical justification for doing so, and not just asking for â10% utilizationâ - but are we overdoing it, for the common cases? * 5.1.2 for âallocations larger than a /29â, and 5.2.1 âsubsequent allocation criteriaâ - it is (sometimes) very hard to bring the necessary documentation * especially the bump âno documentation for /29â to âfull documentation for /28â is steep(!). * Some cases are easy, like âtraditional ISP networksâ, where a LIR can just count customers, POPs, etc., and document their network aggregation hierarchy. * For other large networks, more situated in the enterprise or government arena, it is considered a huge effort to prepare this detailed level of documentation. * increasing the general allocation size (âa /24 for everybodyâ) would not solve the problem for very large networks, and needlessly use more address space for âsmaller LIRsâ * 5.7 âExisting IPv6 address holdersâ is seen as contradicting 5.2.1 - does a LIR need to bring documentation for an extension of its address allocation, or not? (Clarification in 5.7 that this refers to LIRs having been allocated a smaller-than-usual network, i.e. a /32 or /35, should help reducing the confusion) * 4.2 Routability is not guaranteed, but there is little guidance on routing aggregation in the address policy (currently 3.4: âshould be distributed in a hierarchical mannerâ) - this is a situation outside the direct responsibility of address policy, but if we could give advice here, or point to a BCOP document, this would be helpful for newcomers that are looking for guidance on commonly accepted levels of deaggregation, vs. what could be called ânetwork vandalismâ. * Unbounded deaggregation of LIR PA blocks (/29s) into âmore specifics announced by other entitiesâ might create lots of demand for AS numbers as well. * 4.4 âConsideration of IPv4 Infrastructureâ - is this still a relevant criteria? Does it create an unfair situation for âold networks that have lots of IPv4â vs. ânew networks that have great plans, but no v4 to back their numbersâ? Is it just moot and should go? âSpecial Networksâ The needs of IXP fabrics (unique, not tied to any particular ISP, possibly not even routed) and anycast root DNS servers (unique, tied to root DNS instance and not to any particular operator) have not changed. With the general availability of IPv6 PI address space, it is unclear whether these special-case blocks are still needed or whether âplainâ IPv6 PI could serve the needs. âRenumbering, Multihoming, Provider-Independenceâ For non-trivial networks, the whole aspects of ârenumbering on ISP changeâ and also âmultihoming to multiple different providersâ still does not have good solutions in IETF. Existing solutions are âuse BGP routing and multihomingâ - which has obvious scalability limitations in regards to the global routing table - or âuse IPv6 NAT/Prefix translationâ - which has implications on end-to-end address transparency. Solving these is outside the RIPE APWGâs scope. If we acknowledge that the requirements for âBGP based multihomingâ for a certain subset of networks exist, the consequences are âowners of such networks need to have portable address spaceâ. With the current address policy, LIRs can use a PA /29 for that (splitting up the /29 among multiple independent locations, if needed), while non-LIR end users can receive IPv6 PI space, with a /48 per end site, non-aggregatable. Some problems in this space are * routing table size (global impact) * yearly recurring costs for address space holders (IPv6 PI is cheaper than a full RIPE NCC membership) * discouraging IPv6 PI use conflicts with encouraging IPv6 deployment * aggregability of multiple IPv6 PI assignments to PI holders that have multiple independent end sites (e.g. 5 sites = 5x /48, not 1x /45) * IPv6 PI assignment to LIRs holding IPv6 PA is something the policy permits (7.2), but only by demonstrating a âunique routing requirementâ, the interpretation of which can create quite a bit of friction between LIRs and the NCC registration services. Transfer Policy and Stockpiling IPv6 address blocks can be transferred under the ânormalâ Transfer Policy (RIPE-682), just like IPv4 address blocks or AS numbers. This is not something intrinsic to IPv6 needs, but came out of the desire to have a unified Transfer Policy for all number resources managed by the RIPE NCC. That said, there are legitimate business cases for transfers of IPv6 blocks, like mergers and acquisitions, and having identical policies for all resource types makes this much easier for all parties involved. We have observed that some entities have acquired multiple /29s, in a few cases up to âover 50â /29s. This is not exactly the intended outcome, but we consider this as not critical yet (50 /29s are about a /22 worth of total space, of which there are many). The common assumption is that this is a side effect of certain actors opening multiple LIRs to collect multiple IPv4 /22 address blocks, and then merging the LIRs with their v4 and v6 space - so the amount of /29s involved should become somewhat bounded. Monitoring of future developments is still seen as necessary. Recommendations: items where revisiting policy might be worth considering (not calling this âConclusionsâ as we want the work to start here, not to end) * simplify language * simplify requirements for /28, /27, /26 ⦠allocations - explicit numbers, not HD ratio, and maybe start with âless drasticâ documentation requirements for âjust +1 bitâ? * change default allocation size? (4.3) * revisit âspecial caseâ assignments for IXP fabrics and root DNS operators (6.) <-> loosen up general IPv6 PI policy (for LIRs!) or keep special cases? * possibly fold IPv6 for IXP policy into main IPv6 policy document (https://www.ripe.net/publications/docs/ripe-451) * revisit IPv6 PI (7.x) * cost * aggregability * multihoming options * criteria for assignment * revisit aggregation requirements and expectations (BCOP)
IPv6 Address Policy Musings.pdf
Description: Adobe PDF document
signature.asc
Description: PGP signature
-- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
