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

[Kai 'wusel' Siering]

Hi,

am 16.11.2016 um 15:29 schrieb Ondřej Caletka:
> 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.
>
> […]
> 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.

I don't agree on "any device getting an address is getting an assignment"
in the first place. Let's refer to ripe-655's definition:

> 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.

From my point of view, the sentence is really clear already, and shouln'tbe 
able to be interpreted in the way it currently seems to be ;)

An assignment is a bureaucratic act, executed by an organisation (IR) in favor 
of another organisation (non-IR). An assignment is considered to exist for a 
prolonged duration and as such to be documentedin the RIPE Database.

Nothing of that happens when mechanisms like SLAAC or DHCPv6 suggest, to a 
requesting device, which IPv6 Prefix is being used/which IPv6 address itshould 
use.

So, what “are not to be sub-assigned to other parties” (2.6) and 
especially“cannot be further assigned to other organisations” (7) are trying 
toprevent in the first place?

Sander gave the context:
> […]
> Then IPv4 NAT came along, and most residential ISPs started to not assign 
> addresses to customers at all anymore: they only got the interconnect and 
> were expected to NAT using the interconnect's address. That made it possible 
> for ISPs to run their ISP completely on PI addresses. The IPv6 policy then 
> closed the loophole for (IIRC) two reasons:
> - it was considered unfair that some ISPs used cheap PI addresses while 
> others paid for running the NCC (this included hosters using PI space as well 
> as access ISPs)
> - the fear that allowing interconnects on cheap PI space would encourage ISPs 
> to force their users to use NAT on IPv6
>
> This of course forced all ISPs to use PA space, but situations where the 
> "ISP" vs "End user" boundary wasn't the classical one had problems. This was 
> discussed on RIPE62 (https://ripe62.ripe.net/presentations/209-apwg.pdf 
> starting at slide 9, it took me a lot of effort trying to find that one, I 
> couldn't imagine it already being 5 years ago) and because of that an effort 
> was started to stop distributing different "colours" of address space and 
> unify PA and PI.
>
> Unfortunately that effort failed because it turned out to cause too many 
> complications (see 
> https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf),
>  which is why we are at the current policy and interpretation as presented 5 
> years ago:
>
> > - No DSL
> > - No Cable
> > - VPN
> > - No co-location
> > - No virtual servers
> > - No SSL hosting
> >
> > No buts and no exceptions
>
> And that's where we are today, and what this policy proposal is trying to 
> change.

If above reflects the (agreed on?) “current policy and interpretation”, as 
ripe-655 _is_ the document that specifies the “IPv6 Address Allocation and 
Assignment Policy”, it must be added there in a proper and consistent way in 
the first place.(Althoughnot being allowed to use IPv6 PI inhouse for virtual 
servers would be ridiculous at best: Green IT? Only over RIPE's dead body.)

I really think the whole of ripe-655 should be reworked, especially as the 
published policy and the ‘lived’ interpretation are totally out 

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

[Ondřej Caletka]

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



smime.p7s
Description: Elektronicky podpis S/MIME

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

[Maximilian Wilhelm]

Anno domini 2016 Leo Vegoda scripsit:

Hi Leo,

> > > So prefix delegation is OK as long as the prefix is longer than a /64?
> > 
> > Technically that's what the proposal is currently proposing. I'm curious 
> > about the opinions of working group members about that.

> Taking no position on the proposal itself, I'd like to draw people's
> attention to RFC 7421 (Analysis of the 64-bit Boundary in IPv6 Addressing).

Thanks for the pointer.

> Section 4.4 deals with Implementation and Deployment Issues and might be a
> helpful read when considering a proposal that might lead to significant
> pressure to deploy infrastructures designed to delegate prefixes longer than
> /64.

The proposal should not by any means induce preassure to delegate such
prefixes. By "delegate" I think of a "routed delegation", like a prefix
which on the last hop of the organisations infrastructure being an entry
in the FIB and not configured locally.

The whole idea of PI space is that it's not "delegateable" following the
above definition. The proposal doesn't want to change that. The goal
is to allow use of PI space in the organisations infrastructure and
allow the use of prefixies (a /64 for example) in networks open to
guest or the general public to stress this example.

Best
Max
-- 
They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety.  (Ben Franklin)

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

[Leo Vegoda]

HI Sander,

Sander Steffann wrote:

[...]

> > So prefix delegation is OK as long as the prefix is longer than a /64?
> 
> Technically that's what the proposal is currently proposing. I'm curious 
> about the opinions of working group members about that.

Taking no position on the proposal itself, I'd like to draw people's
attention to RFC 7421 (Analysis of the 64-bit Boundary in IPv6 Addressing).
Section 4.4 deals with Implementation and Deployment Issues and might be a
helpful read when considering a proposal that might lead to significant
pressure to deploy infrastructures designed to delegate prefixes longer than
/64.

Kind regards,

Leo Vegoda


smime.p7s
Description: S/MIME cryptographic signature

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

[Sander Steffann]

Hi Radu-Adrian, 

> ... and this is where technical implementation comes and messes things
> up
> If you are functioning in "subscriber management" mode, you equipment
> may impose you that each subscriber has its own subnet for
> interconnection (mine does) - obvious choice being a /64.

I think that that's perfectly in line with the current policy: if you have 
subscribers then you need to get PA addresses. The current policy proposal is 
not trying to change that. But using a /64 for an interconnect is not 
unreasonable in other circumstances such as VPN connections between two 
enterprises etc.

Cheers,
Sander

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

[Radu-Adrian FEURDEAN]

On Sat, Oct 22, 2016, at 23:30, Sander Steffann wrote:
> > (Actually, it would not be ok, as »/64 or shorter« still prohibts use of 
> > /64 for e. g. WiFi. The proposal therefore should read »/63 or shorter« or 
> > »shorter than /64«, I think, or SLAAC is not an option anymore.)
> 
> You are misunderstanding. We're not talking about what you configure on
> your Wi-Fi, we're talking about what you delegate to third parties: the
> users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user
> it's within the proposed policy.

... and this is where technical implementation comes and messes things
up
If you are functioning in "subscriber management" mode, you equipment
may impose you that each subscriber has its own subnet for
interconnection (mine does) - obvious choice being a /64.
But being in "subscriber management" mode may not be the case for
somebody offering wifi on a non-commercial basis, but if it still is,
you may always try to use "longer than /64"  (??? /128 ???) subnet per
device.

I haven't tried to see if "longer than /64" works with my equipment,
since for me it's a non problem (I do assignments from PAs).

--
Radu-Adrian FEURDEAN

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

[Erik Bais - A2B Internet]

This is also my interpertation... 

If you use DHCP of any kind on the network to randomly provide a number for a 
device to connect to the network on a temp lease, it isn't an assignment to the 
letter of the policy. That is also not how the intent of the policy was 
written. 

If you assign a number or subnet to a specific device and that is fixed in the 
configuration, so the next time you connect, you will get the same 
number/subnet, you can see that as an assignment. Especially if that is part of 
a contractual agreement / service / subscription.  Most users/devices are 
looking for a single digit number, not a subnet for their connectivity need. 

The difference between the two is in the duration and the expectation. 
Most roaming wifi users won't be asking for a complete subnet or prefix on 
their laptop or hosting services / third party apps on a wifi link ... 

Most wifi users just want to avoid telco charges while listening to spotify, 
skype or watch youtube/twitch/netflix while in a waiting room .. or do some 
whatsapp while in a wiating room of their healthcare provider.. these are not 
permanent roamers lurkers to avoid RIPE charges or trying to scam their infra 
behind some public provided wifi connection.  
If the specific wifi/network implementation required to use a /64 or smaller 
per connecting device/user, for security reasons for instance, it would still 
be the same if those prefixes would be selected dynamically. 

If the situation is as stated above, the usage should be perfectly within the 
current policy.  

Regards,
Erik Bais


> Op 23 okt. 2016 om 10:11 heeft JORDI PALET MARTINEZ 
> <jordi.pa...@consulintel.es> het volgende geschreven:
> 
> If I’ve a PI for my company … and I offer WiFi for the laptops or phones of 
> my employees, and their families and customers when they come to my office … 
> are those assignments? Clearly they are “others”, not the same organization 
> that got the PI.
> 
> That’s why I think we need to consider that assignment is for infrastructure, 
> not end devices, at least this seems to be my reading of the definition.
> 
> Saludos,
> Jordi
> 
> 
> -Mensaje original-
> De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Tore 
> Anderson <t...@fud.no>
> Responder a: <t...@fud.no>
> Fecha: domingo, 23 de octubre de 2016, 10:06
> Para: Kai 'wusel' Siering <wusel...@uu.org>
> CC: "address-policy-wg@ripe.net Working Group" <address-policy-wg@ripe.net>
> Asunto: Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI 
> Sub-assignment Clarification)
> 
>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.
> 
>Tore 
> 
> 
> 
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the use of the 
> individual(s) named above. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, including attached files, is prohibited.
> 
> 
> 
> 

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

[Leo Vegoda]

On 10/22/2016 02:30 PM, Sander Steffann wrote:

[...]


You are misunderstanding. We're not talking about what you configure on your 
Wi-Fi, we're talking about what you delegate to third parties: the users of the 
Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user it's within the 
proposed policy.


So prefix delegation is OK as long as the prefix is longer than a /64?

Regards,

Leo Vegoda

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

[Tore Anderson]

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.

Tore 

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

[Sander Steffann]

Hi Kai,

> So, since anything _above_ /64 (e. g. /65 to /128) would be whitewashed by 
> the proposal, using a whole /48 PA or PI for /64s for WiFis would be ok, as 
> long as each WiFi user only gets less than a /64 »assigned«?

That's what the proposal currently says. 

> Proposal states: »Today, organisation networks usually include some kind of 
> guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to 
> customers’ sites, or anything similar where devices of non-members of the 
> organisation would get assigned an IP out of the organisation’s prefix.«
> 
> These days I configure P2P links as /64 (with ::1 and ::2 being the 
> endpoints), because ... people actually tried to hit me with cluebats when I 
> carried over IPv4-behaviour of /32 or /31 links into IPv6 (/127). 

Actually, using a /127 for point to point links is pretty common. There is even 
an RFC about it (https://tools.ietf.org/html/rfc6164). I use it a lot, also I 
the training courses I give. I reserve the whole /64 in the numbering plan just 
in case, but on the link I usually configure ::a/127 and ::b/127. 

> So, even after this proposal, I am not allowed to use my IPv6 PA or PI space 
> to build P2P-links outside my organisation, e. g. for peering, with a netmask 
> of /64? But at least anything above /64 (read: /127) in PI would be ok, which 
> currently isn't, neither for PA nor PI?

Technically, yes. I still have to re-read the PA bit, because I'm not sure 
about that. I'll reply to that later.

Cheers,
Sander

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

[Sander Steffann]

Hi Leo,

> So prefix delegation is OK as long as the prefix is longer than a /64?

Technically that's what the proposal is currently proposing. I'm curious about 
the opinions of working group members about that.

Cheers,
Sander

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

[Kai 'wusel' Siering]

Hi there,

am 22.10.2016 um 16:28 schrieb Sander Steffann:
> This of course forced all ISPs to use PA space, but situations where the 
> "ISP" vs "End user" boundary wasn't the classical one had problems. This was 
> discussed on RIPE62 
> (https://ripe62.ripe.net/presentations/209-apwg.pdfstarting at slide 9, it 
> took me a lot of effort trying to find that one, I couldn't imagine it 
> already being 5 years ago) and because of that an effort was started to stop 
> distributing different "colours" of address space and unify PA and PI.
>
> Unfortunately that effort failed because it turned out to cause too many 
> complications (see 
> https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf),
>  which is why we are at the current policy and interpretation as presented 5 
> years ago:
>
>> - No DSL
>> - No Cable
>> - VPN
>> - No co-location
>> - No virtual servers
>> - No SSL hosting
>>
>> No buts and no exceptions
>
> And that's where we are today, and what this policy proposal is trying to 
> change.

Sander, thanks for the historical context.

It explains this statement from the proposal: »Today, organisation
networks usually include some kind of guest networks, (public) WIFI
hotspots in their offices, PTP-VPN links to customers’ sites, or
anything similar where devices of non-members of the organisation
would get assigned an IP out of the organisation’s prefix. Strictly
following the current RIPE policy regarding eligibility for IPv6 PI
space, organisations aren't allowed to be provided with PI space when
this is the case.«

But there's nothing about that in ripe-655:»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” [reference goes to ripe-637 as of this writing].«

Thus, there seems to be a policy, and an interpretation of that
policy, the later hidden in some slides?

Now I do agree that the policy needs fixing, as it neither refers nor
at least mentions these »interpretations«. By policy's text, if you
sign the Independent Assignment Request and Maintenance Agreement with
a sponsoring LIR, you are qualified to receive IPv6 PI space, no?

BUT: how would the simple addition of »[w]ithin the context of these
policies, a sub-assignment is an assignment of a length of /64 or
shorter« will solve the issue that mentioning WiFi in the PI request
leads to it's refusal? (Note that »no WiFi« is not even present on
above's list.)

If above's »interpretation« is still the current one, it misses WiFi,
so that should not have led to refusal of PI assigments. If not, where
is the current one and how does the APWG influence it – and how does
the general public, e. g. an End User looking for PI space to IPv6-
number his or her gear once-and-for-all, learn about it?

Regards,
-kai

-- 
Kai SieringSchalückstraße 107, 2 Gütersloh
eMail: kai.sier...@uu.org ISN: 98735*1796 × Phone: +49 172 8635608
--
"Getdate firmly  believes that years after 1999 do not exist;  getdate
 will have to be killed by the year 2000."
 -- From the "Bugs" section of cnews-020592/libc/getdate.3

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

[Sander Steffann]

Hi Erik,

> Going into that kind of thinking would be similar to not allowing external 
> voice calls to IPv6 PI assigned phones, because some third party should be 
> able to make use of it..
> 
> This discussion is different if we are actually (commercially) hosting 
> services on a (semi)permanent basis on the PI assigned space... like if a 
> third party is actually offering webservice hosting or voip services over 
> that WIFI ..

And there is where it gets complicated :)

A bit of history:

The IPv4 policy had the text "IP addresses used solely for the connection of an 
End User to a service provider (e.g. point-to-point links) are considered part 
of the service provider's infrastructure. These addresses do not have to be 
registered with the End User's contact details but can be registered as part of 
the service provider's internal infrastructure."

This "loophole" made it possible for IPv4 service providers to connect users to 
their network without making a separate assignment. Originally the idea was 
that the interconnect wasn't an assignment but the address space routed over 
that interconnect was. Cases where a single 3rd party server was connected were 
also not considered assignments because of this rule.

Then IPv4 NAT came along, and most residential ISPs started to not assign 
addresses to customers at all anymore: they only got the interconnect and were 
expected to NAT using the interconnect's address. That made it possible for 
ISPs to run their ISP completely on PI addresses. The IPv6 policy then closed 
the loophole for (IIRC) two reasons:
- it was considered unfair that some ISPs used cheap PI addresses while others 
paid for running the NCC (this included hosters using PI space as well as 
access ISPs)
- the fear that allowing interconnects on cheap PI space would encourage ISPs 
to force their users to use NAT on IPv6

This of course forced all ISPs to use PA space, but situations where the "ISP" 
vs "End user" boundary wasn't the classical one had problems. This was 
discussed on RIPE62 (https://ripe62.ripe.net/presentations/209-apwg.pdf 
starting at slide 9, it took me a lot of effort trying to find that one, I 
couldn't imagine it already being 5 years ago) and because of that an effort 
was started to stop distributing different "colours" of address space and unify 
PA and PI.

Unfortunately that effort failed because it turned out to cause too many 
complications (see 
https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf),
 which is why we are at the current policy and interpretation as presented 5 
years ago:

> - No DSL
> - No Cable
> - VPN
> - No co-location
> - No virtual servers
> - No SSL hosting
> 
> No buts and no exceptions

And that's where we are today, and what this policy proposal is trying to 
change.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[JORDI PALET MARTINEZ]

Fully agree.

Using addresses to provide temporary Internet connectivity to “visiting” users 
should not be considered as an assignment, and in fact looking into my notes, 
when I presented the IPv6 PI policy proposal, I’d this clearly pictured in my 
mind.

So I don’t think we need this change.

The Assignment definition mentions Internet infrastructure:

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.

In my opinion devices visiting a hot spot AREN’T Internet infrastructure.

So if there is a need for clarification, it is not just for the PI policy, but 
a more global scope in the section 2.6, o even a new section depicting what is 
“Internet infrastructure”. For example, the CPE of a customer it is 
infrastructure, but not the devices behind it.

Let’s put it in another way. If the hot spot allows a router to “connect” to 
the hot spot and get assigned a /64, then this router is allowing “other” 
devices to connect, so in this case it is network infrastructure.

Saludos,
Jordi


-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Erik 
Bais - A2B Internet <eb...@a2b-internet.com>
Responder a: <eb...@a2b-internet.com>
Fecha: sábado, 22 de octubre de 2016, 13:07
Para: William Waites <w...@hubs.net.uk>
CC: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI 
Sub-assignment Clarification)

Although I see the intent of the policy, the question that I have is : 

If a PI space holder is offering free wifi .. they are offering an access 
service for other to be used in their building or realm ... that qualifies as 
their infrastructure ... 

The users of the service, are not making any claims that they require a 
specific (set of) number assigned ... the user isn't moving into a contractual 
( subscription ) agreement for it .. 
if we are under the current policy disallowing people using the usage of 
wifi, it would be similar to disallowing people coffee from the network 
connected coffee machine..  or not allowing guests walking through a hall with 
CTV camera's with PI IPv6... especially if they can see what the camera's are 
capturing on a screen ... /b.;-) 

