Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Maximilian Wilhelm]

Hi folks,

Anno domini 2023 Peter Hessler scripsit:

> I still support the proposal as-is.  The proposed change does not
> weaken any data that is in the database, and in fact may allow it to be
> more obvious that these address ranges are used by end users rather than
> be unclear what their status is.
>
> Furthermore, I will state that Denis' objections are not relevant to the
> proposal.  The proposers, various people on the lists (including myself),
> and the RIPE NCC themselves all state the opposite of what Denis is
> saying.  In addition the proposers have, in my opinion, addressed the
> concerns stated.

+1 to what Peter said.

Cheers,
Max

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Maximilian Wilhelm]

Anno domini 2023 Sebastian Wiesinger scripsit:

> * Angela Dall'Ara  [2023-09-04 11:55]:
> > Dear colleagues,
> > 
> > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4
> > PA assignments"
> > is now available for discussion.
> > 
> > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA
> > assignments to reduce LIR efforts in registration and maintenance.
> 
> I support this proposal. v4 and v6 should be as feature-equal as
> possible from a database point of view IMO.

+1

Cheers,
Max
-- 
"I have to admit I've always suspected that MTBWTF would be a more useful
 metric of real-world performance."
 -- Valdis Kletnieks on NANOG

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26)

[Maximilian Wilhelm]

Moin,

Anno domini 2023 Gert Doering scripsit:

> On Mon, Apr 24, 2023 at 09:01:03AM +0200, Angela Dall'Ara wrote:
> > This proposal modifies the default size of IPv4 assignments for IXPs 
> > from a /24 to /26 and clarifies the return of the assignments previously 
> > issued for their IXP peering LAN.
> 
> Support.  v2.0 has taken the feedback about not requiring "new technology"
> in policy into account, and sticks to the key issue, reducing the 
> assignment size.  Also, /26 seems a reasonable middle way on the
> arguments heard in the previous discussion.

+1

Cheers,
Max

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] IPv6 Policy Musings...

[Maximilian Wilhelm]

Anno domini 2022 Gert Doering scripsit:

Hey folks,

> I announced too many weeks ago that a small group was looking into the
> IPv6 policy, as it is today, why it is what it is, and whether the
> underlying assumptions that the policy is based on are still valid.
[...]
> We'll present about this next week, picking some points as starting
> points for "shall we do something here?  if yes, what?  and who?" -
> but this is not about *me*, but about the commounity - *you*.  Anyone
> is free and welcome to start a discussion and work on aspects we brought
> up - or on other aspects.

Thanks for this and the work you put into it!  I also believe some
parts of the policies need some review and overhaul, and I think you
identified a lot of details to think about.  I'll try go provide a
brain dump of some topics which resonated with me and which I ran into
in the past with one of my different hats.

First and foremoest, I agree with the observation that IPv6 PI space
is a complicated beast and I still remember my last attempt at making
it more usuable so people don't have to lie about there use cases.  I
fully agree with Jan's statement at the mic that we should look into
this again and like Gert's suggestion to just drop the "3rd party
clause" of the PI policy.  In *this* case the marked might really have
solved the issue and I'd be confident the issue of ISPs only giving out
one IP per subscriber won't arise as those offers will be laughted at.

Another commonly observed obstacle with IPv6 PI has been getting more
than one /48, which also has been brought up by Max (not me :)), which
I also fully agree with.  If a network has a number of sites today and
qualifies for n * /48 prefixes and in the foreseeable future might be
able to conntect those sites (by means of DF, waves, or whatever), it
does make a lot of sense to provide this organization with the
aggregate for ceil(n * /48).  Even if the sites don't end up being
interconnected there's not much difference in prefix size and routing
table usage, but less hassle for all parties involved.

As a customer I recently ran into the issue that an IP access business
connection came with an IPv4 /29 out of the box but no IPv6
whatsoever, not even a /64 on-link which would have totally sufficed
for the use case.  To get a /56 available on that link, it needed to be
booked for 30€ MRC on top of the existing monthly fee, which isn't
very 2020.  Private customers obviously get IPv6 by default as DS-lite
is used to serve their IPv4 traffic.  Tackling business practices
isn't really within our scope, but maybe we can have this in mind when
updating BCOP documents, to "motivate" ISPs to diverge from such
practices, which certainly do not help furthering IPv6 deployment.

