ipv4/25s and above

Joe Maimon jmaimon at jmaimon.com
Fri Nov 18 11:44:39 UTC 2022



Mark Tinka wrote:
>
>
> On 11/17/22 19:55, Joe Maimon wrote:
>
>>
>> You could instead use a /31.
>
> We could, but many of our DIA customers have all manner of CPE's that 
> may or may not support this. Having unique designs per customer does 
> not scale well.

its almost 2023. /31 support is easily mandatory. You should make it 
mandatory.

How many customer addressing designs does that total, 2? So that would 
be 1 more than you have already? Dont buy it.

Its 2023, your folk should be able to handle addressing more advanced 
than from the 90s. And your betting the future on IPv6?

>
>
>> Or private/enterprise-private
>
> Yeah, don't like that, although I understand why some operators use it.

The only issue with it is traceroute although that isnt necessarily a 
problem.

And the CPE sourced traffic should either be all internal or sourced 
from the loopback.

OTOH CoPP protection becomes a lot easier when fewer of the CP 
addressing is globally routed.

>
>
>> or unnumbered and route them the single /32 to use for their NAT on 
>> say a loopback interface.
>
> Same as the CPE issue I described above.

Truth is the real issue isnt CPE support, its user support. Most 
users(even their "IT" folk) really cant wrap their brain around more 
than the bare basic concepts, if that much.

And you can simply say, IPv4 is limited, this is the base model 
addressing included with the service, if your inabilities are preventing 
you from using networking techniques that have been standardized and 
usable for decades, then feel free to pony up for either for your 
comfort level or for support of your inabilities.

>
> To be honest, we'll keep using IPv4 for as long as we have it, and for 
> as long as we can get it from AFRINIC. But it's not where we are 
> betting the farm - that is for IPv6.

This is the crux. So long as you can obtain more, justifiable 
consumption is rewarded with additional resources, dis-incentivizing any 
addressing efficiency progress from the ancient /30 p2p + /29(or larger) 
routed block.

You may wish to lay groundwork to nibble backwards when runout occurs 
for you.

Its on Afrinic to try and preserve their pool if they wish to by doing 
things such as getting it across that progress in addressing efficiency 
is an important consideration in fulfilling requests for additional 
resources.

>
>
>> Your sales people are right. Since you can deliver quite usable 
>> service that enables them to operate just as they have before with a 
>> single /32, and with technical advantages to yourself, all the extra 
>> wasted integers should be bringing in value.
>
> At the risk of using IP addresses to prop uo sales numbers, and then 
> you run out sooner because one customer decided to pay lots of $$ for 
> a /22, even when they don't need it.

If they need more, they pay more and they get more. Most of the rest of 
the world is operating or moving to operate in that fashion.

You would still require them to submit a formal request documenting 
their need. And paying more is likely to mean that its a more honest 
request.

But see the crux above. If your RiR isnt frowning on such behavior then 
its poor strategy to implement it.

Although, if you can get away with it, allocating the /30 + /29 and 
implementing it in an easy-to-clawback approach might be a good strategy.

> Not the kind of potato I want to taste, because we have seen that 
> proposed far too many times to know it will become a reality when the 
> commissions are due.
>
> Mark.
>
>
Thats a question of internal discipline without motivating external 
factors. Odds are those factors will arrive and I would advise 
preparedness for them.

Joe


More information about the NANOG mailing list