In your letter dated Tue, 15 Apr 2014 22:40:59 -0400 you wrote: >I'm not a large scale residential ISP, and I've never played one on TV, but >I've operated niche ISPs since 1991, and recently installed a few medium >sized business oriented DSL, Fiber and GPONs. GPONs are odd. > >I refer you to the sunset4 mailing list archives, but let me see what I recall. > >1) Let's start with PPPoE/DSL > No DHCPv4 server for IPv4, it's all done in PPP. > So you'd have to have a DHCP server somehow, or a new PPP option.
Maybe this is very the scope got overly broad. There is an easy way to signal the lack of IPv4 on PPP: just don't do IPCP. Note that signalling the lack of IPv4 in DHCPv6 over ppp when the CPE already started handing out rfc-1918 address by DHCP leads to very confusing interactions. >2) Cable/FTTH using ethernet-type things. > You need code (silicon actually, at FTTH speeds) to police DHCP traffic > coming from each customer to make sure that they aren't running a rogue > DHCPv4 server. > That's something you can get rid of if you aren't running v4. > You need to have DHCPv4 relay agents in each of your cable head ends, > and they need to add option-82 to indicate where things are coming from. > > You'd like to turn off layer-2 broadcasts (ff:ff:ff:ff:ff:ff) because > there is just a huge amount of noise coming from the customer machines, > but you can't just do that because the DHCPv4 uses that, and you've > got multiple layers of fiber backhauled cable modem. > There is a significant ARP load on the network from every single box > where 0.0.0.0/0->"eth0" because the network isn't configured yet. > (Every single directly connected windows box does this, and some distros > of Linux do this. I was surprised to learn it's allowed...) > > The broadcasts have actually forced you to subnet your IPv4 down into > rather small pieces to contain it, and this has lead to uneven > provisioning of IPv4 address space, and you've effectively run out. > (Also see the history behind ARIN > https://www.arin.net/policy/proposals/2012_7.html and > http://www.crtc.gc.ca/eng/archive/2012/2012-96.htm might also be relevant) > > If you could turn off broadcasts, you could forward just the multicast you > need (DHCPv6, RA..) which would significantly help reduce the MAC address > load on much layer-2 equipment. Moreso, it's pretty much all P2MP > traffic, so perhaps a much simpler layer-2 forwarding system could be > used. (I don't have such a thing; legacy layer-3 assumptions wouldn't let > anyone create such a thing yet) So the options are - - Just drop all ethernet broadcasts. They are not needed for IPv6 anyhow. problem solved. - - Give them IPv4 addresses without default routes. That clearly signals lack of IPv4 connectivity beyond the local subnet. - - Implement a DHCPv4 option that asks the DHCPv4 to not configure a link local address. That kills all ARP traffic and reduces DHCP traffic (though not configuring link local is less ideal from an security point of view) - - Redesign how ethernet broadcast works in those networks. I.e. treat ethernet broadcast as a special mac that needs to be routed towards the core. Problem solved. In any case, all these try to solve the problems directly instead of the rounabout way of using IPv6 to signal lack IPv4. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