Cheers,
Max
-- 
Friends are relatives you make for yourself.

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] stockpiling IPv6

[Maximilian Wilhelm]

Anno domini 2020 Nick Hilliard scripsit:

> JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05:
> > However, in RIPE NCC, if you created several LIRs for getting more
> > IPv4 allocations, *even if you don't use/need it* you can get (and
> > thus stockpile) IPv6 *at no extra cost*.
> [...]
> > Do we need some text about "recovery if not announced and used" ?
> 
> tl;dr: no.

What he said.

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

Re: [address-policy-wg] PA ??? life after death

[Maximilian Wilhelm]

Anno domini 2019 Stary Bezpiek scripsit:

Hi,

[...]
> What is outdated? That Mikrotik deals V6 mostly in software? That Cisco 6800
> series (still pretty wide used) is not ready to full support of today's IPv6
> world?

Could you please elaborate on the shortcomings here?

Best
Max
-- 
 "really soon now":  an unspecified period of time, likly to
 be greater than any reasonable definition
 of "soon".

Re: [address-policy-wg] proposal to remove IPv6 PI

[Maximilian Wilhelm]

Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit:

Hi,

[...]
>> What is your real intent with all this? Simplification does not seem
>> to be it.

> For full disclosure, if you still doubt about it: My intent is only doing 
> work whenever I need it helps, for the good of the community. I'm probably 
> the most objective guy here. I've no any LIR neither end-user (in any RIR), 
> neither I plan. So, whatever is in the policies is not "affecting directly to 
> me". I only had an experimental ASN and IPv6 prefix, many years ago, when I 
> started playing with IPv6.

> Despite that, because you seem to think that I'm hiding something, whatever I 
> can say will not convince you. But put yourself in this situation. When 
> anybody submit a policy proposal, should we always think that? If we start 
> with this kind of prejudices, will never help debating on any topic. Not 
> really smart.

Now it's getting personal, which I really don't approve. After read
throught the whole thread it seems that no one else asking the same or
similar questions is getting the same treatment, so I have to ask
myself why I do.

> So, once more, can you enumerate what are the special features from IPv6 PI, 
> different that IPv6 PA, that I'm missing?

I don't want to repeat myself or others.

> Put aside for a moment all the issues related to fees, because even the AGM 
> could decide to keep the exact same fees for "end-users" as per today even if 
> we remove the IPv6 PI. So that may not change this specific aspect of the 
> overall discussion.

Even *IF* the fee issue wouldn't be touched we would have the issue
that some entities - like the RIPE NCC - cannot ever be a RIPE member,
hence the use of PI space at the meetings. This will apply to others.

To sum this up: I'm totally against this change as it *will* create a
whole bunch of new problems, obviously isn't anywhere near a possible
(even rought) consensus and I don't see a positive cost / gain ratio.

Best
Max

Re: [address-policy-wg] proposal to remove IPv6 PI

[Maximilian Wilhelm]

Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit:

Hi,

> PI and PA are artificial names for the same thing.

They are not.

> There is only one type of Global Unicast Addresses in IPv6.

Not true.

PI and PA are sliced from different pools which may have (I didn't evaluate
that by myself yet) different routing policies in the DFZ. At least
I've seen filters or BCOPs for PA space differ from PI space in the
means of what prefix lengths to accept.

> As I already explained before, the same way the AGM created the end-user 
> contract and the corresponding fee, they should be a new fee structure within 
> the LIR contract, for those that have one of few /48s instead of /32 or /29, 
> etc.

And there you are mixing GM and AP-WG again. This is neither a topic
for this WG, nor do I think that there would be any possible
consensus about a change in charging schema.

And basicly I'm with some other here:

What is your real intent with all this? Simplification does not seem
to be it.

Best
Max

Re: [address-policy-wg] proposal to remove IPv6 PI

[Maximilian Wilhelm]

Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit:

> Responding below, in-line.

*PLEASE* use some meaningful way to quote and answer inline so a
reader can distinguish between the original text and your answer. You
current mode of answering is making this really hard.

> > De: address-policy-wg  en nombre de 
> Martin Huněk 
> > Fecha: miércoles, 16 de mayo de 2018, 17:28
> > Para: , JORDI PALET MARTINEZ 
> 
> > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI
> > 
> >> Hi Jordi,
> > 
> >> As I understand it, the PA is only for a LIR and PI is also for 
> sponsored organization. Also the PI is solely for the end user infrastructure 
> and and PA can be further allocated or assigned.
> > 
> > This is our actual definition. We can change it whenever we want. What 
> I'm asking is what is the *real* distinction among them. Forget for a minute 
> in contracts, fee structure and so on. There is no need to call the same with 
> different names if we don't want. I'm calling here for simplicity. Once we 
> remove the sub-assignment obstacle, there is not anymore a difference.
> 
> Discussion should be about, if we want to / should remove such 
> *obstacle*. I would personally prefer that policy about PI space would stay 
> the same. Just RIPE NCC should be more investigative and restrictive when 
> assigning those. 
> 
> Being Internet policy is very difficult. If we have ways to avoid that, is an 
> easier way to achieve the same. Policies are for a fair distribution of the 
> resources, to make that distribution simpler, not to have complex policies 
> and then being unable to track how well anyone is behaving with them.
> 

> > Yes, that's the idea, please see my slides. PI holders will need to 
> become members, maybe the fee will get an increase (something on the line of 
> a small one-time setup fee and later on a proportion of the cost of a /32 if 
> you are getting only a /48, etc., but this is for the membership to decide). 
> What we all win with that is a fairer cost distribution and also an easier 
> way to make sure that the rules are followed and nobody tricks the rules 
> using a PI as PA. Specially for the NCC is much simpler.
> 
> Easy as a flat rate for every LIR. Actually this is the main problem 
> problem for me. LIR should by the name work as local internet registry. This 
> has been broken for IPv4 by IPv4 shortage. Not everyone should be forced to 
> be a RIPE NCC member. I'm perfectly fine with 50 EUR fee for every /48 for 
> those. Such organization which needs PI have no plans for assigning 
> 
> Is easier, but it is fair?

This is not for the AP-WG to decide.

> addresses to third parties, so why they should be LIR when they don't plan to 
> act as one?
> 
> The problem is that once we accepted 2016-04, that got broken. End-users 
> being assigned a /48 are using that now to sub-assign addresses to other 
> end-users (employees, students, users of a hot-spot, etc.).

Well, most people obviously don't consider this "broken" as there has
been a consensus after all. And I think we really made clear that it's
not a sub-assigment, which was the whole point of the last two years.

> This would make IPv6 addresses less accessible. It is like LIR saying: 
> "Do you want to have your own addresses or more then I gave you? Go to the 
> RIPE NCC and pay them 1400 EUR/y! No matter what you do...". Those PI users 
> would either loose protection of their own space or they would had to pay 28x 
> more per year plus 2000 EUR sign up fee. What would do company outside of the 
> internet business? They would not implement IPv6, that is easy! :-)
>
> As said before, this is fixed in combination with the fee structure decision 
> by the AGM. So *no*, on the contrary, will be fairer. I think probably a 50 
> Euros cost for a /48 is really too low, and may be a /32 will become cheaper, 
> and of course, a /20 more expensive. There are many possible models for that, 
> but it can be perfectly managed to avoid anyone having a requirement from a 
> /48 to not being able to afford it.
>
> >> In my opinion PI should still be here, but only for a special 
> cases, non-ISP non-LIR organizations. So if there will be any use of PI space 
> by ISP for its clients, it should be immediately reclaimed by RIPE NCC. Also 
> LIR should not be entitled to claim PI for itself. But this is just my point 
> of view.
> >
> > So then, again, let's roll back 2016-04, because is non-sense that 
> somebody instead of using the addressing space for their own organization as 
> end-user, is using it for a hotspot or datacenter.
>
> 2016-04 is not the problem, it doesn't say that you can use PI as PA. It 
> just allows you to use your PI range on your premise and give access to such 
> network to 

Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy)

[Maximilian Wilhelm]

Anno domini 2018 Gert Doering scripsit:

Hi,

> On Thu, Feb 22, 2018 at 03:34:25PM +0100, Marco Schmidt wrote:
> > A new RIPE Policy proposal, 2018-01, "Organisation-LIR Clarification in 
> > IPv6 Policy" is now available for discussion.
> 
> This policy proposal was prompted by the discussion at the last RIPE
> meeting, where the NCC brought up the issue that the IPv6 allocation policy
> talks about "organization" without ever defining what that is - "one LIR
> account", "one legal organization" (which can hold multiple LIR accounts),
> etc.
> 
> Jordi volunteered to clean up the text, and here's the proposed changes
> - but without some feedback from *you*, we can't clean this up.
> 
> [..]
> > We encourage you to review this proposal and send your comments to 
> >  before 23 March 2018.
>
> Thus: feedback please.

>   - "the text matches the original intent as I have always understood the
> policy, and we should go there"

This.

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 To Last Call (IPv6 Sub-assignment Clarification)

[Maximilian Wilhelm]

Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit:

Hi Jordi,

> none of this will change our decision, but it would make it more easy
> to the rest of the readers to understand why you're so angry *right now*,
> while neither the announcement of the extention nor the voices of support
> in the four weeks following said announcement seem to have bothered you
> in the least.
>
> [Jordi] I’m not angry at all, I just realized now that the text is not 
> consistent. I think it has been clear in my previous email to Sander. I think 
> now is clear that we all have the same view, but the text don’t look correct 
> to me, unless the NCC don’t care and in  the evaluation they will read the 
> arguments of the policy proposal, which I believe are confirming what I’m 
> saying (trying to summarize: up to /64, temporary, not for broadband, not for 
> “permanent” datacenter services).

As said before somewhere (I'm not sure wether on a RIPE meeting or
here on the list), the RS folks said, that they use the proposal text
as well as the summary/rationale as guidance what is allowed and what
isn't.

Maybe Ingrid, Andrea, Marco, * from the NCC can comment on that?

So to quote the proposal summary (last paragraph):

--snip--
Intended use cases for IPv6 PI space in the spirit of this policy
proposal are the use in (public) WIFI networks (like the WIFI at RIPE
meetings), as transfer networks on PNIs or other PTP-links/VPNs to
users or customers, or for housing/hosting for servers in data
centres. The use of IPv6 PI space for DSL/cable/FFTH/etc. subscribers
is explicitly not an intended use case for this policy proposal.
--snip--

That's quite clear IMHO (and does not fully match with your summary).

The obvious and long discussed goal of this whole thing still is to
make PI space useable again for "the little guy", community projects, etc.
As you well know the motivation to do so has risen with public WIFI
networks + SLAAC in mind, but any other means of address assignment to
clients (as you mentioned and the IA states) are OK as well. This is
the RIPE AP, it should not mention technical details which are subject
to change anyway.

Best
Max
-- 
"Does is bother me, that people hurt others, because they are to weak to face 
the truth? Yeah. Sorry 'bout that."
 -- Thirteen, House M.D.

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

[Maximilian Wilhelm]

Anno domini 2017 JORDI PALET MARTINEZ scripsit:

Hi,

> Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) 
> (that's music?)

> The main idea is to allow what Max (and many other people) needs in PI, but 
> not having restrictions.
> 
> For that, what I’m proposing is:
> 
> 1) Change the actual definition of Assign in 2.6, to:
> 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, with the exception of 
> Provider Independent (PI).
> 
> 2) Remove last paragraph in 7. IPv6 Provider Independent (PI) Assignments
> So, REMOVE: The PI assignment cannot be further assigned to other 
> organisations.
> 
> Rationale:
> 
> a. Arguments Supporting the Proposal
> This proposal will avoid the situations of breaking existing policy when a 
> network using PI is using the addressing space for point-to-point links or in 
> cases such as providing connectivity to employee or visitor devices (BYOD), 
> hot-spots, and similar situations.
> At this way, regardless of if a single /128 or /64 is sub-assigned, and 
> independently of what technology is used for that (SLAAC, DHCPv6, DHCPv6-PD), 
> the restriction is no longer an issue.
>  
> b. Arguments Opposing the Proposal
> It can be argued that this proposal could increase the number of PI request 
> to RIPE NCC.
> 
> Mitigation/counter-argument: This is not an issue and should not be 
> considered as a “bad-effect”.
> 
> The resulting policy could be used to circumvent the allocation policy, 
> avoiding creating a LIR.
> 
> Mitigation/counter-argument: This seems not to have sense as there must be a 
> justification process anyway, and because the starting point is /48, an ISP 
> willing to connect customers, will really want to be an LIR. Furthermore, if 
> we want to be restrictive on this, we could add a limitation that the maximum 
> sub-assignment can be /64.