An assignment by policy, is setting aside a dedicated set of number(s) to 
be used by a party.  The current PI IPv6 policy does not allow further 
sub-assignments to third parties. And using the IP space isn't the same as 
getting an (sub-) assignment from that prefix.. 

Going into that kind of thinking would be similar to not allowing external 
voice calls to IPv6 PI assigned phones, because some third party should be able 
to make use of it.. 

This discussion is different if we are actually (commercially) hosting 
services on a (semi)permanent basis on the PI assigned space... like if a third 
party is actually offering webservice hosting or voip services over that WIFI 
.. 
But if the wifi is for regular public wifi access, to allow guests that 
roam in a public environment on an ad-hoc basis ... it falls perfectly under 
the current policy imho. 

That this might be open for interpertation, doesn't directly mean that the 
current policy is flawed.  I know from working with the NCC, that some of the 
IPRA's haven't been around since this particular policy was discussed and some 
might have different views .. 
So it is good that these particular corner cases are re-discussed from time 
to time imho..  

And I would also like to ask the NCC before we try to implement this into a 
change, how the NCC would see this and how the IPRA's are instructed currently 
on this, on how to evaluate this. ( before the formal IA further in the PDP ) 

Regards,
Erik Bais 


> Op 22 okt. 2016 om 11:17 heeft William Waites <w...@hubs.net.uk> het 
volgende geschreven:
> 
> 
>> A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment 
Clarification"
>> is now available for discussion.
> 
> I support this proposal as well. The current interpretation of the
> policy seems pathological to be honest. It could be supposed that given
> the Freifunk precedent, a local government (for example) would not be
> able to get a PI assignment because they provide complimentary Wifi in
> their lobby. I find it hard to believe that the original policy could
> have been intended to be read like this and indeed am a little surprised
> that the NCC has taken such an interpretation. So there is clearly a bug
> in the policy and this patch appears to fix it.
> 
> B

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

