Hi Mark, > -----Original Message----- > From: Mark Townsley [mailto:[email protected]] > Sent: Friday, January 17, 2014 12:41 AM > To: Mikael Abrahamsson > Cc: Templin, Fred L; [email protected] > Subject: Re: MTU handling in 6RD deployments > > > On Jan 17, 2014, at 9:24 AM, Mikael Abrahamsson wrote: > > > On Thu, 16 Jan 2014, Templin, Fred L wrote: > > > >> The key is that we want to probe the path between the BR and CE (in both > >> directions) *before* > allowing regular data packets to flow. We want to know ahead of time whether > to allow large packets > into the tunnel or whether we need to shut the MTU down to 1480 (or 1472 or > something) and clamp the > MSS. Because, once we restrict the tunnel MTU hosts will be stuck with a > degenerate MTU indefinitely > or at least for a long time. > > > > This method makes some sense, but since network conditions can change, I > > would like to see periodic > re-checks of the tunnel still working with the packet sizes, perhaps pinging > itself over the tunnel > once per minute with the larger packet size if larger packet size is in use. > > Section 8 of RFC 5969 could be relevant here.
In that section, I see: "The link-local address of a 6rd virtual interface performing the 6rd encapsulation would, if needed, be formed as described in Section 3.7 of [RFC4213]. However, no communication using link-local addresses will occur." So, if we were to construct the pings from the IPv6 level we would want to use link-local source and destination addresses. But, that raises a question that would need to be addressed - should the pings be constructed at the IPv6 level, the IPv4 level, or some mid-level like SEAL? One other thing about this is that we are specifically not testing to determine an exact path MTU. We are only trying to answer the binary question of whether or not the tunnel can pass a 1500 byte IPv6 packet. Thanks - Fred [email protected] > - Mark > > > > > -- > > Mikael Abrahamsson email: [email protected]
