Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

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

I wasn't concerned with latency itself - except for the big one ... being able to get the packets through at all.

If PMTU for UDPv6 is always done and works great - then there is no issue as PMTU should work it out.

> Middlebox brokenness is an issue when packets cross networks that are not controlled by the operator.   

If that is the case, then PMTU or using MIN MTU does not help us. We must assume that this is not the case (if we are to use larger packets).

Or, perhaps we need a relay to relay <-> relay / server TCP (STCP, ...) packet delivery capability :).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Ted Lemon
Sent: Wednesday, May 07, 2014 3:29 PM
To: Bernie Volz (volz)
Cc: dhcwg; 神明達哉; Ralph Droms
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

On May 7, 2014, at 2:14 PM, Bernie Volz (volz) <[e-mail]> wrote:
> 1. There is client unicast. Though not sure how much it is used.

You may have missed the point in my message where I addressed that.   Since unicast _only_ happens on renewal, there is no latency issue.

> 2. From my understanding (at least from the IBM documentation), if the destination is local to link (i.e. client multicast), the link's MTU is used (not the min MTU). So this still benefits client multicast and most of the communication in DHCPv6 to use the FULL link's MTU.

Sure, but in that case it just doesn't matter.

> So the only case is when the next hop (again, either relay<->relay or relay<->server or client/server unicast cases where the next-hop isn't local to the link), will the 1280 MTU be used and result in fragmentation.
> 
> I don't know who well PMTU works these days for UDP and how widely it is implemented in the common stacks. If it works great, then maybe this option is unnecessary (as the components must likely to need them are probably on 'good' stacks - relays and servers that implement PMTU).

PMTU discovery is necessary for IPv6.   If the host stack doesn't support it, it's broken and needs fixed.   I have not heard of any cases of this.   Middlebox brokenness is an issue when packets cross networks that are not controlled by the operator.   That's not the case for DHCP.   So I don't think we need to be concerned about this.   This is another difference between DHCP and DNS.

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg