[address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
- Previous message (by thread): [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
- Next message (by thread): [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jan Ingvoldstad
frettled at gmail.com
Wed Feb 6 15:24:44 CET 2019
On Wed, Feb 6, 2019 at 3:16 PM Kai 'wusel' Siering <wusel+ml at uu.org> wrote: > On 06.02.2019 14:36, garry at nethinks.com wrote: > >> […] I'd > >> rather hand that /21 as two /22 to two new LIRs instead of eight /24 > >> to eight new LIRs, since a /24 is basically useless anyway. Especially > >> if you have to wait 6 or more months for it. (Of course, /22 (in up to > >> /24 slices) will mean a much longer waiting time, which makes IPv6 > >> just more interessting. Or IPv4 brokers.) > > Why is a /24 useless? > > Sorry for beeing too brief here: From my perspective, becoming an LIR > implies the intend to provide service a lot of customers, and I don't > see how a single /24 would suffice there. That's what I meant with > "basically useless" (from a business point of view). > In that case, IPv4 is "basically useless" from a business point of view. But that statement is provably false. Additionally, a lot of business is about providing services that are *not* connectivity-based, to a lot of customers. Additionally, a lot of connectivity services can be provided via NAT. And so on. This line of argument is not fruitful, sorry. Please abandon it. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20190206/0cd42654/attachment.html>
- Previous message (by thread): [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
- Next message (by thread): [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]