Hi Sue,
Thanks for your review.
On Mar 6, 2017, at 10:47 PM, Susan Hares <shares(_at_)ndzh(_dot_)com> 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
smime.p7s
Description: S/MIME cryptographic signature