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

["Bernie Volz (volz)" <[e-mail]>]

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]"?

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.)

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?

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

In 5. Client-Server Interactions:

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

-          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.)

-          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?

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?

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).

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?

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).


-          Bernie

From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, October 12, 2014 10:14 PM
To: [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