dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
315809
ps0ps
join:2015-08-11

5 recommendations

ps0ps to phibs

Member

to phibs

Re: [Networking] IPv6 working!

umm. I have no knowledge of the bug but it's going to most likely be on the PON side of things and not in the core network. Considering 22394 uses 701 and 22394 pushes a ton of v6 the issue isn't on the backbone but more than likely on the pon side of things.

For instance Sonic in California hasn't done v6 on their Fiber installs also due to some vendor issue.
Lexatt
join:2017-02-22
USA

7 recommendations

Lexatt

Member

If it's Juniper, it's not PON side. It may be access network side, still, but not PON. They use Alcatel and a few other vendors for PON equipment, not Juniper (I'm not even sure Juniper MAKES PON equipment off the top of my head).

Their backbone is a mixture of Cisco and Juniper, so it may well be access network. We won't ever know, unless Branch happens to get us the right insider info.
phibs
join:2012-09-25
Newark, DE

4 recommendations

phibs

Member

I mean we've been waiting since... 2012

sporkme
drop the crantini and move it, sister
MVM
join:2000-07-01
Morristown, NJ

4 recommendations

sporkme

MVM

said by phibs:

I mean we've been waiting since... 2012

Exactly. Just not believing that this bug has been around for 8+ years and every other Juniper customer was just like ¯\_(ツ)_/¯

Anon1138d
@70.30.33.x

1 recommendation

Anon1138d to ps0ps

Anon

to ps0ps
said by ps0ps:

umm. I have no knowledge of the bug but it's going to most likely be on the PON side of things and not in the core network. Considering 22394 uses 701 and 22394 pushes a ton of v6 the issue isn't on the backbone but more than likely on the pon side of things.

Definitely not limited to the PON portion of the network. This affects tons of other ISPs.
said by ps0ps:

For instance Sonic in California hasn't done v6 on their Fiber installs also due to some vendor issue.

Different issue all together.
Anon1138d

4 recommendations

Anon1138d to sporkme

Anon

to sporkme
said by sporkme:

Exactly. Just not believing that this bug has been around for 8+ years and every other Juniper customer was just like ¯\_(ツ)_/¯

They can't ¯\_(ツ)_/¯ if they're not aware of the issue. Windows is the master at having bugs that are 10+ years old that are being found now.

This is just a convenient excuse. It doesn't excuse the previous numerous years of being incompetent.
GLX
join:2000-01-18
Hoboken, NJ

4 recommendations

GLX to Anon1138d

Member

to Anon1138d
Completely wrong.

It's a PON issue related to Alcatel, who basically refused to fix it for years.

sporkme
drop the crantini and move it, sister
MVM
join:2000-07-01
Morristown, NJ

2 recommendations

sporkme

MVM

said by GLX:

Completely wrong.

It's a PON issue related to Alcatel, who basically refused to fix it for years.

How the mighty have fallen. There was a time if Bell Atlantic said "jump" to a vendor, the answer would be "how high?".
ps0ps
join:2015-08-11

6 recommendations

ps0ps to Anon1138d

Member

to Anon1138d
said by Anon1138d :

said by ps0ps:

umm. I have no knowledge of the bug but it's going to most likely be on the PON side of things and not in the core network. Considering 22394 uses 701 and 22394 pushes a ton of v6 the issue isn't on the backbone but more than likely on the pon side of things.

Definitely not limited to the PON portion of the network. This affects tons of other ISPs.
said by ps0ps:

For instance Sonic in California hasn't done v6 on their Fiber installs also due to some vendor issue.

Different issue all together.

You're completely missing the point. The quoted Juniper bugs have nothing to do with why Verizon has paused their IPv6 rollout. Spreading false information about a bug that has nothing to do with the FiOS rollout just confuses people.

Personally I have run into my fair share of IPv6 bugs with vendors, but we got them all fixed and have been running IPv6 only inside our datacenters since 2014. My guess is Verizon really wants to finally do this and ran into a show stopper that would have ended up with massive support calls. They can't just roll something out because some customers want it. The amount of bugs I had with the early testing of Comcast's IPv6 on DOCSIS was horrible and working with them to resolve the issues took a while and then viola, it slowly rolled out nation wide to where 80+% of their homes use IPv6 everyday.
Lexatt
join:2017-02-22
USA

4 recommendations

Lexatt to GLX

Member

to GLX
said by GLX:

It's a PON issue related to Alcatel, who basically refused to fix it for years.

The PON is layer 2 from GWR to customer location router. The demux interface on the Juniper router in the CO runs through an Aggregate Ethernet fiber bundle to the OLT, then it's GPON from the PON card on the OLT down to the customer site ONT, through the twisted pair Ethernet cable to the customer router. No IP. It would be weird for the layer 2 PON to have effects at layer 3 IPv6.

Is there a frame size problem with the larger IPv6 header? Maybe?

Is that likely? It wouldn't be my first guess.

The linked bug with JunOS may not be the problem, but I would bet it's there before I'd bet it's in the PON.
GLX
join:2000-01-18
Hoboken, NJ

6 recommendations

GLX

Member

That is a relatively new bug and certainly hasn't caused them to not deploy v6 for a decade+ before this.

Unfortunately I can't comment more but you're on the right track with thinking about the OLT.
gadgetinsp
join:2009-03-21
San Mateo, CA

5 recommendations

gadgetinsp to custer

Member

to custer
Verizon isn't the only one having trouble with network equipment bugs on ipv6.
Aussie Broadband pauses IPv6 trial due to Cisco bug - Latest patch solved one problem but caused another.
»www.itnews.com.au/news/a ··· g-534851

...the ASRs are currently impacted by a firmware bug that “causes the DHCP [Dynamic Host Configuration Protocol] process on the routers to crash, so customers are not able to reauthenticate,” Aussie Broadband said in a customer advisory.

...The bug has official recognition from Cisco - and is one of five that Aussie Broadband has uncovered in Cisco code over the past 18 months “that have not been discovered previously”.

Cisco Bug: CSCvr71624 - dhcpv6d memory leak when handling relay-reply with interface-id
Last Modified
May 04, 2020

Smith6612
MVM
join:2008-02-01
North Tonawanda, NY
·Charter
Ubee EU2251
Ubiquiti UAP-IW-HD
Ubiquiti UniFi AP-AC-HD

7 recommendations

Smith6612 to Lexatt

MVM

to Lexatt
I know DOCSIS is a bit of a different Animal, but I remember working with some Time Warner Cable engineers in my area on an IPv6 bug that was present in the firmware they had loaded onto the Motorola SB6141 cable modems around here. The firmware bug caused the modem to rewrite the TCP headers in all IPv6 traffic with a TCP Scaling factor of 128, on top of the base Receive/Send window set by the sender/receiver. As a result, this meant that while IPv6 traffic flowed, there was a very high number of unnecessary TCP retransmits and TCP discards, which caused plenty of issues with connection reliability and the big one... Speed. This was because of mismatches in ACK/BDP timing unknown to either end being created by the modem mangling packets. I remember spending about an hour on the phone with the engineers at Time Warner Cable running packet captures with them (they ran one on the CMTS, I ran one from my end) and diving into where the problem was.

A fix ended up being available already from Motorola / Arris, and they deployed it a few weeks later during one of their maintenance periods.
jhclce
join:2016-11-26
Obihai OBi202
Ubiquiti EdgeRouter X
Aerohive AP230

3 recommendations

jhclce

Member

Lexatt, the above reply by Smith is an excellent example of the problems that supposedly "layer 2" equipment can still manage to have related to IPv6 compatibility. There are often hidden assumptions present about the form and structure of IP packets which break when IPv6 is introduced.

sporkme
drop the crantini and move it, sister
MVM
join:2000-07-01
Morristown, NJ

1 recommendation

sporkme to Smith6612

MVM

to Smith6612
said by Smith6612:

The firmware bug caused the modem to rewrite the TCP headers in all IPv6 traffic with a TCP Scaling factor of 128, on top of the base Receive/Send window set by the sender/receiver.

Good lord, I assume this wasn't random, but some kind of misfire of a feature on the modem. KISS.
Lexatt
join:2017-02-22
USA

3 recommendations

Lexatt to Smith6612

Member

to Smith6612
Yeah, there is no limit to how badly the developers can screw up but...that is a weird one. Were the re-writes valid values?

Still, outright corruption of encapsulated data at the level of a software bug isn't something that incredibly commonly escapes acceptance testing, the PON itself is not where I would look for a bug preventing IPv6 deployment first.

Smith6612
MVM
join:2008-02-01
North Tonawanda, NY

5 recommendations

Smith6612

MVM

The re-writes were generating "Valid" values... if you assume negotiating a TCP Receive Window of 1,536,000 bytes when 12,000 bytes is the true negotiated value.
GLX
join:2000-01-18
Hoboken, NJ

2 recommendations

GLX to Lexatt

Member

to Lexatt
The PON is responsible for admission control (and identification).

Anon1138d
@70.30.33.x

1 recommendation

Anon1138d to GLX

Anon

to GLX
said by GLX:

Completely wrong.

It's a PON issue related to Alcatel, who basically refused to fix it for years.

I wasn't the one spreading the bogus information. I didn't believe it in the first place. Lots of other ISPs are running v6 on the same hw and code.
Anon1138d

2 recommendations

Anon1138d to jhclce

Anon

to jhclce
said by jhclce:

Lexatt, the above reply by Smith is an excellent example of the problems that supposedly "layer 2" equipment can still manage to have related to IPv6 compatibility. There are often hidden assumptions present about the form and structure of IP packets which break when IPv6 is introduced.

There is very little out there that is purely Layer 2 only nowadays. This isn't specific to IPv6 only. This is just where a bug has been exposed. v4 bugs of this nature have definitely existed.

Da Geek Kid
join:2003-10-11
::1

2 recommendations

Da Geek Kid to custer

Member

to custer
Is there a procedure to find out if IPv6 is enabled from Vz FIOS side? I have read that some do have IPv6 around the area, but wanted to find out if there's a way to know or request to have it enabled...?

Branch
:D
Premium Member
join:2014-07-22
VHO 4
Greenwave FiOS-G1100
Actiontec WCB6200Q

4 recommendations

Branch

Premium Member

said by Da Geek Kid:

Is there a procedure to find out if IPv6 is enabled from Vz FIOS side? I have read that some do have IPv6 around the area, but wanted to find out if there's a way to know or request to have it enabled...?

No request. You can look at yourIP in your router settings

Da Geek Kid
join:2003-10-11
::1

1 recommendation

Da Geek Kid

Member

thanks.
ingenium
join:2018-10-10
Pittsburgh, PA

3 recommendations

ingenium to Branch

Member

to Branch
said by Branch:

said by Da Geek Kid:

Is there a procedure to find out if IPv6 is enabled from Vz FIOS side? I have read that some do have IPv6 around the area, but wanted to find out if there's a way to know or request to have it enabled...?

No request. You can look at yourIP in your router settings

Technically you can request it. There was script for pfsense earlier in this thread that uses rstool and looks for a response.

Da Geek Kid
join:2003-10-11
::1

2 recommendations

Da Geek Kid

Member

Funny thing is, I tried 5 times and as usual with Vz keeps bouncing between different groups of CS teams and mostly had no clue what I was requesting, each time hold time of 3hrs.

I don't know how much Vz pays some company to get good rating for CS...

Branch
:D
Premium Member
join:2014-07-22
VHO 4
Greenwave FiOS-G1100
Actiontec WCB6200Q

6 recommendations

Branch

Premium Member

said by Da Geek Kid:

Funny thing is, I tried 5 times and as usual with Vz keeps bouncing between different groups of CS teams and mostly had no clue what I was requesting, each time hold time of 3hrs.

I don't know how much Vz pays some company to get good rating for CS...

Don't call. You cannot ask for an IPV6 address. it's a waste of time. you will get one when you get one, and probably not for a while, covid pushed back a bunch of things. I know that's not helpful but that's the way it is.
mattlach
join:2010-04-19
Woburn, MA

2 edits

2 recommendations

mattlach

Member

So,

I use a 3rd party router (pfSense)

I'm curious to check if IPv6 is available in my area. Anyone know how I should try to acquire an address range? Should I set the WAN to DHCPv6? or SLAAC?

I tried enabling DHCP6, but it doesn't appear to have pulled an address. Not sure if this is just because it isn't enabled here yet, or if it is because I have configured something incorrectly.

And on the LAN side, do they give you a block so you can use DHCPv6, or is SLAAC the only option?

Much Obliged,
Matt
jnv11
join:2015-05-18
Morrisville, NC

4 recommendations

jnv11

Member

If IPv6 is enabled in your area, your router will need DHCPv6-PD to acquire an address range on the WAN side. You can choose whatever method that you want to distribute IPv6 addresses on the LAN side once you have an address range from DHCPv6-PD on the WAN side.
mattlach
join:2010-04-19
Woburn, MA

3 recommendations

mattlach

Member

said by jnv11:

You can choose whatever method that you want to distribute IPv6 addresses on the LAN side once you have an address range from DHCPv6-PD on the WAN side.

Are you sure about that?

My understanding is that DHCPv6 currently cannot deal with having a dynamic upstream address range, and that in order to use it, you absolutely positively need to have a static block assigned, or you'll be manually reconfiguring it every time the AR changes.

So, if AR is dynamic, SLAAC is the only option.

At least this is what my reading suggests.

Anon1138d
@142.112.151.x

5 recommendations

Anon1138d

Anon

said by mattlach:

Are you sure about that?

My understanding is that DHCPv6 currently cannot deal with having a dynamic upstream address range, and that in order to use it, you absolutely positively need to have a static block assigned, or you'll be manually reconfiguring it every time the AR changes.

So, if AR is dynamic, SLAAC is the only option.

At least this is what my reading suggests.

That's an implementation issue not a protocol issue. It's how all the pieces fit together. Meaning if you have for example a DHCPv6-PD client there needs a means of (re)configuring the relevant network interfaces and then feeding the DHCPv6 server and/or the SLAAC server the first prefix when starting up and any new prefix once the existing one has expired; whether that can be done via command line parameters or generating a new config file and restarting the daemon.