Re: [dhcwg] WGLC for draft-ietf-dhc-dynamic-shared-v4allocation-02 - Respond by Oct 27, 2014

[<[e-mail]>]

Hi Bernie,

Many thanks for the review. Please see inline.

Cheers,
Ian

From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Montag, 27. Oktober 2014 04:08
To: [e-mail]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dynamic-shared-v4allocation-02 - Respond by Oct 27, 2014

While I am ok advancing this work if someone feels they need it (I would prefer we not deploy this technology and just move to IPv6 - especially as this requires making changes to hosts), I do have review comments that I believe need to be addressed:

In 1. Introduction, why reference ietf-dhc-dhcpv4-over-ip6v4? That work was an alternative to what became RFC 7341 and the WG decided that dhpv4-over-dhcpv6 was the way forward. Perhaps just drop "such as DHCPv4 over IPv6 [reference]"?

[if] I'm happy to remove this. IIRC, the ref was left in there when DHCPv4oIPv6 was intended to be an experimental RFC, but as it's no longer being updated, then it can go.

In the next paragraph, RFC 6346 is mentioned - this is an Experimental document. It is only an informational reference, so at least that may be OK. But it seems a bit odd that the text here is "This extension is only suitable for specific architectures based on Address plus Port model" when that is experimental? Even draft-ietf-softwire-map-t (-06) is going for Experimental, not standards track. (Though draft-ietf-softwire-map is going for Standards Track.)

[if] How about updating that sentence to read:
This extension is only suitable for specific architectures based on the Address plus Port model (A+P) [RFC6346], such as [I-D.ietf-softwire-lw4o6] and [I-D.ieft-softwire-map].

In 4. Functional Overview:

-          In the 2nd paragraph, this option is only used in the PRL in the DHCPDISCOVER? It is send by the client in DHCPREQUEST (DHCPRELEASE) messages. Perhaps this should be indicated?
[if] Propose the sentence with the wording
The client includes this option within the Parameter Request List option [RFC2132] in its DHCPv4 request, indicating its support for shared, dynamic address leasing to the DHCP 4o6 server.
Is updated to:
The client includes this option within the Parameter Request List option [RFC2132] in DHCPv4 DHCPDISCOVER and DHCPREQUEST messages, indicating its support for shared, dynamic address leasing to the DHCP 4o6 server.

>From my reading of RFC2131 (sec 4.4.1), PRL is not included in the DHCPRELEASE message.


-          I think in the last paragraph, first sentence, which should be that? ... to identify clients that support?

[if] New wording proposal:
OPTION_V4_PORTPARAMS is also implemented by the server so that clients supporting shared, dynamic address leasing can be
identified and so that shared IPv4 address and PSID leases can be  allocated and maintained.

In 5. Client-Server Interactions:

-          In #1, there is an opened parenthesis that is never closed.

[if] Will fix.


-          In #3, what if the client receives offers without the OPTION_V4_PORTPARAMS? Should it prefer that (I would think so)? (You do mention this later in section 7.)

[if] OK, I'll add some text to prefer the full address.


-          Ted already pointed out the issue in the last paragraph with RFC 2131 3.2 and that a DHCPREQUEST is sent, not a DHCPDISCOVER. I think this will also need some careful attention as this could result in problems if the client ends up on a different network and a server decides to allocate the requested address but doesn't support OPTION_V4_PORTPARAMs? First, I think perhaps using input from the IPv6 layer (i.e., as this is using RFC7341) can help since if the V6 stack determines the location has changed, then obviously going to DHCPDISCOVER is the better choice? (Not sure if perhaps we should recommend that existing "traditional" DHCP servers that receive a DHCPREQUEST (init-reboot) with an OPTION_V4_PORTPARAMS should either drop the packet or send a DHCPNAK it?

[if] I can add some text into the client behavior section saying:
"In the event that the client's DHCPv4o6 IPv6 source address is  changed for any reason, the client MUST re-initiate the DHCPv4o6 shared-address provisioning process by sending a DHCPDISCOVER message".

For recommending that 'traditional' DHCP servers, can we meaningfully do that in this spec? Surely existing server implementations will behave as they do, unless this is positioned as an update to RFC7341?
In 6. Server Behavior, un the 2nd paragraph "server MUST run an address and port-set" is rather odd wording? Do you implemented instead of run?

[if] Agreed. Will change.

Section 7. Client Behavior is rather similar to section 5. Kind of a bit odd order (perhaps Client-Server Interactions, Client Behavior, Server Behavior would be a bit better, but not a big deal).

[if] OK. I'll reorder them.

In 7.1, is there any RFC to reference here that describes the limitations for a node with a limited port set? For the first bulleted item, do we know what "port-aware" protocols are? I think this is not a common term, so it will have to be defined? Also for the sentence that introduces the list "Client MUST apply ... to ... the shared address"? I think what you mean here is if it provides information to another node to make connections back (into) the client, it must use its port range?

[if] We could reword to: Only port-aware protocols (e.g TCP, UDP, DCCP etc.) or ICMP implementing [RFC5508] MUST be used.
For the second point, the intention is to restrict outgoing connection's source port and service listeners to being initiated only with protocols that have L4 ports, and only to use the specific range of ports which have been provisioned to it. Can this be clarified by changing the intro sentence to?:

The client MUST apply the following rules for all traffic destined to or originating from the shared IPv4 address

In 9.1, isn't there also a problem if a malicious client doesn't follow the rules in section 7.1 if there isn't proper filtering in place (i.e., egress filtering).

[if] For this to be a problem, there would need to be operator mis-configuration in the A+P border router, and matching malicious configuration on the client. As lw4o6 & MAP implement ingress and egress checks that the packets received are valid (i.e. there must be a match between the v6 address, and source IPv4 address and L4 ports for decap and a valid IPv4 address and dst port for encap).  As this is data-plane functionality, and this draft is concerned with provisioning, do you think this needs to be re-iterated here?


-          Bernie

From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, October 12, 2014 10:14 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [dhcwg] WGLC for draft-ietf-dhc-dynamic-shared-v4allocation-02 - Respond by Oct 27, 2014


Hi all,



This message starts the DHC working group last call to advance "Dynamic Allocation of Shared IPv4 Addresses", draft-ietf-dhc-dynamic-shared-v4allocation-02, document as a Standards Track (Proposed Standard) RFC. The authors believe that this version is ready.



The draft is available here:

http://tools.ietf.org/html/draft-ietf-dhc-dynamic-shared-v4allocation-02



Please send your comments by October 27th, 2014. If you do not feel this document should advance, please state your reasons why.



There are no IPR claims reported at this time.



Bernie Volz is the currently assigned shepherd for this document.



- Tomek & Bernie