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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 13 Oct 2014 02:13:34 +0000

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 21 Oct 2014 15:18:14 +0000

Reminder - this WGLC is in progress and you have until Oct 27th to respond.

-          Bernie

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

Hi all,

- Tomek & Bernie

---

From: Qi Sun <[email-masked]>
Date: Wed, 22 Oct 2014 11:38:37 +0800

Dear all, 

As one of the co-authors, I support this document to move forward. This draft describes how to allocate port-set based on the DHCP 4o6 with a newly defined DHCPv4 option. The comments from the mailing list has been addressed, and I think it ready to go. 

Thanks, 
Qi

On Oct 21, 2014, at 11:18 PM, Bernie Volz (volz) <[email-masked]> wrote:

> Reminder – this WGLC is in progress and you have until Oct 27th to respond.
>  
> -          Bernie
>  
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Oct 2014 23:54:12 -0400

> Reminder – this WGLC is in progress and you have until Oct 27th to respond.

The document has some bugs and isn't ready to be published, IMHO.   E.g., the mention of INIT-REBOOT suggests that the clients sends a DHCPDISCOVER, which is wrong.   I think it needs a close review, but I don't have time right now.  I don't think there's anything really major, but it would be good to get it right.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 23 Oct 2014 02:36:06 +0000

Hi,

I have reviewed this document and support to move it forward. This draft solves a real issue on how to allocate port-set based on the DHCP 4o6. The document have no major issue although there are a few nits, which can be solved by a quick update version.

Also, the security consideration has a reference to an individual draft. It may not be proper.

Unused Reference: 'I-D.ietf-softwire-lw4over6'
Unused Reference: 'RFC3315'
Unused Reference: 'RFC3927'
Downref: Normative reference to an Informational RFC: RFC 6269

Best regards,

Sheng

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, October 21, 2014 11:18 PM
To: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dynamic-shared-v4allocation-02 - Respond by Oct 27, 2014

-        Bernie

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

Hi all,

- Tomek & Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 27 Oct 2014 03:07:36 +0000

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

Hi all,

- Tomek & Bernie

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Oct 2014 00:10:07 -0400

On Oct 26, 2014, at 11:07 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 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),

It's needed for a softwires document that's going through IESG review this week.

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

The IESG is in the process of promoting that to standards track.   It's not experimental anymore.

Thanks for doing a more thorough technical review than I've yet had time for.

---

From: <[email-masked]>
Date: Mon, 27 Oct 2014 20:21:58 +0100

Hi Bernie,

Many thanks for the review. Please see inline.

Cheers,
Ian

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

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

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

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

[if] Will fix.

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

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

[if] OK. I'll reorder them.

[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

[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

Hi all,

- Tomek & Bernie