msiodelski / ietf-dhc-relay-dhcp4-over-dhcp6 Goto Github PK

The client's source address needs to be of the same or 'wider' scope than the destination address because the client may be instructed to use a unicast address; otherwise, the responses may not make it back. This is different than the RFC 3315 text which says to use the link-local source address.

This is a comment from Simon.
He suggested that all the "SHOULD" in the bullets change to "MUST".
I agree with most of them, except the one in bullet 3:
"(it) SHOULD send requests to the unicast address(es) in the 4o6 Server Address Option."
Because the addresses in the option may be duplicated, no matter unicast or multicast. The client MUST make sure the addresses are unique before it uses them. This is discussed in the Security Consideration section.

This is a comment from Simon Perreault. The text is in the section 8, Page 9.
He suggested this directive be rewritten so that it applies only to the interface in question, not to the whole client node. It should also be rewritten to account for the fact that the client may not have been doing regular DHCPv4 in the first place (you cannot cease doing something that you are not doing).

All the options related to DHCPv6 configuration should not be carried in the BOOTREQUESTV6/BOOTREPLYV6 messages. Do not preclude options other than BOOTP Message Option from being included in these messages as they may be required by the future drafts.

This is a comment from Simon Perreault from the mailing list.
He suggested Section "4. Architecture Overview" should explain how to use the IPv4 configuration the client has received. For example, when the client receives an IPv4 address, the draft should specify the IPv4 address is to be assigned to which interface. This is not discussed in the current version.

The IANA Considerations section should be updated according to the main text, as the number and names of options/messages have changed.

Section 8, the sentence beginning ‘The client that intends…’ should read ‘A client that intends….'

The terminology talks about DHCP 4o6 Client, DHCP 4o6 Server and DHCPv4 over DHCPv6 protocol. The term DHCP 4o6 is used in multiple places in the document which doesn't appear in the terminology and is ambiguous. Perhaps the sentences like this one:

"The client MUST obtain the necessary IPv6 configuration before using DHCP 4o6."

should be replaced by this:

"The client MUST obtain the necessary IPv6 configuration before using DHCPv4 over DHCPv6"

as the "DHCPv4 over DHCPv6" is the name of the protocol.

In the mailing list, there are suggestions to include "DHCPV4" in the message name rather than "BOOT", which may be clearer for the readers.
Two options:

1. DHCPV4-REQUEST/DHCPV4-REPLY
2. DHCPV4-QUERY/DHCPV4-RESPONSE

The text needs a final clean up.

One of the Bernie's comments is that the DHCPv4 is interface-oriented. There is a question if the 4o6 client needs to be associated with any interface to get the tunnel configuration. It could be for example associated with the v6 interface but there may be a problem to provision multiple 4o6 clients. Perhaps, we could let implementation deal with that or create a sort of provisional interface. The text of the draft should be extended to cover this.

On the mailing list, Bernie has suggested that the 4o6 Servers option could be used to enable DHCPv4-over-DHCPv6 service. When this option has no addresses the client is supposed to send requests to the All_DHCP_Servers_and_Relay_Agents multicast address. If there is any IP address this address should be used. According to Bernie, any address should be allowed: either multcast or unicast.

The regular DHCPv4 server (implemening RFC2131) uses either chaddr or client identifier to identify the client. When DHCPv4 over DHCPv6 is to be used, it is likely that the HW address of the interface being configured is not present. Therefore, the server should be using client identifier as per RFC6842 to identify the client.

Recently, we renamed the BOOTPREQUESTV6 and BOOTPREPLYV6 messages to DHCPV4-QUERY and DHCPV4-REPLY. The name of the option carrying these messages should be renamed to better reflect that it carries one of these, e.g. DHCPV4-MESSAGE?

In the introduction, the sentence:

Also, it has the added benefit of providing information about the IPv6 network
over which the request is sent, as a result of having passed through one or
more DHCPv6 relay agents.

If unicast is being used by the client, then the above is not true. Should this be updated or removed?

The last sentence of this paragraph:

" The DHCPv4-over-DHCPv6 function MUST be disabled by default. The
client MUST obtain the necessary IPv6 configuration before using DHCP
4o6. A client intending to use DHCP 4o6 MUST request the 4o6 Server
Address option using Option Request option (ORO) in every Solicit,
Request, Renew and Information-request message. The DHCP 4o6 client
MUST NOT request the 4o6 Server Address option in the DHCPv4-query
message."

could be moved to this paragraph:

" The client generates a DHCPv4 message and stores it verbatim in the
BOOTP Message option carried by the DHCPv4-query message. The client
MUST put exactly one BOOTP Message option into a single DHCPv4-query
message."

as it is logically linked with the generation of the DHCPv4-query message.