[address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8)

On 19/09/2014 10:31, Martin Pels wrote:
> You are correct in that having received a small IPv6 PA assigment from another
> LIR may not be enough for deploying IPv6 to end-customers. But I could argue
> that having this PA assignment actually deployed in your network is more
> meaningful than having requested your own PA allocation without doing anything
> with it (which would satisfy the policy as it is now).

There is nothing in the proposal about deployment of either PI or PA space,
so it's not clear why you're making this argument.

The proposal as it stands is window dressing because it requires only
tickbox-style compliance.  This is completely pointless.  Organisations
will either deploy ipv6 or they won't, and this decision will be made on
business merit rather than because a RIPE NCC IPRA delayed a /22 allocation
because of a policy violation.

>From a syntax point of view, the wording is contradictory.  The summary
states that there is a requirement for an "inet6num object registered in
the RIPE Database or any of the other RIR databases mirrored by the RIPE
NCC".  The policy itself does not state this; just that the /22 allocation
can be made if the LIR has "already received a valid globally routeable
unicast IPv6 address block".  These two things are not the same.  If you
intend something to be in the policy, then put it into the policy.  The
policy is what ends up in RIPE-* documents; the summary is not a part of this.

>From an implementation point of view, it may be worth asking the RIPE NCC
if they intend to demand that the assignee of the inet6num is an exact text
match of the legal name of the LIR.  Most organisations are pretty sloppy
about this, and this is a likely source of future confusion because getting
PA or other RIR assignment/allocation details changed in order to qualify
for the /22 could turn out to be surprisingly troublesome.

FWIW, the RIPE NCC has done the community a favour by implicitly pointing
this out: "Delay and extra workload is only expected if the provided IPv6
range is not clearly registered to the requesting RIPE NCC member."  In
other words, be careful what you ask for because you might get it.

Also, the RIPE NCC has clarified that IPv6 assignments to different
companies within the same company group do not qualify for this proposal.
>From what I understand, this was one of the original complaints about the
existing policy, and it will not be fixed with this proposal.

overall:

- I don't support this policy because window dressing is not a good basis
for making ip addressing policy.

- even if I did support it, a) the policy doesn't say what you think it
says and b) it doesn't handle some of the problems of the current policy.

I would kindly suggest either dropping the ipv6 requirement completely from
the last /8 policy, or if you feel strongly that it should stay, rewording
this proposal to make it say what you intend.

Nick