Hi, Peng Thanks for your explanations, please see some comments inline.
2015-04-28 12:58 GMT+08:00 Fan, Peng <[email protected]>: > 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. > [Linhui]: Great, this example is useful for me to understand this question. > > > *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. > [Linhui]: Agree, I think adding DHCP4o6 as an alternative solution in the appendix is the best way. Since I've ignored that DHCP4o6 will not implemented on every IPv4 or dual-stack host. Thus it would be clearer to treat it as an alternative. > > > 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. > [Linhui]: Well, I could get your idea now : ) > > > 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 > > Best Regards, Linhui
_______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