> Thoughts?

I like the idee, but I'm totally with Nick on this one: It's a much
larger change - which I support - but don't think, that we can get
this implemented into policy in the near future. So I propose to *now*
implement my proposal with the smaller change and then get the bold
move of lifting more restrictions or even lifting the distinction
between PI/PA going.

I think it's safe to predict that if we shift to your approach right
now, we will still be discussing this on the next RIPE meeting, or
even the one after that as the area of things touched by this change
is considerably larger, as pointed out by others already. That way we
solve the real time problem - which we all agree on, right? - right
now and make PI great again, and then have time to make the world and
even better place afterwards. :-)

Best
Max

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

[Maximilian Wilhelm]

Anno domini 2017 JORDI PALET MARTINEZ scripsit:

Hi Jordi,

[...]
> I feel that the current version is solving partially Max case, but even in 
> his case, if he decides to provide /64 for each hot-spot customer, this 
> proposal will not work.

Actually the NCC IA interpretation is rather clear on this one - as
Marco (IIRC) confirmed while the WG session. /64 assignments to hosts
aren't a problem with the current policy text / interpretation.

Best
Max

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

[Maximilian Wilhelm]

Anno domini 2017 Marco Schmidt scripsit:

Hi Marco,

> Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the 
> Review Phase.

Cool, thanks for that!

> The goal of this proposal is to re-define the term "sub-assignment" for IPv6.
> 
> This proposal has been updated following the last round of discussion and is 
> now at version v2.0.
> Some of the differences from version v1.0 include:
> - the scope is extended to all IPv6 assignments
> - it defines that the provision of separate IPv6 addresses is not considered 
> a sub-assignment
> 
> The RIPE NCC has prepared an impact analysis on this latest proposal version 
> to support the community’s discussion. You can find the full proposal and 
> impact analysis at:
> https://www.ripe.net/participate/policies/proposals/2016-04
> 
> And the draft documents at:
> https://www.ripe.net/participate/policies/proposals/2016-04/draft

There seem's to be some glitch in the comparison between the proposal
versions. The diff seems to be in the wrong direction. Could you have
a look at that?

Thanks!

Best
Max
-- 
"I have to admit I've always suspected that MTBWTF would be a more useful
 metric of real-world performance."
 -- Valdis Kletnieks on NANOG

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)

[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)

[Maximilian Wilhelm]

Anno domini 2016 David Croft scripsit:

> On 21 October 2016 at 12:55, Maximilian Wilhelm <m...@rfc2324.org> 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-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Maximilian Wilhelm]

Anno domini 2016 Ciprian Nica scripsit:

[...]
> Yes, start praising people if that's the purpose of this list. Hitler was
> also a very praised man.

https://en.wikipedia.org/wiki/Godwin%27s_law


Best
Max

Re: [address-policy-wg] IPv6 PI assignment policy

[Maximilian Wilhelm]

Anno domini 2015 Gert Doering scripsit:

Hi,

 On Sat, Jun 27, 2015 at 03:29:54PM +0200, Thomas Drewermann wrote:
  the Freifunk communities are not going to give /64 to end users.
  There will be one single IPv6 address leased to end users connecting to
  the wireless networks.

 So what's the user to do with this single address, and his network behind
 his router?  User IPv6 NAT/Masquerading?

Hell no :)

There is no his router.

 I strongly encourage you to re-think this approach.

