Forwarding Bernie's excellent review with his permission. Thanks,
Wes From: "Bernie Volz (volz)" <[email protected]<mailto:[email protected]>> Date: Friday, July 25, 2014 at 12:53 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: draft-ietf-sunset4-noipv4 Simon, et al: In looking back over the current draft (00) and based on Thursday’s discussion, I think the draft could be improved by documenting some of the network configurations that is trying to address. For example, dealing with no IPv4 upstream for a home’s ISP link is different than turning off IPv4 in an enterprise or on a wireless network. There is text in the introduction about some of this, but the solutions don’t necessarily match up (for example, in the CPE case where is the “no ipv4” signal expected to come from - is the ISP expected to include this in the DHCPv6 transactions done by the CPE or does the CPE determine this by not being able to obtain an IPv4 address from the ISP). I think this propagation issue needs to be better addresses for the CPE example; for the enterprise or wireless network, this is less of an issue since this is administratively determined and there is only one administrative domain. Also, although the ISP may signal “no IPv4 at all”, the home customer may well want to continue running IPv4 in their home network – regardless of what the ISP may signal. This really isn’t addressed or discussed in the draft at all. I do think the 4 levels of IPv4 service are appropriate (though they should be more advisory to the client - SHOULD actions, not MUST). I also agree with Lorenzo that DHCPv4 is probably the best way to deliver this. However, I think there should also be some tweaks to DHCPv4 clients to prevent them from using unnecessary bandwidth when IPv4 is ‘blocked’ at layer 2 or otherwise unavailable (since then DHCPv4 may not work to return this information). These tweaks are to change the cap on the exponential back-off time for DHCPDISCOVER retransmissions if no answers are received (I’d suggest the RFC 7083 values used for Solicits in DHCPv6). I also think that a CPE should only return values 0 (IPv4 fully enabled) or 2 (no IPv4 upstream, local IPv4 restricted) unless explicitly “manually” configured with values 1 and 3 (these would even prevent the CPE from trying DHCPv4 on the upstream interface – or are used when DHCPv4 is turned off on the upstream interface). I also think the option is better called ipv4 service level or ipv4 availability level or something like that (not no_ipv4). This may also be a bit more tricky in DHCPv4 because the DHCPOFFER will not want to provide an address and so will require some special handling on the part of the server and client (since both normally only send OFFERs when they have an address to offer). And, it is probably a good idea to include some text on how to handle the situation that a CPE boots and clients start sending DHCPv4 requests – the CPE hasn’t yet been able to get a response from ISP DHCP server (either the link is not yet fully established or perhaps the server is down). This is exactly the case that David Thaler (if I recall) mentioned – the server is forced to return an address and itself as the default router – but there’s no information as to whether the network is available. So, what to do – likely choices which can be left up to the vendor to decide on include: 1. Don’t answer the DHCPv4 requests until some initial timeout to allow the CPE a chance to determine this? 2. Answer but perhaps with a new, 5th value, “IPv4 availability unknown”? (While a lack of this option could be used to mean this, sending it explicitly would indicate to the client that this server supports this capability so the client might do connectivity checks or Information-Request messages periodically to obtain updates on the status.) 3. Answer but with shorter lease times to assure the at the client comes back to get updated information in a Renewal? (This one obviously requires defining this value in document.) Using DHCPv4 isn’t as good as using RAs / DHCPv6 since there may never be a response to the DHCPDISCOVER if all IPv4 is blocked; but that is what the extended retransmission timers will help with – reducing the frequency of the DHCPDISCOVERs. Only on the large flat wiki network with 20K clients flat might this still be an issue – since these are more likely ‘roaming’ devices that aren’t connected for long periods; the shorter retransmissions will still take up bandwidth. Thus, this means deploying enough IPv4 to respond to the DHCPDISCOVERs to shut down as much of this activity as possible. If I recall, I’m not subscribed to the sunset4 mailing list at present, so I did not send to the list. However, feel free to forward or reply including the list or others. - Bernie ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
