Here is an example that explains PROBLEM2. In a home network, when a host makes a DHCP request, the home router, which runs a DHCP server, responds to the request. In the response, the default router is set to the address of the home router (e.g., 192.168.1.1). The problem is that this happens irrelevant of the state of WAN connectivity on the home router. The home router always sets 192.168.1.1 as the default router in the DHCP response even if it doesn't have access to the Internet. This makes hosts on the LAN think that they can reach the Internet by sending packets to 192.168.1.1, which can cause timeouts and connection failures, even if IPv6 is available.
From: sunset4 [mailto:[email protected]] On Behalf Of Fan, Peng Sent: Monday, April 27, 2015 8:51 PM To: 'Linhui Sun'; [email protected]; [email protected] Cc: [email protected] Subject: Re: [sunset4] Review of draft-ietf-sunset4-gapanalysis-07 Hi Linhui, Many thanks for the review and comments. I’ll give my understanding of the second and third comments first. Comment 2: I think RFC7341 solves the problem of transporting DHCPv4 message in an IPv6 only network, but not disabling IPv4 address auto-configuration. I think we can add RFC7341 to the second paragraph of A.1.2 as a referential solution, and it should be used in combination with RFC2563. In this way, IPv4 addr autoconf can be disabled over pure IPv6 access network, but still running an IPv4 DHCP server is needed. Comment 3: Problem 13 states that other provisioning protocols such as DHCP may also develop similar on-demand IPv4 address provisioning mechanism as proposed for PPP, thus we may encounter the same problem when using those protocols. Best regards, Peng From: sunset4 [mailto:[email protected]] On Behalf Of Linhui Sun Sent: Sunday, April 26, 2015 2:06 PM To: [email protected]; [email protected] Cc: [email protected]; [email protected] Subject: [sunset4] Review of draft-ietf-sunset4-gapanalysis-07 Dear authors, I read this document and think it is really a good and useful work. The draft describes various problems that we may encounter when we desire to sunset the IPv4, also some corresponding solutions is available in the appendix. Meanwhile, I've got some minor questions and comments about this document. Since I'm not pretty much familiar with the sunset4 area, please correct me if I got something wrong. Some detailed comments: 1. In section 3.1, PROBLEM 2. Are the "default routers" just the "relay agents" in DHCP? If so, it would be better to use "relay agents" instead of the "default routers". 2. In section 3.2, the last paragraph. The text says "using this option requires running an IPv4 DHCP server". However, I think we could run a DHCPv4 over DHCPv6 server (RFC7341) here to solve the problem. DHCPv4 over DHCPv6 aims to solve the problem that DHCPv4 messages cannot be transported in pure IPv6 networks. Thus there is no need to design another equivalent protocol of RFC2563 using DHCPv6 as described in the section A.1.2. 3. In section 6, PROBLEM 13. You mentioned DHCP here, do you mean DHCP should also have a similar mechanism? Best Regards Linhui
_______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
