[address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)

Dne 23.10.2016 v 10:06 Tore Anderson napsal(a):
> Hi Kai,
> 
> * Kai 'wusel' Siering
> 
>> > (Which, btw, means there's no difference between PA and PI here.
>> > Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent
>> > interpretation. Eeks.)
>> > 
>> > [...]
>>> > > And 3rd party usage of IPv6 PI addresses is currently not allowed.  
>> > 
>> > Well, if reading the policy that way, neither is it for non-PI space?
> I think you're right. An assignment is an assignment.
> 
> If the policy currently disallows using assignments (PI or PA) for
> things like wireless networks for guests, then I'd say that 2016-04
> doesn't go far enough.

+1

My opinion is that 2016-04 goes completely wrong way because it makes
the exception "longer than /64 is not an assignment" valid only for PI,
not for PA addresses.

So if we agree that any device getting an address is getting an
assignment, which has to be registered properly in the database, this
problem is same for PI and PA addresses.

The only legitimate solution that is available exclusively for PA
holders is the special status AGGREGATED-BY-LIR with an assignment size
of 128. But I guess this is not the intention of this special status.
I've searched through the RIPE DB and found just 31 such assignments.
This is certainly not on par with how many Wi-Fi networks used by third
parties are out there.

And this is not only about Wi-Fi networks. All the VPS providers I know
have just one block assigned to themselves from which they delegate one
or more IP address per customer-controlled VPS.

I think it would be better to clarify the 2.6 section of ripe-655 to
explicitly state what is not an assignment. Using a prefix length of
"longer than /64" seem to be a good criteria, although it makes me
little bit scared of possibly wrong interpretation by some non-LIR ISPs
who would start delegating very long prefixes to avoid the need of
becoming LIR.

Cheers,
Ondřej Caletka
CESNET

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5600 bytes
Desc: Elektronicky podpis S/MIME
URL: </ripe/mail/archives/address-policy-wg/attachments/20161116/fbcce8da/attachment.p7s>