Fyi: Mediacom & ipv6
-
The joys of being in one of the few places fiber from more than one source is available. Does your client's prefix come from a carrier (a delegation) or do they 'own' it (if so, how much do they pay to set it up, and how much annually to keep it?) Or is the ISP the owner of the separately allocated prefix and just letting the client use it?
-
Does your client's prefix come from a carrier (a delegation) or do they 'own' it (if so, how much do they pay to set it up, and how much annually to keep it?
In this case, their own, but the carrier also provides blocks to customers. I have no idea as to costs, as I'm not involved in that. I just go and set up the equipment. There are several fibre providers in the Toronto, Ontario area. Some are old time telecom or cable TV companies and others are newcomers. There was one company which ran fibres in sewers, in exchange for cleaning the sewers. I recall some jobs, years ago, where we were running fibre in power ducts, something that would have been extremely dangerous with copper cables. Around here fibre to curb is now the norm, with newer areas, fibre to the home. I'm on a hybrid system, with fibre into the area and copper the rest of the way. I get 60/10 Mb (usually closer to 75/11), though up to 1 Gb is available from my provider, the local cable TV company.
-
The situation calls for a great deal of patience with ISP staff I'm learning. One very sincere help desk person thought the problem with the IPV6 setup was the ARP table. (FYI: IPV6 doesn't make use of ARP much less a table for it).
Today I learned that if I set up PFsense to ask Mediacom for DHCPv6, it will do the right thing: give the interface on the cable-modem side an address in the /64 prefix, then route traffic through pfsense to another interface set to 'track' on another, different ipv6 prefix. Just exactly what you'd hope for and expect so long as the best you hope for is one useable /64.
Presently though, so far as all the testing and support to date has been able to discern, static V6 setups via them have the cable modem doing neighbor discovery icmp6's looking for the static prefix on the link-local net directly connected to the modem.
A perfect catch-22. Even if one is willing to overlook the fact 'bridging is almost always bad', try to set up pfsense as a filtering bridge, the cable modem can only talk to 6 mac addresses, and they have to be registered with the ISP.
I'm working with very sincere support staff, perhaps I've missed something obvious. The only info I got was notice that I had been assigned a specific /64 address, expressed as a xxx::1/64, and two authorized mac addresses. I've tried every setup I can think of to get the thing to route that address to pfsense. Set up the WAN side to SLAAC and a static IPv6 on the LAN side thinking it would send pfsense fe80 the static traffic, etc. I tried prefix delegation hoping the static IP was prefix id 1, not 0… nope (though I had to guess at many of the parameters).
So, that's the update to the story so far.
-
'bridging is almost always bad', try to set up pfsense as a filtering bridge, the cable modem can only talk to 6 mac addresses
Why is bridging bad? 3rd party routers/firewalls are generally superior to those built into the cable modems. I have a Hitron cable modem and it's firewall is pathetic.
Also, if your're going through a router, the cable modem will only see one MAC address, the one belonging to the WAN side interface. All the other MACs are discarded as soon as the packet goes through a router and replaced by the MAC on the output port.
-
I have an ADSL modem by Zyxel that has only one ethernet port. It can be used as a NAT router (without any firewalling ability) but even the manufacturer recommends that you use the NAT mode only for the initial set up and then switch it to bridge mode.
So yes, there are use cases where NAT would be vastly inferior to bridging.
-
As of today: For business customers, Mediacom in the midwest by default will assign a /128 to a router's dhcp request. I think they really want people to use NAT66.
For $25 setup and $6/mo they will assign one static /64. Their tech support staff for business callers were gracious, but knew nothing of ipv6. I had to take them through it, then they had to find someone only available by email to discuss it with them.
They want the MAC address of anything you might put on the same layer2 link as their modem, I think the limit is 6.
Assigning a /128 and charging for a /64 are both pretty convincing evidence that this ISP doesn't understand ipv6 and probably won't figure it out anytime soon. Unless you are really attached to this ISP, you should consider switching to another ISP. In the interim, use a tunnel. I've been using a tunnelbroker tunnel for a couple of years, waiting for my ISP to deploy ipv6 (first with sophos utm then with pfsense). The tunnel has worked perfectly without any outages.
-
About all I can see that really 'works' for Ipv6 feels like one-of end users (cell phones) connecting to netflix et. al. That is: Huge source providers that have zero business-to-business demand chatting with devices that are 'owned' by their ISP for all comm purposes and will never be multihomed. This will save the ipv4 address depletion problem for them.
I have to think more about it, but so far IPV6 is struggling in the world I care about: <150 person sites that must have more than one internet on-ramp.
I doubt anyone will argue that ipv6 has taken far too long to implement, but has been growing substantially lately. I'm really glad that my ISP is finally offering it and they are doing it right. They delegate a /56 and there are no apparent restrictions as to how many. WRT netflix, along with blocking VPNs, they are now blocking ipv6 tunnels, so this is is a great reason to have native ipv6. There is a lot of misinformation about how widely implemented ipv6 really is. If you have it, you will be surprised at how much of your traffic favours it. The problem has been the ISPs taking forever to make it available. Thankfully that has improved a lot recently.
-
The situation calls for a great deal of patience with ISP staff I'm learning. One very sincere help desk person thought the problem with the IPV6 setup was the ARP table. (FYI: IPV6 doesn't make use of ARP much less a table for it).
Today I learned that if I set up PFsense to ask Mediacom for DHCPv6, it will do the right thing: give the interface on the cable-modem side an address in the /64 prefix, then route traffic through pfsense to another interface set to 'track' on another, different ipv6 prefix. Just exactly what you'd hope for and expect so long as the best you hope for is one useable /64.
Presently though, so far as all the testing and support to date has been able to discern, static V6 setups via them have the cable modem doing neighbor discovery icmp6's looking for the static prefix on the link-local net directly connected to the modem.
A perfect catch-22. Even if one is willing to overlook the fact 'bridging is almost always bad', try to set up pfsense as a filtering bridge, the cable modem can only talk to 6 mac addresses, and they have to be registered with the ISP.
I'm working with very sincere support staff, perhaps I've missed something obvious. The only info I got was notice that I had been assigned a specific /64 address, expressed as a xxx::1/64, and two authorized mac addresses. I've tried every setup I can think of to get the thing to route that address to pfsense. Set up the WAN side to SLAAC and a static IPv6 on the LAN side thinking it would send pfsense fe80 the static traffic, etc. I tried prefix delegation hoping the static IP was prefix id 1, not 0… nope (though I had to guess at many of the parameters).
So, that's the update to the story so far.
I will echo the response that there is nothing wrong with bridging. I have bonded VDSL2 service. The modem gets a prefix for itself and the LAN. It also allows one port to be bridged. I have two pfsense routers on this port. One is using a tunnel. The other is using native ipv6. Both get their own addresses. The only clue that the port is bridged is the IGMP messages that get dropped by the firewall.
-
I doubt anyone will argue that ipv6 has taken far too long to implement, but has been growing substantially lately. I'm really glad that my ISP is finally offering it and they are doing it right.
Here's what a network architect at my ISP has to say:
I can’t provide specific dates as schedules are constantly changing but I can tell you that we are working on this sequence at the moment:
1. Dual-Stack on cellular
2. IPv6 enablement on all supported cable modems (currently a one-time factory reset is needed, this would enable all remaining devices)
3. IPv6-only (using 464XLAT translation for IPv4 service) on certain mobile devices
4. Larger prefix delegation for cable modems (up to /54)Items 2 and 3 may occur in a reverse order.
Stay tuned however because things are moving faster than you may think….
They started offering a single /64 recently
-
Update:
After a bothersome delay, we had a cordial discussion with Mediacom design engineering staff.
They assign a single static /64 prefix, with their gateway at ::1. They bridge this with whatever dhcpv6 and other v4 whatnot happens within the cable modem. They approve up to I think 6 CPE devices they are willing to pass packets to within the /64 range. They expect the client firewall/router to delegate subnets smaller/higher than /65 and force use of dhcpv6 within pfsense on LAN– specifically they see support for SLAAC as a security risk.
I asked if they might satisfy security concerns by simply allowing only source IP's using the assigned /64 prefix from their cable modem in my shop, not from others. The reply was that there was a security risk without elaboration. There was talk I didn't understand about how others could 'steal the ips'. Seems to me that if my company was an ISP and I controlled the admin access point to the customer side equipment, problem solved by allowing packets with those sources and no others requiring, you know, exactly one firewall rule.
After I introduced the design engineer to pfsense, he allowed as owing to pfsense limitations (his term, I offered to run BGP if he'd liked....) they'd have to assign some out-of-scope net to make it work, I'd need to 'get with sales' about it after they had a chance to talk. The design staff made mention made of a list of certified / approved IPV6 routers, but when I asked for that list the design staff referred to sales on the line, which did not appear to know of it.
So, that's were we are so far. Their default static ipv6 product is a /64 they expect the customers will chop up into smaller prefixes the customers assign via DHCPv6, SLAAC=BAD.
-
So much of the ipV6 talk presupposes subnets smaller than /64 are in the category of 'error' it just never occurred to me an ISP would expect it.
