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

From: Linhui Sun <[email-masked]>
Date: Sun, 26 Apr 2015 14:05:45 +0800

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

---

From: "Fan, Peng" <[email-masked]>
Date: Mon, 27 Apr 2015 20:51:19 +0800

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-masked]] On Behalf Of Linhui Sun
Sent: Sunday, April 26, 2015 2:06 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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

---

From: "Fan, Peng" <[email-masked]>
Date: Tue, 28 Apr 2015 12:58:37 +0800

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-masked]] On Behalf Of Fan, Peng
Sent: Monday, April 27, 2015 8:51 PM
To: 'Linhui Sun'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sunset4] Review of draft-ietf-sunset4-gapanalysis-07

Hi Linhui,

Comment 2:

Comment 3:

Best regards,

Peng

Dear authors,

Some detailed comments:

Best Regards

Linhui

---

From: Linhui Sun <[email-masked]>
Date: Tue, 28 Apr 2015 13:21:46 +0800

Hi, Peng

Thanks for your explanations, please see some comments inline.

2015-04-28 12:58 GMT+08:00 Fan, Peng <[email-masked]>:

> 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-masked]] *On Behalf Of *Fan, Peng
> *Sent:* Monday, April 27, 2015 8:51 PM
> *To:* 'Linhui Sun'; [email-masked];
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [sunset4] Review of draft-ietf-sunset4-gapanalysis-07
>
>
>
> Hi Linhui,
>
>
>
> 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-masked]] *On Behalf Of *Linhui
> Sun
> *Sent:* Sunday, April 26, 2015 2:06 PM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [sunset4] Review of draft-ietf-sunset4-gapanalysis-07
>
>
>
> Dear authors,
>
>
>
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4
>
> Best Regards,
Linhui

---

From: "Fan, Peng" <[email-masked]>
Date: Tue, 28 Apr 2015 15:59:50 +0800

A small complementary comment, inline [FP] please.

Comment 2:

[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:

Best regards,

Peng

Dear authors,

Some detailed comments:

Best Regards

Linhui

Best Regards,

Linhui