[Maximilian Wilhelm]

Anno domini 2016 Kai 'wusel' Siering scripsit:

Hi Kai,

> am 21.10.2016 um 10:32 schrieb David Croft:
> > Strong support in principle. We have been denied IPv6 temporary
> > assignments due to the NCC's interpretation that a single DHCP lease
> > on wifi is a "subassignment" to another entity, which was clearly not
> > the intention.

> I'm new to this, so please bear with my simple-mindedness here,
> but to me it looks like »the NCC's interpretation that a single
> DHCP lease on wifi is a "subassignment" to another entity« iswhat
> should be addressed, instead of special-caseing something intoan
> already complex policy document.

> Reading through ripe-655 multiple times, I can't find a basisfor
> counting an temporal, RA/DHCP-based, lease of PI space by an
> organisation holding Provider Independent Resources as a sub-
> assignment of a/128 prefix.
 [...]
> An »assignment« therefore is something that – to prevent the word
> »assign« here – dedicates an address space to someone for a specifc
> purpose and this act needs to be registered (see 5, and esp. 5.5)
> in an RIR database. But PI assignments cannot be assigned further,
> as clearly stated.
> 
> Operating a WiFi network for employees, relatives, event-visitors or
> even the general public (i. e. open WiFi, no WPA2) as an End User
> of Provider Independent Resources does not constitute an
> »assignment«, neither in terms of ripe-655 nor in real life.
> 
> As far as I understand the process, this WG suggests the policies
> which the NCC implements? So, unless there was a previous call from
> this WG to the NCC to interpret things as it is reportedly done –
> which, from the comment, wasn't the case? –, why not just vote on
> a statement that NCC's interpretation is outside of the scope or
> intention of ripe-655?

