Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 20, 2021, at 06:48 , Brian Turnbow via NANOG  wrote:
> 
> Hi,
> 
>>> v4 is so thoroughly fragmented and v6 is a lot less likely to become
>>> so.
>> 
>> It is true that fragmentation is a problem. However, it merely means that 
>> IPv6
>> address space will also be fragmented and that
>> IPv4 can but IPv6 can't be deployed at full scale,
> 
> Just this week We had our first customer asking if we can setup BGP to route 
> the /48 they received from the headquarters in the states.
> They are asking us to provide a few v4 addresses , but to use their own v6 
> block.
> Yes they are a large conglomerate with their own AS and a large v6 
> allocation, so not a common customer, but they have hundreds of offices 
> everywhere in the world where they are doing this... 
> I can just see the Cxx presenting their solution at some event and it 
> becoming the new thing to do
> What you are still using your providers addresses? You must be crazy... We 
> assign our own it's much better...
> A couple hundred corporations like this and the v6 table would surpass v4...

In such a case, I’m not convinced that’s a bad thing.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 20, 2021, at 05:15 , Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
>>> But, on routers, IPv6 costs four times more than IPv4 to look up
>>> routing table with TCAM or Patricia tree.
>>> It is not a problem yet, merely because full routing table of IPv6
>>> is a lot smaller than that of IPv4, which means most small ISPs and
>>> multihomed sites do not support IPv6.
>> Well, it’s a combination. Even with full v6 adoption, the routing
>> table in v6 should be substantially smaller.
> 
> Not at all.
> 
>> Compare AS6939 v4 vs. v6:
> 
> That is not a meaningful comparison.
> 
> As mergers of ASes increases the number of announcements
> and IPv4 addresses were allocated a lot earlier than those
> of IPv6, comparing the current numbers of announcements is
> not meaningful.

Mergers of ASes does not increase announcements in IPv4 nearly as much as 
slow-start
and repeated expanding requests for additional IPv4 space have.

> As a result, size of global routing table will keep
> increasing unless there are other factors to limit it.

Sure, but it’s very clear that the rate of increase for IPv6 appears to be 
roughly 1/8th that of
IPv4, so even if IPv6 was 4x as expensive, the growth rate in cost would still 
be 1/2 that of
IPv4.

> An important factor is that, for IPv4 with globally
> routable /24, the absolute upper limit is merely 16M,
> to be looked up by a single memory access of conventional
> SRAM without needing TCAM. OTOH, IPv6 is hopeless.

The reality is that IPv4 will never be completely disaggregated into /24s and 
IPv6 will never
be completely disaggregated into /48s, so this is actually meaningless and not 
predictive
in any way.

> Another favorite factor for IPv4 is that, though most of
> routing table entries are generated from small entities
> having a /24 assuming NAT, if such entities are merged,
> renumbering is not so much a pain and they are motivated
> to rely on a single /24 and sell others. OTOH, there is
> no such motivation for IPv6.

There is no need for such motivation in IPv6 and better yet, since the two 
organizations
have fully globally unique addresses deployed throughout their network, there’s 
no risk
of collisions in RFC-1918 space necessitating large renumbering projects to 
merge the
networks. Indeed, all you need to do is turn on forwarding between the two 
networks
and you’re basically done.

As such, no, that’s an advantage that clearly goes to IPv6, not IPv4.

> 
>> v4 is so thoroughly fragmented and v6 is a lot less likely to become
>> so.
> 
> It is true that fragmentation is a problem. However, it merely
> means that IPv6 address space will also be fragmented and that
> IPv4 can but IPv6 can't be deployed at full scale,

Why would IPv6 become fragmented? When a provider the size of HE can
easily get a /24 from ARIN, what need is there for fragmentation. Sure, they
started with a /32 and they’re keeping that, but the equivalent growth in IPv4
would have resulted in a /20 + /19 + /18 + /17 + /16 + /15 + /14 + /13 and 
likely
an additional /12 eventually. So you get 7-8 prefixes for the same factor of 
growth
as 2 prefixes in IPv4.

