Heho, I just had an interesting thread with the RIPE NCC when applying for an ASN and IPv6 /46 PI. Given the upcoming discussion on the 11th, some people suggested it might be interesting to describe the process on the list. Please excuse the length. I tried to be short, but there is a bit of context i believe should be included. With best regards, Tobias # Background ## About me For those who do not know me, I am Tobias, in my day-job I am a somewhat network measurement, somewhat security, somewhat humans researcher at the MPI-INF. In my spare time, i push a few packets around the Internet. I am currently speaking for myself/as de.wybt, and not my affiliation/MPI. ## Measurement.Network I am currently trying to build a 'measurement AS', i.e., an AS that is solely dedicated to network measurements, providing that service to academics, but also adding on some additional support. Specifically, the idea (briefly) is to: - Esp. support things going beyond SYN/Banner scanns; Did a lot of mail stuff in the past, for example, where it is easier to make mistakes. - Have a well-known AS/v4+v6 prefix dedicated to the network to make blocking easier, esp. as some researchers use public cloud infra for measurements, which are hard to block (as real services may be on those addr a week later) - Keep blocking collateral away from university/researchers' own institutions' networks - Do probe attribution, abuse handling, and opt-out correctly - Provide support/review of tools, going beyond 'academic ethics review' (there were some cases were people released harmfull tools due to their limited experience with the protocols they measured; and new PhDs students usually don't have 20 years of industry experience ;-)) - Make such infra more accessible; Some university IT departments can be a little anxious when you want to do active measurements My current plan is to get this built and running, and then see if some parts of the community would be willing to adopt it (and its  governance); Usually easier to ask for support when you have something working to show for. ;-) The idea is to have at least two PoPs with dedicated routing policies to also move DNS and mail 100% into the AS (block one thing, see no packets of any kind). Additionally, a further /23 allows for anycast experiments or tests using more/less specifics, without interfering with the infrastructure/static measurement networks. For the purpose of setting this up, MPI borrowed me a /22 v4. This left me with needing an ASN and an IPv6 prefix, the latter ideally being at least a /46 to be able to exactly mirror whatever policy might be on the /22. # Requests to the NCC Based on the above, I requested a 32bit ASN and a /46 PI from the NCC. Assignment of the ASN commenced after some in-depth discussion on policy provisions and how they apply to legacy space; After fulfilling the requirement that LEGACY spaceh should have INETNUM for the same org as the ORG holding an ASN (independent of MNT-ROUTE), the ASN was issued, even though I could not find this requirement in the applicable policy documents. The discussion around a PI assignment was, however, less successful. ## Reasoning for PI (7.2): - This is an independent project from the main activities of the main ASN of the LIR and should ultimately be upstreamed independent of AS59645. For now, while setting up, upstream would be provided by AS59645 and AS41051. - The assignment should not overlap with the existing PA of the LIR to ensure that the PA is not affected by potential blocking activity - The project, when established, would qualify for interconnection the main networks of the LIR do not necessarily qualify for, i.e., again necessitate a different routing policy. ## Reasoning for a /46 - The nature of the project needs it to be able to mirror any routing policy set for the v4 /22 to be able to leverage this network for measurements to its full extend based on requested experiments, ranging from experiments using more/less specifics or anycast experiments. (routing needs) - There are at least two PoPs which are to be hosting services necessitating distinct routing policies (DNS prim/sec, mail prim/sec), even though there is L2 transport for iBGP between the PoPs. Even though upstreams overlap between the PoPs, upstreams also have diverging routing policies for both PoPs. (routing need) ## Additional reasoning in line with general goals (3.) - To prevent renumbering and overhead if the project would reach a state that allows it to enter community governance, resources should be independent of the LIR, i.e., transferable (3.7). - As the routing policy of the /22 v4 should be mirrored, more than a /46 is not necessary (3.5), a /46 allows for aggregation (3.4) under changing policy, i.e., when no experiments are running that require all four sub-networks in different policies, and an aggregatable prefix is needed to be able to run experiments with overlapping prefixes, e.g., investigate how well more specifics are honored given some anecdotes that they might not _always_ win). # Discussion with the NCC ## First exchange In the first reply, the NCC requested a full documentation of the intended modus operandi of measurement.network, likely aiming at identifying whether use of addresses would technically constitute sub-allocations to researchers, barring the use of PI. Additionally, the NCC noted that additional reasoning for PI has to be provided given existing PA. The NCC noted, after just having had initially denied the request for an ASN to announce the v4 /22, that the /22 or any more specifics are not in the DFZ, and hence requested documentation of AS59645's current routing policy and how it would differ for the requested PI. ### Reply In reply, I provided a full documentation of the proposed goals and modus operandi as well as the intended governance structure of measurement.network. Furthermore, I detailed the reasoning following 7.2 as outlined above. ## Second exchange After informing me of needing some time to deliberate, the NCC came back and requested information on what 'network measurements' are, which subnet sizes would be used for measurements, and the legal status of any potential 'review board' of the project prior to it moving to not-only-me-is-responsible-governance, likely to ascertain whether there should be another entity listed as an ORG. Additionally, the NCC mentioned that more specific INET(6)NUM objects cannot be created for PI (see also my recent post on the db-wg ML). Instead, the NCC suggested i could do this with an allocation. ### Reply In reply, i defined network measurements and provided examples via my recent publications, clarified that, for now, i would be solely responsible in a legal sense, explained subnet sizes planned to be used, detailed various experiments needing unique routing policies stretching over a /46, and documented why technically, more specific INET6NUM are covered by policy as long as they use the same ORG object, but simply are not supported by the DB. Additionally, i asked whether their reference to PA suggested that they propose to apply RIPE-738 5.2.1. b), i.e., the justification of a new allocation due to new needs arising from this project, specifically, as per RIPE-738 5.1.2, the segmentation of infrastructure for security reasons, more specifically, the blocking and security implications of measurement infrastructure. Even though i noted that I'd be happy to receive an additional non-adjacent allocation to my existing PA, I also noted that a /46 PI would satisfy the unique routing requirementes we seemed to have converged on at this point, as it aligns closer to 3.5 of the policy (address space conservation). ## Third exchange A day later, the NCC came back, first addressing my question regarding their suggestion around PA by referencing the general page on assessment criteria for IPv6 allocations, and noting that a /29 holds 524 thousand /48. The NCC also agreed on my point concerning more specific INET(6)NUM objects, but noted that this is not supported by the DB. Next, the NCC came back to highlighting unique routing requirements, noting that announcements would take place in the same physical locations as AS59645 is present in, and hence again questioned unique routing requirements. Furthermore, the NCC noted that i mentioned that both sites are connected via L2, making Duesseldorf and Berlin essentially one end-site. This means that they could only issue one /48 unless i can demonstrate unique routing requirements for each site; The NCC also states that "The minimum size of the assignment is a /48.", which is interpreted as to mean that '[f]ollowing the policy, [the NCC] can only issue larger assignments to sites where there is a need to use more than 65536 of /64 subnets. However, multiple /48 assignments can be issued to multiple distinct sites.' Hence, as even when qualifying for more than one /48, i would receive multiple non-contiguous prefixes, the NCC concludes, that this means that 'it [is] impossible to achieve traffic advertisement using more and less specific prefixes (as [the NCC] understand[s] you need to use for the measurements) while using IPv6 PI space' ### Reply In reply, i first referred back to the second message in the ticket, where i detailed the different upstream and pering interconnections the project would qualify for, despite the announcements happening from the same physical locations, i.e., measurement.networking being topologically different. Next, i first state that 'minimum size of the assignment' prevents a /49, but not--as implied--a /47. Next, i challenge the point that addressing needs (number of devices to address) is the only justification for less specific assignments, referring to 5.4.2 of the policy, which clearly stats that exceeding the size of a single /48, either via multiple /48 or a shorter prefix, requires that it: a) must be based on address usage OR b) because different routing requirements exist Subsequently, i also note that the policy does not distinguish between assigning more than a single /48 to an end-site and assigning a less specific prefix, as it reads "Assignments larger than a /48 [shorter prefix] or additional assignments exceeding a total of a /48..." Before concluding, i again reference the NCCs statement that PI could not meet my routing requirements, asking whether their statements means that they acknowledge that my unique routing requirements could be satisfied by assigning a /46, but not by assigning a /48. I conclude the reply by summarizing my core points: - I read the NCCs statements regarding impossibility of fulfillign my routing requirements as acknowledging the existence of unique routing requirements. - The NCC proposes multiple /48 instead of a /46, claiming the former to be in-policy and the latter not, while the policy does not distinguish the two cases (or connected). - Noting that given 3.8 and thereon 3.4 of the policy, a single /46 will be more compliant than multiple /48, thereby making multiple /48 essentially incompliant. Finally, i note that i find it challenging to see how the NCC applies policy, especially given they cite policy incomplete and make proposals essentially less compliant than the (in my opinion in-policy) initial request. Hence, I ask whether they could point to where the policy supports their interpretation, or if they believe the case to be so unclear that it should be discussed with the wg. ## Fourth exchange Three days later, the NCC came back, claiming that 5.4.2 of the policy only "covers cases when [a] single End-site need[s] a larger prefix due to "address usage" which in this case is measured in terms of subnets. Subnet size in IPv6 is fixed at /64." Furthermore, they reiterate that this only means multiple assignements can be requested and approved under the policy. The NCC also reiterates that, due to the L2 connection, only one /48 can be issued, and i only informed the NCC about one routing policy. The NCC also repeats that, even if there were multiple locations, only multiple /48 could be assigned, not referring to policy at all. ### Reply In reply, i highlgihted again that the NCC makes claims not covered by policy, specifically, there being a difference between multiple non-adjacent more specifics vs. a less specific of the same aggregate size (barring the aggregation principle outlined in 3.8, which should be the highest priority goal in all interpretations of the policy, according to the policy, essentially prioritizing a single less specific over multiple more specifics). I also reiterate that 5.4.2 does not require multiple locations for routing requirements to be in place. I conclude by reiterating that the NCC acknowledged my unique routing requirements use case, given it sees it as a routing setup not possible with a single /48; Note that--as the NCC considers DUS and BER to be one site--5.4.2 certainly applies, which also means that the same requirements hold for assigning multiple /48 instead of a shorter prefix (aggain, barring 3.8). I close with the question why the NCC--given it considers multiple /48 feasible--refuses to apply policy (unique routing requirements and a single prefix shorter than /48 to satisfy these). ## Resolution At this point, the process had been going for nearly two weeks. While typing up the last reply to the NCC around 4pm, I acquired a /32 IPv6 PA and had the offering party initiate a transfer. The next morning, I received a reply from the NCC telling me that they would come back to me regarding my prior reply to the PI request. When the transfer of the /32 was completed a few hours later, I informed the NCC that the issue had been resolved and I would no longer need a dedicated assignment. So far, the ticket has not been closed, but i expect this to happen shortly. # Relevant discussion points Given how the process went, I see some points relevant to the ongoing discussion. ## Interpretation of policy by the NCC I believe that my reading of the policy has been outlined sufficiently above. I see that one may disagree on matters of how policy may be read. What, however, concerns me a bit is that the NCC provided incomplete citations of the policy in multiple instances throughout the ticket, where the omitted parts no longer supported the position of the NCC. Furthermore, i find the very fundamental adherence to, even multiple, /48 assignements in place of a smaller prefix/larger assignment size odd given 3.4 and 3.7 of the policy, especially considering the statement in 3.8 of the policy that makes it very clear that "In IPv6 address policy, the goal of aggregation is considered to be the most important." ## 3.5-3.7 of RIPE-738 Given the standard reservation sizes for v6 PI, as well as the ultimate solution for the issue I encountered, I am not sure whether either multiple /48 or the path I now ultimately took to reduce overhead for me is ideal; However, obtaining a larger prefix than needed (due to the minimum size of PA, i.e., /32 instead of /46), and doing so in less than 24h, in contrast to a nearly two week (unsuccesful) request with the NCC feels odd. I am also not to sure whether 3.6 is sufficiently covered here. As it is indeed significantly easier for LIRs to obtain PA of at least /32, than it is for end-users to even obtain a /47. Looking at this cynicaly, one might argue that undertaking/building/contributing a project like the one I am building is hardly possible for end-users that are not LIRs, even though I'd also argue that projects like this are very much what PI is for. Being an LIR making this easier, at least to me, pretty much feels like an "other factor", as described in 3.6. -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl