Re: [v4tov6transition] [Softwires] IPv6 VPNs configured over1280MTU tunnels

"Templin, Fred L" <> Mon, 11 October 2010 23:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E0B03A6B98; Mon, 11 Oct 2010 16:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.188
X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XD3r60GaZCFl; Mon, 11 Oct 2010 16:18:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0A9B03A6B9F; Mon, 11 Oct 2010 16:18:23 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9BNJYfR017828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Oct 2010 16:19:35 -0700 (PDT)
Received: from (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9BNJYxk024046; Mon, 11 Oct 2010 16:19:34 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9BNJYZ2024036 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 11 Oct 2010 16:19:34 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Mon, 11 Oct 2010 16:19:33 -0700
From: "Templin, Fred L" <>
To: Brian E Carpenter <>
Date: Mon, 11 Oct 2010 16:19:32 -0700
Thread-Topic: [Softwires] [v4tov6transition] IPv6 VPNs configured over1280MTU tunnels
Thread-Index: Actpi3vgzbSkzi0YRHSOi7gCI3/7DwAAYWlg
Message-ID: <>
References: <><E1829B60731D1740BB7A0><E1829B60731D1740BB7A06 2><AANLkTik0_9CRSfi_O53MCh gt><D8BB9123-C611-4476-AFA1-D0ADEEDB627 0@f>< eing .com><> <E1829B60731D1740B><E1829B60731D1740BB7> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Softwires <>, "" <>
Subject: Re: [v4tov6transition] [Softwires] IPv6 VPNs configured over1280MTU tunnels
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Oct 2010 23:18:24 -0000

Hi Brian, 

> -----Original Message-----
> From: 
> [] On Behalf Of Brian E Carpenter
> Sent: Monday, October 11, 2010 2:26 PM
> To: Templin, Fred L
> Cc: Softwires;
> Subject: Re: [Softwires] [v4tov6transition] IPv6 VPNs 
> configured over1280MTU tunnels
> Fred
> On 2010-10-12 07:23, Templin, Fred L wrote:
> >>> In the to-host direction, because the ISP network is all what 
> >>> is left to traverse before reaching the CPE.
> >> In what you call the to-host direction, any ICMPv4
> >> returned from the ISP network might not have enough
> >> information for stateless translation to ICMPv6.
> > 
> > I should also say, any ICMPv4 returned from within
> > the end user network (where MTUs might not be so well
> > managed) might not be delivered to the tunnel endpoint
> > in the ISP network.
> Well, yes, and there were several years when I frequently found myself
> in hotel rooms having to manually set the IPv4 MTU on my laptop to a
> low value, when connecting through broken dial-up ISPs. No doubt
> we'll also go through some years before all operators are providing
> an adequately large MTU to cope with IPv6-in-foo tunnels. I don't
> think any transition solution can hope to be 100% watertight
> on this.

IROM (vis-a-vis SEAL) is striving for a true tunnel MTU
solution and I think has made significant strides. The
SEAL approach is dissimilar from IPv4 PMTUD in that it
is the tunnel far end (and not a router on the path) that
returns the PTB message. SEAL relies on routers in the path
correctly implementing IPv4 fragmentation, which is a
required behavior even for tunnel paths that traverse
untrusted/unmanaged domains.

SEAL's only requirement is that the IPv4 first fragment of a
fragmented IPv4 datagram contain at least enough information
to include a tunnel identifier. The minimum size for a first
fragment is 8 bytes beyond the IP header, since the fragment
offset field counts the number of 8 byte blocks. Common
operational practices also suggest that routers tend to make
the first fragment be approximately MTU-sized since this may
be useful to allow the destination to measure the path MTU.
There is also enough uncertainty about tiny fragment attacks
(RFC1858, RFC3128, etc.) that it seems highly unlikely that
the first fragment of a multi-fragment IPv4 datagram would
contain less than 16 bytes (UDP header plus enough extra to
contain a tunnel ID). 

> We'll make the changes that Rémi mentioned, but
> you're correct that IPv6-in6a44 tunnels might have MTU issues.

Please have a look at my tunnel MTU guy when deciding how
to set the static MTU configuration knob:

The term "configuration knob" came from RFC4213, which
also has an analysis of setting a static MTU that may
be helpful. But, remember that VPNs configured over
paths containing IPv6-in-IPv4 tunnels will need more
headroom, so 1280 seems insufficient.

Thanks - Fred

>     Brian
> _______________________________________________
> Softwires mailing list