There is no such thing as a "vote on a statement hat NCC's
interpretation is outside of the scope". See below.

> I mean, it's not the policy that's at fault here; there exists
> an _interpretation_, used by the RIPE NCC during evaluation of PI
> space requests, which at least to me is not even remotely covered
> by ripe-655. Don't mess with what's not broken, fix what is broken ;)

As previously discussed via IRC the means of the community to "tell
the RIPE NCC how to interpret things and do it's job" are the
RIPE policies, such as ripe-655. Obviously the current policy is
"broken" - to use your wording - as there have been multiple
interpretations within the NCC.

The proposed policy change tries to close this room for interpretation
by defining "an interpretaton" for the point in question following the
Policy Development Process. See https://www.ripe.net/participate/policies
for details about this.

Best
Max

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

[William Waites]

> A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification"
> is now available for discussion.

I support this proposal as well. The current interpretation of the
policy seems pathological to be honest. It could be supposed that given
the Freifunk precedent, a local government (for example) would not be
able to get a PI assignment because they provide complimentary Wifi in
their lobby. I find it hard to believe that the original policy could
have been intended to be read like this and indeed am a little surprised
that the NCC has taken such an interpretation. So there is clearly a bug
in the policy and this patch appears to fix it.

Best wishes,
-w

-- 
William Waites
Network Engineer
HUBS AS60241

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

