January 2022 - address-policy-wg

ripe-587, Temporary Internet Number Assignment Policies
by Randy Bush 07 Mar '22

07 Mar '22

ok, i did it again, tried to fit a square peg in a round hole. while the immediate problem is past, thanks to the ncc reg folk, i fear that we could benefit from thinking a bit more about $subject. for a research experiment, we wanted eight or a dozen routable, i.e. /24, prefixes which we would announce from various places in the topology. each /24 would have one pingable address, let's assume .42. because this is ops based research, we have to o go through the ncc bureaucrazy o actually deploy and test o run the measurements for a few months o do the analysis o possibly tune or vary the experiment o write the paper and submit it o wait three months for the accept/reject o if rejected, retune and submit to a different venue o the reviewers may ask for us to re-run to get fresh data for publication o whine whine this takes six to twelve months. if you are familiar with $subject, you will sense there are two problems here. 587 is designed for a much shorter time window, and it kind of assumes more that 1:256 utilisation. you can imagine that my request to registration services generated a bit of discussion :). as our social environment has become less tolerant, reg services understandably wants simple rules they can follow and which clearly justify their actions. and geeks such as i just want our mtv :). i suspect we may be able to wordsmith conditions to deal with the time length issue. but i suspect that codification of guidelines covering the needs & justifications for research experiments, folk qualifying strange devices, and those doing other weird things will not be so easy. i am considering a policy proposal in this space; but want to learn what others see and think, and to see if it is worth the time and effort. and can we please keep discussion focused on temporary address space assignments? thanks. randy

13 27

IPv6 - Geolocation concerns
by Michalak, Damian 01 Feb '22

01 Feb '22

Hi there, This is a follow-up question to the older thread ("IPv6 - Using RIPE acquired prefix in other regions") Situation: I have acquired /32 IPv6 prefix from RIPE NCC. Prefix is registered for country: DE. I'm going to create /48 subnets and advertise them from various locations all around the globe. Question: Do I have to be concerned about geo-location issues? For example someone in US opening Google and getting Google.de? If so - what's the best way to address this? P.S. That's certainly a concern in IPv4 - I do advertise in US a subnet of a bigger supernet (registered in Poland) and Apple.com thinks I'm in Poland. Thanks

4 4

IPv6 - Using RIPE acquired prefix in other regions
by Michalak, Damian 27 Jan '22

27 Jan '22

Hi there, I'm quite confused and would appreciate your help - let's say I acquired /32 IPv6 prefix from RIPE NCC. I work for a company with a global footprint with locations at various regions (including ones covered by APNIC and ARIN). I create a subnet plan that assigns /48 to each location with the company. So each /48 falls into the /32 assigned by RIPE. Now let's take as an example a location in the USA. I have this location connected using Direct Internet Access link from one of the providers. BGP is established. Question: can I advertise the /48 subnet (that falls into the /32 assigned by RIPE) from the location that in theory falls into ARIN regulatory domain? I cannot find an answer on that anywhere, and I'd like to make sure that I don't have to acquire additional prefixes from other RIRs. Thanks

2 2

RIPE 83 Minutes
by Leo Vegoda 06 Jan '22

06 Jan '22

Dear WG, The RIPE NCC has now published draft minutes of our session at RIPE 83. The page also links to recorded content and supporting materials. Please write to this list or inform the co-chairs of any issues or corrections. https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-83-addre… Kind regards, Leo Vegoda for the Address Policy WG co-chairs

1 0

ripe-682 Transfer Policy Problems
by denis walker 05 Jan '22

05 Jan '22

Colleagues The Transfer Policy ripe-682 is so vague you can drive a train through the holes in it. I have some questions that I hope someone can answer before Christmas as I would like to propose an amendment to this policy in the new year. "Any legitimate resource holder is allowed to transfer" What does 'legitimate' mean in this context? It is not defined in this policy document. It is no use referring to a dictionary or even some other policy document. It needs to be defined in this policy. If it has no specific meaning in the context of this policy, then the word should be removed. My understanding of a 'policy document' is that it is self contained and consistent. None of the terms: -RIPE NCC Member -LIR -Resource holder are defined anywhere in the Transfer Policy or ripe-733, IPv4 Allocation... A policy may be dependent on another policy being in place. You cannot transfer a resource unless it has been allocated. You cannot allocate a resource unless there is a RIPE NCC Member and an LIR. But you should not have to backtrack through a whole sequence of documents to find out what a term in this policy means. This policy can only work if people understand 'commonly accepted' definitions of these terms. But that is open to interpretation and mis-understanding. That could make legal enforcement of, for example, restrictions more difficult to apply. [As a side issue I have just quickly read through a whole series of documents and forms on becoming a RIPE NCC Member and getting resources. In every document/form I found: -Legal errors -English grammar errors -Procedural errors -Webpage errors The whole process is a complete mess and needs a serious Legal/Comms review.] I found the definition of a Member in one document but nowhere have I found any definition of LIR. These terms are so fundamental to all these policies, to not define them leaves a massive hole in their meaning and authority. These terms seem to be so interchangeable from one paragraph to the next. In some places the wrong term is used. ripe-733 says allocations are made to LIRs ripe-682 says allocations are transferred to members ripe-682 says transfer restrictions apply to resource holders Then we have this document https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tra… which talks about 'hodership', another term not defined. Then we have this document https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tra… that conflicts with the Transfer Policy. It also refers to Members as organisations, again without any actual definition. The above document says: "Exception: For transfers between multiple LIR accounts belonging to the same organisation, also referred to as consolidations, the 24 months restriction will only apply once after the resources were received from the RIPE NCC or from another organisation." This is NOT what the Transfer Policy says. The policy makes no mention anywhere of consolidation. The only definition we have of a transfer in any POLICY is this one line: "Allocated resources may only be transferred to another RIPE NCC member." This does not even make sense. A Member cannot 'hold' a resource. Resources are held by Member LIRs. So if a resource is transferred to a Member with 5 LIRs, which one receives it? Does it matter? Is it whichever LIR the Member writes on the transfer request form? Now a consolidation is not a transfer. In the policy a transfer is defined as moving a resource to 'another Member'. So consolidating a resource by moving it from one LIR to another LIR of the same Member is by policy definition, not a transfer. So consolidation is not subject to Transfer Restrictions because it is not a transfer. So all the shell companies that have been set up this year to hoover up the last /24s can now be merged with their parent company and then all the /24s can be consolidated into one LIR. The other LIRs can then be closed. Nothing in this policy document says a /24 allocation must remain for 24 months with the LIR that it was allocated to. It says it cannot be transferred, but mergers are allowed and consolidation is not a transfer. This is even confirmed in a procedural document ripe-758, Transfer of Internet Number Resources... (which doesn't appear to be policy) "Internet number resources that are subject to transfer restrictions imposed by the RIPE Policy "RIPE Resource Transfer Policies", and that are transferred due to a change in a member's business structure, must either remain registered with the original LIR account or be registered with a new LIR account." So merging a shell company with 20 LIRs, each with a /24, with the parent company with a single LIR, allows those 20 /24s to be registered with the single LIR of the parent company and closure of the 20 LIRs. Also ripe-758 introduces yet another term, parties, without any definition or clarity. This whole transfer process is totally confused with contradictory, inconsistent and poorly written documents and policies. cheers denis co-chair DB-WG

4 5