[sunset4] Review of draft-ietf-sunset4-gapanalysis-07

[Linhui Sun]

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

[Fan, Peng]

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:sunset4-***@ietf.org] On Behalf Of Linhui Sun
Sent: Sunday, April 26, 2015 2:06 PM
To: ***@ietf.org; draft-ietf-sunset4-***@tools.ietf.org
Cc: ***@tsinghua.edu.cn; ***@chinamobile.com
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

[Fan, Peng]

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:sunset4-***@ietf.org] On Behalf Of Fan, Peng
Sent: Monday, April 27, 2015 8:51 PM
To: 'Linhui Sun'; ***@ietf.org; draft-ietf-sunset4-***@tools.ietf.org
Cc: ***@tsinghua.edu.cn
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:sunset4-***@ietf.org] On Behalf Of Linhui Sun
Sent: Sunday, April 26, 2015 2:06 PM
To: ***@ietf.org; draft-ietf-sunset4-***@tools.ietf.org
Cc: ***@tsinghua.edu.cn; ***@chinamobile.com
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

[Linhui Sun]

Hi, Peng

Thanks for your explanations, please see some comments inline.

Post by Fan, Peng
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.

Post by Fan, Peng
*Sent:* Monday, April 27, 2015 8:51 PM
*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.
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.

Post by Fan, Peng
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 : )

Post by Fan, Peng
Best regards,
Peng
Sun
*Sent:* Sunday, April 26, 2015 2:06 PM
*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.
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
https://www.ietf.org/mailman/listinfo/sunset4
Best Regards,

Linhui

[Fan, Peng]

A small complementary comment, inline [FP] please.

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.

[FP] Giving it a second thought, since it requires the implementation of DHCP4o6 client on the hosts, application of DHCP4o6+RFC2563 to disable IPv4 auto-configuration may be rather restricted. DHCP4o6 is not designed to be used universally, as shown in the text of RFC7341:

This is intended as a special-purpose mechanism that

will be implemented on nodes that must obtain IPv4 configuration

information using DHCPv4 in specific environments where native DHCPv4

is not available. Such nodes are expected to follow the advice in

Section 9; nodes that do not require this functionality are expected

not to implement it, or not to enable it by default.



Best regards,

Peng



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:sunset4-***@ietf.org] On Behalf Of Linhui Sun
Sent: Sunday, April 26, 2015 2:06 PM
To: ***@ietf.org; draft-ietf-sunset4-***@tools.ietf.org
Cc: ***@tsinghua.edu.cn; ***@chinamobile.com
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
***@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4

Best Regards,

Linhui