It simply doesn’t make sense to claim that fragmentation in v6 will be nearly 
as bad
as it is in v4 because we don’t have the problems of slow start and we’re no 
longer
trying to balance scarcity against aggregation.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 19, 2021, at 16:17 , Victor Kuarsingh  wrote:
> 
> Owen,
> 
> 
> On Sat, Sep 18, 2021 at 23:51 Owen DeLong  > wrote:
>> On Sep 18, 2021, at 12:34 , Victor Kuarsingh > > wrote:
>> 
>> On Sat, Sep 18, 2021 at 2:39 PM John Levine > > wrote:
>> It appears that Owen DeLong via NANOG > > said:
>> 
>> 
>> Glad you noted this.  Thinking this was/is purely a hardware cycle problem 
>> related to normal/forced upgrade strategies.  On that point, most hardware I 
>> know of from 2004 in larger networks is long fully depreciated and sweating 
>> assets 15+ years can happen, but I don't personally think this is the 
>> biggest issue.
> 
> It’s certainly not purely hardware, but it also doesn’t require solving the 
> entire problem across the entire backend.
> 
> What is urgently needed is to fix the customer-facing front end so that it 
> speaks both protocols (or at least speaks IPv6).
> 
> This is a great question.  So when we approached this (going back a while 
> now) this is what I thought too.  But I was responsible to solve this end to 
> end.  So just updating front end (CPEs, network routers, DHCP, provisioning, 
> IP address planning, security, peering/transit, staff training, test 
> harnesses/plans, etc) was not sufficient to turn on IPv6. 
> 
> The high cost and time challenge issues were not upgrading backend servers to 
> IPv6, but backend provisioning systems, tools, customer support tools, their 
> training, and related items.  These systems were far more complex and costly 
> to address (especially when considering opportunity cost).   Without all of 
> this in place, we could not actually deploy IPv6 for production use (it’s not 
> just Turing it on, its our ability to operate it down to the person answer 
> the phone, the technician that installs and/or fixes/replaces items in home). 

This sounds like an eyeball environment… Note that my question was in the 
context of the laggard content providers.

Eyeball providers are going to have to do something eventually whether they 
like it or not and I’m a whole lot less worried about a forcing function for 
them.

The major eyeball providers have basically completed this. Hopefully that means 
that the vendors you’re using have been forced to upgrade their code and such 
to accommodate by now.

> Also at that time vendor CPE hardware was not as far along on IPv6 readiness 
> (approx mid-decade 2000s).  Getting reliable code at that time was hard with 
> a lot of brokenness (which also could not go into production until it was 
> reliable).  Perhaps this a non-issue today, but it certainly was not a 
> something that was “ready to go” even 10-15 years.   This (IPv6 readiness in 
> CPE code) was also competing with other priorities often blowing up timelines 
> which meant it had to wait as not releasing code into production on a strict 
> timeline was not an option for business reasons.

Sure, but a lot of that has gotten better in the recent years, largely driven 
by some of the major eyeball ISPs.

> All said and done, we got it completed, but it far most costly than we first 
> thought, and IPv4 costs did not go away after we were completed.  Sure it’s 
> possible to reduce those costs with an aggressive program, but it is not as 
> simple as many think.

Agreed… IPv4 costs for you, as an eyeball provider, can’t really go away until 
you can start doing one or more of the following:
1.  Raising your overall rates and providing a discount to 
IPv6-only customers
2.  Adding a surcharge to your billing for customers still 
requiring IPv4 services
3.  Turning off or reducing availability of IPv4 native services 
and moving more towards IPv4AAS
4.  Turning off IPv4 services outright

All of those basically depend on moving a few key laggard content providers 
forward.

>> As you noted John, its the plethora of software, support systems, tooling, 
>> and most important in many environments - legacy customer management and 
>> provisioning systems that can be the limiting factor.  I recall looking back 
>> when leading IPv6 turn-up, those were the biger problems to solve for.  
>> Often such systems are extremely expensive to touch and working on them 
>> required prioritization against direct revenue generating projects 
>> (opportunity cost) .  Replacing routers was just a money problem.
> 
> Why do those systems have to be updated in order to deliver the service to 
> the customer in both protocols?
> 
> Addressed in above comment.  

