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