[Riccardo Gori]

Hi list,

I support this proposal. It's seems logical and needed modify.
Simple and easy clarification to avoid misunderstading in 
interpretation. Well done thank you Max.


I realized that I was proposing sort of this to one of my customers just 
before summer season 2016 for beach side public wifi.

Project postponed to summer season 2017 for technical reasons.

I would copy the "Contractual requirements" under "New Policy Text" 
since like this seems to be part of the modify.


regards
Riccardo

Il 21/10/2016 10:15, Marco Schmidt ha scritto:

Dear colleagues,

A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification"
is now available for discussion.

The goal of this proposal is to define sub-assignments in IPv6 PI assignments 
as subnets of /64 and shorter.

You can find the full proposal at:

 https://www.ripe.net/participate/policies/proposals/2016-04

We encourage you to review this proposal and send your comments to
 before 21 November 2016.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum



--
Riccardo Gori

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

[Richard Hartmann]

+1

Richard

Sent by mobile; excuse my brevity.

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

[Kai 'wusel' Siering]

Hello,

am 21.10.2016 um 10:32 schrieb David Croft:
> Strong support in principle. We have been denied IPv6 temporary
> assignments due to the NCC's interpretation that a single DHCP lease
> on wifi is a "subassignment" to another entity, which was clearly not
> the intention.