Eyeball… Now think about it in the context of a content provider… Especially 
one that is behind a CDN where it’s literally simply flipping the switch on the 
CDN
that says front end our stuff with both protocols.

> When it comes to turning on IPv6 and reducing your dependency on IPv4, your 
> mileage may vary (in terms of real costs, complexities and deployment).   

Four years since Hurricane Maria hit Puerto Rick/US Virgin Islands

[Sean Donelan]

Wednesday, September 20, 2017, Hurricane Maria struck Puerto Rico with 
sustained winds of 155 mph. An estimated 2,975 people died in PR, 3 in 
USVI, and 81 the other parts of the carribean. It caused over $90 billion 
in property damage.


The Puerto Rico power grid was effectively destroyed by the hurricane, 
leaving millions without electricity. It still has not been fully 
restored, with rolling blackouts still occuring. Over 95% of the islands 
had no cell service, and other telecommunications service was limited 
mostly to San Juan metro area.  Only a handful of radio stations were 
still operating.


Only about $18 billion of the $63 billion allocated by Congress for 
disaster relief and recovery has actually been disbursed. Most of the 
remaining funds are not expected to be disbursed until after fiscal year 
2025.

Re: IRR Upstream\Downstream

[Matthew Petach]

On Mon, Sep 20, 2021 at 5:09 PM Mike Hammett  wrote:

> I'm trying to firm up my grasp of how I define my neighbor ASes in my IRR
> entries.
>
> https://bgp.he.net/AS40764#_irr
>
> In my aut-num, I've defined my two upstreams (Intercarrier and Cogent).
> I've used their AS-Set or just their AS and used that in the export lines.
>
> I'd assume I'd do the reverse in the import fields for any downstream
> customers.
>
> I realized after looking at this that I need to add an export to IX and
> other peering connections.
>
> What else do I need to change?
>
>


I find it easier to put in a set of entries like this:

import: from AS-ANY accept ANY export: to AS-ANY announce
AS-DIGITALNETWORKACCESS
 mp-export: afi ipv6
to AS-ANY announce AS-DIGITALNETWORKACCESS
-V6
mp-import: afi ipv6 from AS-ANY accept ANY

That takes care of anyone on an IX peering port that is doing filtering
based off IRR policies,
and then you should apply your own sanity filters on your import policies
on your router,
which you can update programmatically without having to keep updating your
IRR
policies.  ^_^

Matt





>
>
>
> Yes, I realized that I just asked NANOG to criticize me. Hopefully, I get
> more help than flames.  ;-)
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>

IRR Upstream\Downstream

[Mike Hammett]

I'm trying to firm up my grasp of how I define my neighbor ASes in my IRR 
entries. 


https://bgp.he.net/AS40764#_irr 


In my aut-num, I've defined my two upstreams (Intercarrier and Cogent). I've 
used their AS-Set or just their AS and used that in the export lines. 


I'd assume I'd do the reverse in the import fields for any downstream 
customers. 


I realized after looking at this that I need to add an export to IX and other 
peering connections. 


What else do I need to change? 








Yes, I realized that I just asked NANOG to criticize me. Hopefully, I get more 
help than flames. ;-) 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

Fwd: [safnog] Reminder: SAFNOG-6 Virtual Conference

[Mark Tinka]

FYI.

Mark.

 Forwarded Message 
Subject:[safnog] Reminder: SAFNOG-6 Virtual Conference
Date:   Mon, 20 Sep 2021 16:23:37 +0200
From:   SAFNOG Conference 
To: saf...@lists.safnog.org



Hello Everyone,

SAFNOG-6 Virtual Conference is just one week away!

This is a reminder to join us for SAFNOG's sixth annual meeting, 
SAFNOG-6 Virtual Conference 
 next week 
on the 27 and 28 September at 13h00 SAST/ 11h00 UTC.


Don't miss this opportunity to engage with and learn from our industry 
experts such as our *keynote speaker*, *Eddy Kayihura from AFRINIC.*  
Visit https://safnog.org/virtual-meetings/agenda 
 for the full agenda.


