Hi, lets assume following (DHCP on WAN side) scenario:
A) DHCP used on WAN side to obtain WAN address/LAN prefix B) CPE routers deployed are generally dual stack enabled, by default C) as a consequence, those CPE routers do emit both DHCPv4 and DHCPv6 requests on WAN side, no customer interaction/configuration required In this scenario, CPE routers would come up dual-stacked on WAN and LAN side just fine. Now growing residential ISPs might be forced to break the 1-IPv4-per-active-customer model (v4 depletion!) and thus deploy some kind of LSN. If the chosen approach is DS-Lite, the ISP needs at some point in time start to provision customers in a way to make sure they'll use DS-Lite for IPv4 connectivity to conserve IPv4 addresses in a plannable manner. "plannable manner" means specifically that the DS-Lite provisioned customer cannot opt-out of using DS-Lite by turning off DS-Lite in the CPE router and then again get a public IPv4 address via DHCPv4. Ideally (that's the goal), wether CPE router has to use DS-Lite or just go for DHCPv4 (dual stack mode) should be signalled by the ISP to the CPE router device. Or more precise: there should be a way for an ISP to signal a CPE router that is absolute has to use DS-Lite to obtain IPv4 connectivity as DHCPv4 will fail. The customer should not have to know what "DS-Lite" is or - even worse - explicitly enable it in the CPE router GUI in order to get IPv4 connectivity behind a "DS-Lite connection". As far as I read the current drafts, there is no standardised way to do that. draft-ietf-softwire-ds-lite-tunnel-option-08 says about client behavior: A client that supports the B4 functionality of DS-Lite (defined in [I-D.softwire-ds-lite]) and conforms to this specification MUST include OPTION_AFTR_NAME on its OPTION_ORO. What does "supports" mean? Has the code, or also has DS-Lite administratively "enabled"? Let's assume "has the code". So a CPE router implementing DS-Lite will ask for AFTR address in DHCPv6 request. The draft outlines regarding DHCPv6 Server behaviour: RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and server negotiate configuration values using the Option Request Option (OPTION_ORO). As a convenience to the reader, we mention here that a server will not reply with a AFTR-Name option if the client has not explicitly enumerated it on its Option Request Option. I think that (will not reply [unless asked for]) is not really correct. RFC 3315 17.2.2 says: The server includes options the server will return to the client in a subsequent Reply message. [...] If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. [...] So in fact, "will not reply" is not the full truth. One possible approach to DS-Lite enforcement could be: - block DHCPv4 (don't reply) - always deliver AFTR address in DHCPv6 replies - ask CPE router vendors to take unsolicited AFTR address response as "DS-Lite required", to automatically enable DS-Lite operations on the CPE. If above analysis is correct, I think the AFTR DHCP option draft would need a correction about DHCP client behaviour, and if this "DS-Lite enforcement" approach would be deemed suitable for standardisation, include behaviour specification as well. I think it would be wise to standardise an "enforcement" scheme to avoid operators telling their CPE router vendors to implement "special hacks" which are operator-specific. Best regards, Daniel -- CLUE-RIPE -- Jabber: [email protected] -- dr@IRCnet -- PGP: 0xA85C8AA0 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