I'm new to this, so please bear with my simple-mindedness here,
but to me it looks like »the NCC's interpretation that a single
DHCP lease on wifi is a "subassignment" to another entity« iswhat
should be addressed, instead of special-caseing something intoan
already complex policy document.

Reading through ripe-655 multiple times, I can't find a basisfor
counting an temporal, RA/DHCP-based, lease of PI space by an
organisation holding Provider Independent Resources as a sub-
assignment of a/128 prefix.

Quoting the relevant definitions of ripe-655:
---8<---
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
therequirements of the policies described in the RIPE NCC document
entitled “Contractual Requirements for Provider Independent Resources
Holders in the RIPE NCC Service Region”.

The RIPE NCC will assign the prefix directly to the End User
organisationsupon a request properly submitted to the RIPE NCC,
either directly orthrough a sponsoring LIR.

[…]

Assignments will be made from a separate 'designated block' to
facilitate filtering practices.

The PI assignment cannot be further assigned to other organisations.
--->8---

An »assignment« therefore is something that – to prevent the word
»assign« here – dedicates an address space to someone for a specifc
purpose and this act needs to be registered (see 5, and esp. 5.5)
in an RIR database. But PI assignments cannot be assigned further,
as clearly stated.

Operating a WiFi network for employees, relatives, event-visitors or
even the general public (i. e. open WiFi, no WPA2) as an End User
of Provider Independent Resources does not constitute an
»assignment«, neither in terms of ripe-655 nor in real life.