We are grateful to our SAFNOG-6 sponsors, Akamai, FLEXOPTIX, Team Cymru, 
Africa Data Centres, Internet Society, Workonline, INX-ZA and NAPAfrica 
for their support.


Register now: https://safnog.org/virtual-meetings/ 



Regards,
SAFNOG OC
___
safnog mailing list
saf...@lists.safnog.org
http://lists.safnog.org/listinfo/safnog

RE: IPv6 woes - RFC

[Brian Turnbow via NANOG]

Hi,

> > v4 is so thoroughly fragmented and v6 is a lot less likely to become
> > so.
> 
> It is true that fragmentation is a problem. However, it merely means that IPv6
> address space will also be fragmented and that
> IPv4 can but IPv6 can't be deployed at full scale,

Just this week We had our first customer asking if we can setup BGP to route 
the /48 they received from the headquarters in the states.
They are asking us to provide a few v4 addresses , but to use their own v6 
block.
Yes they are a large conglomerate with their own AS and a large v6 allocation, 
so not a common customer, but they have hundreds of offices everywhere in the 
world where they are doing this... 
I can just see the Cxx presenting their solution at some event and it becoming 
the new thing to do
What you are still using your providers addresses? You must be crazy... We 
assign our own it's much better...
A couple hundred corporations like this and the v6 table would surpass v4...

Brian

Re: IPv6 woes - RFC

[Masataka Ohta]

Owen DeLong wrote:


But, on routers, IPv6 costs four times more than IPv4 to look up
routing table with TCAM or Patricia tree.

It is not a problem yet, merely because full routing table of IPv6
is a lot smaller than that of IPv4, which means most small ISPs and
multihomed sites do not support IPv6.


Well, it’s a combination. Even with full v6 adoption, the routing
table in v6 should be substantially smaller.


Not at all.


Compare AS6939 v4 vs. v6:


That is not a meaningful comparison.

As mergers of ASes increases the number of announcements
and IPv4 addresses were allocated a lot earlier than those
of IPv6, comparing the current numbers of announcements is
not meaningful.

As a result, size of global routing table will keep
increasing unless there are other factors to limit it.

An important factor is that, for IPv4 with globally
routable /24, the absolute upper limit is merely 16M,
to be looked up by a single memory access of conventional
SRAM without needing TCAM. OTOH, IPv6 is hopeless.

Another favorite factor for IPv4 is that, though most of
routing table entries are generated from small entities
having a /24 assuming NAT, if such entities are merged,
renumbering is not so much a pain and they are motivated
to rely on a single /24 and sell others. OTOH, there is
no such motivation for IPv6.


v4 is so thoroughly fragmented and v6 is a lot less likely to become
so.


It is true that fragmentation is a problem. However, it merely
means that IPv6 address space will also be fragmented and that
IPv4 can but IPv6 can't be deployed at full scale,

Masataka Ohta

Re: (Free)RADIUS Front-End

[Mark Tinka]

On 9/20/21 02:16, Philip Loenneker wrote:

Splynx is a commercial product designed to be an entire package for running an 
ISP, including billing etc. It uses FreeRadius in the backend which chains into 
their own RADIUS system. Integration for MikroTik routers is very extensive, 
but we have had it working with a variety of other BNGs too including Cisco and 
Linux-based systems. You can add in RADIUS dictionaries and customise the 
router profiles via the GUI to send whatever VSAs you require, including for 
COA. The APIs on it are extensive, making automation of service provisioning 
relatively easy. The IPAM in it is fairly basic, primarily ensuring that you 
don't re-use IPs between multiple services. IPv6 support is included, but 
primarily for IPv6-PD rather than interface IPs, however I have managed to get 
a BNG to assign an IPv4 address, an IPv6 interface address and IPv6-PD all from 
the Splynx profile. The accounting is ok, allowing you to apply bandwidth caps 
on users if required, including different speeds for different times of day.

www.splynx.com


Many thanks, Philip. Looks awesome!

Mark.