There seems to be a fundamental misunterstanding:

  A user in this case is a human using his/her/its
  mobile/tablet/laptop/youNameIt device and connects it to the wifi
  network (or connects it via ethernet cable to a network port of a
  local Freifunk node).

  It is no intended scenario that anyone connects a router to the
  Freifunk network to connect own network, so by definition there is no
  need for NAT. (There are some considerations to used routed /64
  inside the Freifunk mesh network instead of a large L2 segment but
  even then there would be no intended scenario where anyone would
  connect some non-Freifunk router.)

  We provide an access network for single devices not for (home)
  networks and by no means plan on changing that.

 [..]
  Since no Freifunk communities has the need for a /32 prefix that would
  be a waste of addresses.

 The whole point of IPv6 is to have plenty of addresses - and as there are
 4 billion /32s, using one to give your users at least a /64 is the *right*
 way to waste addresses.  Do not encourage anyone to use NAT66.

This is not an intended scenario for a Freifunk network. We don't want
to be in competition with any regular ISP. And we certianly won't
encourage anyone to use NAT66.

  @Sascha Luck: I think the policy should reflect that as it does for IPv4.
  Speaking in IPv4 this problem would not have occoured:
  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.
  
  That problem has already been identified. (page 8)
  https://ripe69.ripe.net/presentations/72-APWG_RS_Feedback_Final.pdf

 Yes, we're aware of that, but this is the old a user only needs
 to have a single IP address, and can use NAT world.

Well how about single IP address without NAT?

 Since we do not want to encourage this model for IPv6, nobody has ever
 brought forward a proposal to allow this approach for IPv6 PI.

 (Now, I have no good answer what the Freifunk community *should* do.  I can
 understand that you're indeed set up quite differently than a traditional
 ISP - OTOH, you're not the only one who runs a network on a non-commercial
 basis and needs IPv6 addresses.  So using PA space from a friendly ISP in
 the neighbourhood - like, a /40 or even a /32 - might be a workable
 solution...  yes, renumbering will be nearly impossible, but right now
 the RIPE model doesn't really permit free rides I want my own addreses,
 I want to run something that is similar to an ISP business, I want a slot
 in the global routing system, but I am not going to pay for it.  We might
 want to change our member structure to accomodate non-commercial LIRs - but
 that's a topic for the AGM to decide...)

IMHO that would be something worth a discussion.

Kind regards
Max
Freifunk Paderborn / Freifunk Rheinland
-- 
If it doesn't work, force it.
If it breaks, it needed replacing anyway.

Re: [address-policy-wg] IPv6 PI assignment policy

[Maximilian Wilhelm]

Anno domini 2015 Ondřej Caletka scripsit:

Hi Ondřej, hi list,

 I'm not sure what networks typically a freifunk community network
 oparates. But if it can be compared to a very small ISP with tens to
 hundreds customers, than the PI assignment is not an option due to its
 fixed size of /48 which is simply not enough. You are not going to give
 a single /64 to customer, are you?

God no :)

A Freifunk network is a mesh network (build upon a BATMAN Layer 2 mesh
in most cases, but other solutions exist, OLSR based f.e.) where
interested individuals can connect their Freifunk node to and become
part of that independent peoples network.

So a /48 allocation/assignment would be totally enough to fulfill this
scenario(s).

 On the other hand, if the freifunk only operates a few hot spots,
 comparable to some Wi-Fi service in a restaurant, etc. then all
 addresses can be in my opinion counted as a part of organisation
 infrastructure so the PI rules would not be violated.

What definition would be required for organization? Usually a local
Freifunk community is organized as lose group of interested people who
may or may not have set up a registered association to have a legal entity.

The goal behind Freifunk is that everyone can participate in a free
and open wifi network by just bying some wifi hardware, installing
some pimped OpenWRT software on it and connecting it to the wifi cloud
(or via VPN to central network points). There is no central management
of all nodes, membership requirement or anything the like.

  Small Hotspot providers and especially Freifunk communities typically
  can not afford a LIR Membership to be independent. In my opinion the
  current policy makes it hard to adopt IPv6 in such cases.

 Everybody would like to be independent to have some back-up scenario if
 something happen to their main uplink ISP. However, every new PI
 assignment have a permanent negative impact on the global routing table.
 I therefore think it is reasonable to have some limit for obtaining
 independent resources such as the RIPE NCC membership fees.

 What if the freifunk communities formed an alliance and become a LIR as
 a part of the alliance? It would lower the costs of becoming a LIR and
 at the same time allow communities to get enough independent IPv6
 addreses that could be assigned to customers.

