[address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification)

Hi list & Ondřej,

I Share this feeling.

An end user to me is a user that permanently with or without a contract uses a certain (call it assigned or agreed) or logical block of addresses.

The wifi will probably not give out permanent addresses that can be claimed back the next time, so I see no point in the sub allocation either.

Rgds,

Ray

-----Original Message-----
From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Ondrej Caletka
Sent: 9. tammikuuta 2017 15:46
To: address-policy-wg at ripe.net
Subject: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification)

On 2.1.2017 v 13:59 Marco Schmidt wrote:
> 
> We encourage you to review this proposal and send your comments to <address-policy-wg at ripe.net> before 31 January 2017.

Hi list,

I would like to express my disagreement with the proposal. As I stated
before [1], I think this proposal goes completely wrong way. After
reading the impact analysis, I'm even more sure this is the case:

To quote impact analysis:
> Section 5.4.1 of the RIPE IPv6 policy mandates a /64 as the minimum
assignment size per End Site within IPv6 allocations, while this policy
change will make subnets smaller than a /64 per customer possible within
IPv6 PI assignments.

As I understand it, the proposer certainly don't want to lower the
minimum of /64 per *End Site*. He just want to be able to operate a
public Wi-Fi network within *his own End Site*.

Another quote of impact analysis:
> The current RIPE Database business rules prevent the creation of more
specific objects under an object with the status “ASSIGNED PI”,
therefore these small subnets used by customers of the requesting
organisation cannot be documented in the RIPE Database.

This is starting to get ridiculous. Even if the database allowed
creating sub-assignments under ASSIGNED PI, there is no technical way
how to register every single device pulling address via SLAAC/DHCPv6 to
the RIPE database, nor has been anything like that needed any time
before. The RIPE Database is not a pan-European DHCP pool, is it?

We really have to fix the RIPE NCC interpretations of "End Site" and
"Assignment" so they don't consider a laptop connected to Wi-Fi network
to be a separate End Site requiring it's own sub-assignment. This is the
part that is broken and needs to be fixed, not the PI assignment rules.

Best Regards,

Ondřej Caletka
CESNET

[1]:
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-November/011943.html