As far as I understand the process, this WG suggests the policies
which the NCC implements? So, unless there was a previous call from
this WG to the NCC to interpret things as it is reportedly done –
which, from the comment, wasn't the case? –, why not just vote on
a statement that NCC's interpretation is outside of the scope or
intention of ripe-655?

I mean, it's not the policy that's at fault here; there exists
an _interpretation_, used by the RIPE NCC during evaluation of PI
space requests, which at least to me is not even remotely covered
by ripe-655. Don't mess with what's not broken, fix what is broken ;)

Regards,
-kai (End User since 1992)

-- 
Kai SieringSchalückstraße 107, 2 Gütersloh
eMail: wu...@uu.org   ISN: 98735*1796 × Phone: +49 172 8635608
--
"Getdate firmly  believes that years after 1999 do not exist;  getdate
 will have to be killed by the year 2000."
 -- From the "Bugs" section of cnews-020592/libc/getdate.3

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

[David Croft]

On 21 October 2016 at 12:55, Maximilian Wilhelm  wrote:
> Anno domini 2016 David Croft scripsit:
>> I note that the "New policy text" does not specify the replacement
>> text for the "Contractual Requirements"
>
> That doesn't seem neccessary as the point in question - the definiton
> of a sub-assignment - is specified in the new version of ripe-655.
>
> What are you missing?

