Hi Sue, Thanks for your review. > On Mar 6, 2017, at 10:47 PM, Susan Hares <shares@xxxxxxxx> wrote: > > Bob: > > Thank you for your response. I'm pulling up the remaining questions to the top here. All my questions were about corner cases and "what ifs" - which is just the result of being a reviewer of a long-implemented specification. > > 1) I thought the IPv6 LAN was targeted for new mobile networks or sensor networks. If so, it may be in the future that the wireless connections would want to change the MTU on a network to increase the ability to change the MTU. If you're answer is, we'll make the timer adjustment when these technology use it in this way, this is a fine answer. The mobile and sensor networks you talk about can independently increase the MTU on the access link to which the host initiating PMTUD connects to. While this will affect the assumed initial value of the PMTU, it may or may not affect the final PMTU. If the first hop link was the link with the smallest MTU on the path, increasing it would have an effect on the PMTU. Else, it will not. > > 3) The question #4 - I was trying to determine what the interaction between the SEND with an MTU size option, and this update to RFC1918. It appears in the specification these two functions are interacting. Is this my imagination? If not, just for my own information - where do I find this in the specification. The SEND MTU option (which is the same as the ND MTU option - type 5) is used just to communicate the MTU of the local link. There is no real interaction between this and PMTUD except for the fact that the Path MTU cannot exceed this number. Thanks Suresh
<<attachment: smime.p7s>>