MTU handling in 6RD deployments

[Templin, Fred L]

Hi Mark,

> -----Original Message-----
> From: ipv6-ops-bounces+fred.l.templin=boeing.com at lists.cluenet.de [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing.com at lists.cluenet.de] On Behalf Of Templin, Fred L
> Sent: Friday, January 17, 2014 7:57 AM
> To: Mark Townsley; Mikael Abrahamsson
> Cc: ipv6-ops at lists.cluenet.de
> Subject: RE: MTU handling in 6RD deployments
> 
> Hi Mark,
> 
> > -----Original Message-----
> > From: Mark Townsley [mailto:mark at townsley.net]
> > Sent: Friday, January 17, 2014 12:41 AM
> > To: Mikael Abrahamsson
> > Cc: Templin, Fred L; ipv6-ops at lists.cluenet.de
> > 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."

Sorry, I was looking at the wrong section. I see now that Section 8
is talking about a method for a CE to send an ordinary data packet
that loops back via the BR. That method is fine, but it is no more
immune to someone abusing the mechanism than would be sending a ping
(or some other NUD message). By using a ping, the BR can impose
rate-limiting on its ping responses whereas with a looped-back
data packet the BR really can't do rate limiting.

Also, Section 8 of RFC5969 only talks about the CE testing the forward
path to the BR. Unless the BR also tests the reverse path to the CE it
has no way of knowing whether the CE can accept large packets. 

Thanks - Fred
fred.l.templin at boeing.com

> 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
> fred.l.templin at boeing.com
> 
> > - Mark
> >
> > >
> > > --
> > > Mikael Abrahamsson    email: swmike at swm.pp.se