It appears in the "Current policy text" section, which implied that it
was going to be changed in the "New policy text" section, but I guess
it's just there for context then.

David

-- 
David Croft

For support enquiries please always contact support at sargasso.net
and not any named individual. UK: 0845 034 5020 USA: 212-400-1694

Sargasso Networks Ltd. Registered in England and Wales No. 06404839.
Registered Office: 46a Albert Road North, Reigate, Surrey, RH2 9EL

http://www.sargasso.net/

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

[Maximilian Wilhelm]

Anno domini 2016 David Croft scripsit:

> On 21 October 2016 at 12:55, Maximilian Wilhelm  wrote:
> > Anno domini 2016 David Croft scripsit:
> >> I note that the "New policy text" does not specify the replacement
> >> text for the "Contractual Requirements"
> >
> > That doesn't seem neccessary as the point in question - the definiton
> > of a sub-assignment - is specified in the new version of ripe-655.
> >
> > What are you missing?
> 
> It appears in the "Current policy text" section, which implied that it
> was going to be changed in the "New policy text" section, but I guess
> it's just there for context then.

Yes, indeed. I quoted that part as it is relavant context for the
change and holds the point in questions.

Best
Max
-- 
"Wer nicht mehr liebt und nicht mehr irrt, der lasse sich begraben."
 -- Johann Wolfgang von Goethe

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

[Maximilian Wilhelm]

Anno domini 2016 David Croft scripsit:

> Strong support in principle. We have been denied IPv6 temporary
> assignments due to the NCC's interpretation that a single DHCP lease
> on wifi is a "subassignment" to another entity, which was clearly not
> the intention.

Thanks for the support.

> I note that the "New policy text" does not specify the replacement
> text for the "Contractual Requirements"

That doesn't seem neccessary as the point in question - the definiton
of a sub-assignment - is specified in the new version of ripe-655.

What are you missing?

Best
Max
-- 
<@Placebox> Gibts eigentlich IRGENDWAS im IT-Bereich, was nicht a priori 
komplett scheiße ist?
<@Zugschlus> all software sucks

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

[David Croft]

Strong support in principle. We have been denied IPv6 temporary
assignments due to the NCC's interpretation that a single DHCP lease
on wifi is a "subassignment" to another entity, which was clearly not
the intention.

I note that the "New policy text" does not specify the replacement
text for the "Contractual Requirements"

Regards,
David

On 21 October 2016 at 10:15, Marco Schmidt  wrote:
> Dear colleagues,
>
> A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification"
> is now available for discussion.
>
> The goal of this proposal is to define sub-assignments in IPv6 PI assignments 
> as subnets of /64 and shorter.
>
> You can find the full proposal at:
>
> https://www.ripe.net/participate/policies/proposals/2016-04
>
> We encourage you to review this proposal and send your comments to
>  before 21 November 2016.
>
> Regards,
>
> Marco Schmidt
> Policy Development Officer
> RIPE NCC
>
> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
>
>



-- 
David Croft

For support enquiries please always contact support at sargasso.net
and not any named individual. UK: 0845 034 5020 USA: 212-400-1694

Sargasso Networks Ltd. Registered in England and Wales No. 06404839.
Registered Office: 46a Albert Road North, Reigate, Surrey, RH2 9EL

http://www.sargasso.net/

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

[Marco Schmidt]

Dear colleagues,

A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification"
is now available for discussion.

The goal of this proposal is to define sub-assignments in IPv6 PI assignments 
as subnets of /64 and shorter.

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2016-04

We encourage you to review this proposal and send your comments to
 before 21 November 2016.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum