tl;dr: 2016-04 adds ambiguity and uncertainty to the policy
text, is micro-managing the NCC against common intent
and paves the way to use cases, according to RIPE NCC's Impact
Analysis, the initial wording was trying to keep out.
Hi Sander,
[Jordi] I think we are in-sync, but your
response clearly demonstrates that there is a need for
clarifying the text.
-> Policy proposal “Providing another entity with separate
addresses (not prefixes)”
-> a /64 is a prefix
Technically, because the router is the PI holder's, you're not
delegating a /64. You're allowing a customer to do i.e. SLAAC on a
/64 of the PI holder.
and there we are again (besides, it's about (sub-) assigning, not
delegating, v6 addresses). 2016-04 started because of the RIPE NCC
started to take the view that “a single DHCP leaseon wifi
is a "subassignment" to another entity” [1], or, more
precisely [2]: “As an example, some Freifunk Communities in
Germany have been had their PI request declined because some
1-digit-number of subnets would have been used as IPv6 prefixes on
public WIFIs. This usage of the IP space in the End User’s
infrastructure has been interpreted as a sub-assignment of a /128
prefix. This would have been "assigned" to a user device of the
public WIFI network as the device would get an IP address via
SLAAC (or any other means for that matter). This
interpretation seems rather extreme and history shows that it's
not even shared by every member of the RIPE NCC.”
I've learned that …
when in doubt the RIPE NCC will check the
rationale behind a policy proposal to make decisions
… but if the RIPE NCC does read the rationale behind a policy
proposal, why is there a need adding more ambiguos text to an
already rather clear policy? Adding more text to the policy on what
is not supposed to be a sub-assignment than there is already
for the definition of what an assignment is is not really
helping things. The more specific the text, the more problems you'll
end up with, as can be seen in Monday's exchange already.
On the grounds of …
The NCC reads both. This has explicitly been
discussed before, and both the NCC and the working group confirmed
that we don't want policy text that is too specific because
reality is more complex than policy, and if we would try to make
the policy complexity match that of reality then we would end up
with horrible policy.
… 2016-04 heads in this (“horrible policy”) direction: “Providing another entity with separate
addresses (not prefixes) from a subnet used on a link operated by
the assignment holder is not considered a sub-assignment.” By
definition [3], any /128 is a prefix, thus “addresses (not
prefixes)” contradicts itself. Therefore, by trying to
clarify things, 2016-04 with the current wording just creates more
ambiguity and uncertainty.
(Next stop would be the question if a leased line is a "link
operated by" oneself or the company one ordered it from.)
"Please stop being a lawyer." Sorry, I didn't start this
nit-picking. To me, common sense – and the current
policy's definition of "assign" – clearly shows that having a
visitor's device pick an IPv6 address off my guest WiFi is not
a (sub-) assignment by words nor spirit of the current policy.
The community has agreed not to
micro-manage the NCC, and the NCC has promised to apply common
sense when implementing policy.
If so, why did we end up here? There is the RIPE NCC happily
violating their own rules continuously (most/all(?) RIPE Meetings
since roughly a decade), in – by their definition – sub-assigning
their PIv6 space — and at the same time denying this to others when
requesting new PIv6 space, “because of policy”.
I think Gert Döring was a too lazy on summarizing my concerns as "we
do not need this, the NCC is interpreting the policy all wrong";
there's something seriously wrong when a policy is implemented
randomly. Any policy, anywhere. Especially when the administrator
imposes random (that is: not covered by the policy) restrictions on
adress space request applications, which the administrator itself is
not adhering to for itself.
So, while this sounds like RIPE NCC bashing, that's not my intend;
but if the RIPE NCC just needs a statement that "WiFi is permitted
use for PIv6", why can't we agreed on this, here, and tell
the RIPE NCC?
There have been many cycles of micromanaging
the NCC to writing vague policy and letting the NCC sort out the
details. In both cases the NCC was blamed for everything.
But this is not the case here. Current policy,
https://www.ripe.net/publications/docs/ripe-684, is cristal
clear already:
2.6. Assign
To “assign” means to delegate address space to an ISP or End User
for specific use within the Internet infrastructure they operate.
Assignments must only be made for specific purposes documented by
specific organisations and are not to be sub-assigned to other
parties.
[…]
7. IPv6 Provider Independent (PI) Assignments
To qualify for IPv6 PI address space, an organisation must meet
the requirements of the policies described in the RIPE NCC
document entitled “Contractual Requirements for Provider
Independent Resources Holders in the RIPE NCC Service Region”.
[…]
The PI assignment cannot be further assigned to other
organisations.
The Wifi case (and that's all I care about, as that's the driver for
2016-04) is simply solved, since nothing is assigned or delegated
here anyway: RA announces a prefix, the devices pick some rather
random IPs. And this access point is part of the resource holder's
infrastructure, there are no "other parties" involved. An iOS or
Android device is no "Internet infrastructure [the End User]
operate[s]"; it's a client device, not infrastructure. Case over.
To me at least, that's "common sense". "A single DHCP lease on wifi
is a 'subassignment' to another entity" is not.
After many years of hard work we have
reached a balance where the working group and the NCC work
together to make policy that is one the one hand giving guidance
to the NCC about what the community wants, but also leaves some
room for the NCC (along with the accompanying responsibility) to
adapt to changes and to apply some common sense.
So, what went wrong there in the first place ([1], [2])? Why is the
RIPE NCC "suddenly" applying odd interpretations to new PIv6
applications, while at the same time not adhering to those
interpretations for their own use of their PIv6 space?
Other organisations in the internet
constellation have moved to a more legalese mindset, but I think
as the RIPE community we are proud that we have evolved enough
that we don't need that anymore and can actually work together
pleasantly without setting everything in stone.
I totally agree. So, why do we even consider 2016-04, which is
adding more legalese to a policy that, with common sense applied,
does not need any fixing?
(On the impact analysis, this might be more a PDP-related issue, but
anyway: why is there a »RIPE NCC's Understanding of the Proposed
Policy« but no »RIPE NCC's Understanding of the Current Policy«? And
on »it is the RIPE NCCs understanding that assignments as described
above are dynamic in nature, either by varying the prefix or
interface identifier (IID) over time«: Is 3 years still »dynamic«?
»Any permanent and static assignments of a prefix would still be
considered a sub-assignment as per clause 2.6, “Assign” of the IPv6
address allocation and assignment policy. Consequently the RIPE NCC
will not provide IPv6 PI assignments for such deployment plans.«
Well, the proposed clause 2.6 already forbids »providing another entity with […] prefixes
[…]«. Yes, wording is important on policy documents;
commentary isn't read by the applicant.)
And with legalese added comes new uses (see Impact Analysis): “If
this proposal is accepted, it is the RIPE NCC’s understanding that
for an IPv6 assignment, the provision of separate addresses to
customers of the assignment holder will not be considered a
sub-assignment. […] The RIPE NCC will consider […] in line with this
policy and not a sub-assignment as long as the subnet size does not
exceed a /64. […] Further it is possible that, despite the intention
of the proposer, broadband providers will request and receive IPv6
PI assignments as long they comply with the requirement to only
provide separate addresses to customers.”
Therefore, in order to fix an odd RIPE NCC interpretation regarding
WiFi-on-PIv6, much broader use cases for PIv6 will be opened by
2016-04.
“To use an extreme example, even a broadband provider with millions
of customers would qualify for an IPv6 PI assignment as long as he
would follow the policy requirements.”
Thus, in a nutshell, I'm still against 2016-04, as it addresses a
non-issue (with common-sense applied at least) and opens the box of
pandora without any need at all (see Impact Analysis on 2016-04).
Regards,
-kai
[1]
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-October/011838.html
[2]
https://www.ripe.net/participate/policies/proposals/2016-04/?version=1
[3] https://tools.ietf.org/html/rfc4291#section-2.3