Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

["STARK, BARBARA H" <[e-mail]>]

From: Ted Lemon <[e-mail]>

On Dec 10, 2019, at 9:16 AM, STARK, BARBARA H <[e-mail]<mailto:[e-mail]>> wrote:
Some CE routers are coded to have special handling for 0.0.0.0. Multiple ISPs use that address for IPTV multicast traffic (on a VLAN dedicated to that traffic). I could envision such routers having issues with getting 0.0.0.0 from DHCPv4. CE router vendors and their chipset vendors do the darnedest things sometimes (as Cloudflare discovered wrt 1.1.1.1).  I think widespread testing of CE routers is needed if the returned address is going to be required to 0.0.0.0.

The idea here is that the returned address is bogus and won’t work.   So if the CE router tries to use it for anything, it’s going to break, whether it’s 0.0.0.0 or 192.0.0.0.

Consider the possibility of a CE router that says: “Proper DHCP servers don’t send bogus addresses. I’m receiving a bogus address from this DHCP server. That means this DHCP server must be compromised, which means the network is compromised, which means I can trust nothing on this network. I shall now (choice A) cease all communication with this network; (or choice B) continue to send DHCPv4 messages frequently until I get one that has a non-bogus address.” We just don’t know. We had no idea that there were chipsets in routers with chipset firmware that considered messages to/from 1.1.1.1 a threat and a security violation. It’s important not to assume that routers are tolerant of 0.0.0.0 in DHCP responses. I think whoever wants 0.0.0.0 mandated or preferred needs to be the one to prove that it would not cause harm, because I’m not seeing evidence of real benefit of such normative language. If the IP address(es) to return are left up to the deployer, then the deployer can make sure whatever they do works in their network, with their server and middleboxes and whatever clients are attaching. [BTW, Ted, I’m having to change my email client settings every time to have different rules for responses to text vs. html/rich text – this is IETF, darn it, so we should all be using plain text; personal experiment over; rules favoring plain text are staying and no more switching options to satisfy people who don’t reply to text with text.]

Here is language from BBF TR-124 (requirement LAN.IGMP.ROUTED): "It MUST be possible to configure a WAN-facing IPv4 interface with an IPoE encapsulation and no IPv4 address visible by the access network. It MUST be possible to receive multicast traffic on such an interface, independent of whether upstream IGMP is sent on this interface or not. The RG's IGMP proxy-routing function MUST be able to send upstream IGMP traffic on such an interface, using an unspecified (0.0.0.0/::) IPv4 source address.”

I don’t think this would be violated.   Is DHCPv4 currently configuring an address of 0.0.0.0 for IGMP to use?  :)