Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A detailed look at the router provided by my ISP

0x90.psaux.io

Post reply on HN
Print view View original

171–180 of 184 posts

Re: A detailed look at the router provided by my ISP

#171

Post by fulafel »

zamadatix wrote: post #60
fulafel wrote: post #4

Trivia: Strictly speaking a box that does NAT is not a router in the IP protocol sense, it's a kind of proxy. The router requirements RFC explicitly forbids altering most fields (incl the address field) in the IP header.

The NAT RFCs came after the routing RFC and refer to NAT as a router function not as an orthogonal function, boxes that do NAT are referred to as routers in the RFC. This is reflected in the real world where NAT is implemented as part of the routing chain not as a separate module. Remember NAT isn't a box creating 2 sockets and ferrying data between them it is just the translation of fields on top of normal routing f…

> boxes that do NAT are referred to as routers in the RFC

This is not the case, certainly if you are referring to the router requirements. Last I looked, the rest of the IETF was also very cognizant of the distinction, as there has been wide anti-NAT sentiment in the IETF, trying to get people to move over to IPv6 etc.

Re: A detailed look at the router provided by my ISP

#172

Post by ksec »

PhantomGremlin wrote: post #170
ksec wrote: post #144

Earlier quoted context omitted.

So they actually have an ONT somewhere and provides you with a RJ45 Ethernet port only? This is brilliant! Why aren't more ISP doing it? I dont want another ONT / Modem / piece of equipment in my flat.

Usually (always?) the way FiOS works is that every subscriber gets his own ONT. That ONT can be configured to output network bits on either an RJ45 port or using MoCA. For many people MoCA is more convenient because most houses and apartments are already wired for "cable", ie RG-6 for television purposes. FiOS is offered as a "triple play" service: internet, TV, and phone. Cable is the TV part of that. There usually…

>I'm not clear on your objection to an ONT.

Just one less pieces of equipment really. Having an RJ45 cable directly to Router is just a much cleaner solution. For those of us living in a extremely small sub 200 Square Feet apartment, getting rid of an equipment results in less cluster.

Re: A detailed look at the router provided by my ISP

#173

Post by lima »

ficklepickle wrote: post #159
pathseeker wrote: post #83

Earlier quoted context omitted.

>The Internet itself is "a zoo of endpoints on a shared medium", No, the shared medium in this case is referring the last part of the cable network where everyone in a neighborhood is transmitting effectively onto the same cable. All it takes is a single device with a broken configuration to spew crap onto the wrong channels, taking down the whole neighborhood. https://en.wikipedia.org/wiki/DOCSIS#Physical_layer On t…

That is a really good point and one I hadn't considered. Is it really that easy for a single device to take down a neighborhood? For example, could a bad actor trivially disrupt a node with a modified modem? I guess that would be difficult to defend against. I don't know enough about docsis to say if it has any protections against out-of-spec devices. I don't know why I'm surprised when things outside my area of expe…

> Is it really that easy for a single device to take down a neighborhood? For example, could a bad actor trivially disrupt a node with a modified modem? I guess that would be difficult to defend against.

Yes, similarly to how you could jam a radio frequency. Fortunately, this is rare and only ever happens due to hardware failures in modems.

Re: A detailed look at the router provided by my ISP

#174

Post by SAI_Peregrinus »

sandov wrote: post #15
packet_nerd wrote: post #9

Earlier quoted context omitted.

The box in people's home's colloquially known as a router actually commonly combines a lot of functions into one: * router * firewall * NAT device * modem * switch * access point * DNS resolver * DHCP server And probably others I'm not thinking of :-)

ONT in the case of fiber. Don't know if it technically counts as a modem.

Modem comes from MODulator/DEModulator. It's taking a signal of one sort (electrical) and modulating light to send info, and also demodulating incoming light to receive. It's a modem.

Re: A detailed look at the router provided by my ISP

#175

Post by zamadatix »

fulafel wrote: post #171
zamadatix wrote: post #60

Earlier quoted context omitted.

The NAT RFCs came after the routing RFC and refer to NAT as a router function not as an orthogonal function, boxes that do NAT are referred to as routers in the RFC. This is reflected in the real world where NAT is implemented as part of the routing chain not as a separate module. Remember NAT isn't a box creating 2 sockets and ferrying data between them it is just the translation of fields on top of normal routing f…

> boxes that do NAT are referred to as routers in the RFC This is not the case, certainly if you are referring to the router requirements. Last I looked, the rest of the IETF was also very cognizant of the distinction, as there has been wide anti-NAT sentiment in the IETF, trying to get people to move over to IPv6 etc.

Again router requirements came out before NAT, you're not going to find anything in that RFC about something else they hadn't written yet. You have to look at the RFCs for NAT to see they are referred to as routers e.g. starting with https://tools.ietf.org/html/rfc1631:

"2. Overview of NAT

The design presented in this memo is called NAT, for Network Address Translator. NAT is a router function that can be configured as shown in figure 1. Only the stub border router requires modifications."

The IETF collectively aren't big fans of NAT as a good solution but that hasn't stopped multiple standards track NAT RFCs per year. v6 only increased this with all of the transitional mode NAT types (46, 64, 464, 646).

Re: A detailed look at the router provided by my ISP

#176

Post by fulafel »

zamadatix wrote: post #175
fulafel wrote: post #171

Earlier quoted context omitted.

> boxes that do NAT are referred to as routers in the RFC This is not the case, certainly if you are referring to the router requirements. Last I looked, the rest of the IETF was also very cognizant of the distinction, as there has been wide anti-NAT sentiment in the IETF, trying to get people to move over to IPv6 etc.

Again router requirements came out before NAT, you're not going to find anything in that RFC about something else they hadn't written yet. You have to look at the RFCs for NAT to see they are referred to as routers e.g. starting with https://tools.ietf.org/html/rfc1631 : "2. Overview of NAT The design presented in this memo is called NAT, for Network Address Translator. NAT is a router function that can be configured…

That's an informational rfc that has no weight in this manner, router requirements is a standards track document.

"4.2.2 Informational

An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3)."

Re: A detailed look at the router provided by my ISP

#177

Post by lima »

metters wrote: post #94
lima wrote: post #40

Earlier quoted context omitted.

Same in Germany! ISPs hate it because it it makes their lives a lot harder - in cable networks, they now have to deal with a zoo of endpoints on a shared medium vs. a small set of standardized devices. As a customer, I like it.

They also hate it, because they cannot charge rent, like for the ISP owned router.

That's very uncommon in Germany, most ISPs provide a router for free and only charge for upgrades to more expensive ones.

Re: A detailed look at the router provided by my ISP

#178

Post by blaser-waffle »

m3at wrote: post #158
avip wrote: post #143

Earlier quoted context omitted.

This law is a tech-support nightmare. You can call your ISP with any arbitrary piece of non-branded random AliExpress $#@$ of a network eq. and they must walk you through configuring it? That does not make much sense to me.

Parent note that the ISP provide a router anyway. It's safe to assume that most people will simply use that, if not for the support just because it is already there.

Yeah this. My mom isn't ever going to add a 3rd party router. Even most of the technical people I know (well paid python devs, etc.) probably wouldn't mess the on-prem ISP gear.

I do network engineering for a living, so I totally would, but I'm an outlier compared to the rest of the population.

Re: A detailed look at the router provided by my ISP

#179

Post by detaro »

saber6 wrote: post #53
pdonis wrote: post #48

Earlier quoted context omitted.

> ISPs hate it because it it makes their lives a lot harder - in cable networks, they now have to deal with a zoo of endpoints on a shared medium vs. a small set of standardized devices. In other words, ISPs hate it because it forces them to actually do their jobs and be ISPs. The Internet itself is "a zoo of endpoints on a shared medium", and ISP stands for Internet Service Provider.

To bolster your point: Honestly they don't need to do much - the infrastructure is already there as a matter of being able to turn people's service up/down/on/off. There is always a provider-managed CPE device that functions as the service demarcation point. This is the point where your contracted service speed is enforced (shape + egress queue and ingress policing). You can have literally whatever router (dumb, smar…

Not true for actually shared media on the last mile. (also, if it's not on Customer Premises it's not a CPE)

Re: A detailed look at the router provided by my ISP

#180

Post by usmannk »

0xff00ffee wrote: post #119
usmannk wrote: post #116

Earlier quoted context omitted.

It was a “fast nmap”, so only the top 100 most common ports were checked.

Ah, thanks. If nmap was run exhaustively on all 64k ports, would that both (a) take forever, and (b) raise alarm bells on the target? Why isn't a full scan the norm?

Yes to both of those (but not thaaat long). But in this case I still would have ran an exhaustive nmap because it's a device on my local network rather than a remote server.
Post reply on HN