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(a)fiebig.nl