Well that's basicly the idea behind Freifunk Rheinland :)
Which is fine for legacy IP 'n stuff but for larger Freifunk networks
raises some problems and limitation as Thomas mentioned.

  I'd like to propose a change of the policy to allow PI addresses to be
  used for clients which don't belong the assigment-holder. This clients
  are connecting to networks which use address space of the holders PI
  assignment e.g. via wifi.

 I don't think it's a good idea. There is a reason why the usage of PI
 addresses is restricted. I think your proposal would lead to a situation
 where everybody uses PI addresses just-in-case even if they don't really
 need them, thus flodding the global routing table.

Although I get your points, there's an operational downside to this:

As every Freifunk community which exists or pops up in any major and
minor city around Germany operates on their own, each community would
need to have a /32 assignment to be able to set up local peerings.
Some local ISPs would sponsor peerings and provide IPv6 transit for
free if we were able to announce our own prefix to them which we can't
today even if we have a /48 assignment from our Freifunk alliance LIR
(as this would probably be filtered away by most of you as it's from
 the PA pool).

As communities don't have money for leased lines/dark fiber/etc. to
connect to one or better two of those central LIRs only VPNs/GRE tunnel
to central nodes are in the cards and local peerings are out of the
picture. I'd really like to leverage the offers of our local ISPs to
peer with us and provide IPv6 upstream for more stable connectivity,
less latency and more bandwidth.

So our only hope would be to get a /48-PI prefix (or a /32 PA one
which would be hugh waste of addresse space in my opinion) and
wouldn't make a difference in number of routes in the DFZ anyway.

Kind regards
Max
Freifunk Paderborn (+Freifunk Rheinland associate)

Re: [address-policy-wg] IPv6 PI assignment policy

[Maximilian Wilhelm]

Anno domini 2015 Sascha Luck [ml] scripsit:

 On Fri, Jun 19, 2015 at 09:52:10PM +0200, Ond?ej Caletka wrote:
 I don't think it's a good idea. There is a reason why the usage of PI
 addresses is restricted. I think your proposal would lead to a situation
 where everybody uses PI addresses just-in-case even if they don't really
 need them, thus flodding the global routing table.

 You might as well get used to the idea. If seen as a loose
 federation of independent network clouds (as I understand the
 Freifunk idea, correct me if I'm wrong), this offers a first
 glimpse into how things will be if and when the Internet of
 Things becomes something more than vapourware. We might as well
 start thinking about how to solve the coming resource management
 issues.

When by »loose federation of independet network clouds« you see
every Freifunk community as one or more clouds which are loosely
federated by mail/IRC communicated admins, then I could agree :)

 For the Freifunk people here, could you provide some detail on
 how this is solved for IPv4 at the moment?

There currently are some solutions used by the different communities:

 a) each Gateway (central node in the Batman mesh network) has it's
own VPN uplink to $vpn_provider (for legal reasons, usually
outsite .de (think: Störerhaftung)) with NAT44 on the gateway and
usually on VPN provider site, too.

 a2) Some internal routing to some concentrator nodes, then VPN uplinks
 there + NAT(s).

 b) GRE uplinks to Freifunk Rheinland e.V. who - as becoming LIR a
not long ago - own a /22 and delegate small prefixes to each
community over GRE tunnels + NAT44 before the GRE uplinks.

 c) I know of a least one lucky community which got a /24 delegation
sponsored from one friendly ISP in northern Germany - may he out
himself as I guess he's on this list - so they can use direct
peerings for v4, too.

But as legacy IP already is depleted there's not much thought put into
that area in general as there's not much which can be done about it if
there's no solution c) available. Personally I don't worry about IPv4
(besides building some active-active NAT44 solution with option »b«
 right now, which is kind of PITA) and put more hope into IPv6 where
a large enough prefix which we could announce directly would
enormously improve our upstream situation.

I hope I could shed some light on the topic.

Best
Max
-- 
If it doesn't work, force it.
If it breaks, it needed replacing anyway.