Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 12 October 2010 02:57 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D363A68AB; Mon, 11 Oct 2010 19:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Level:
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGT6sw6rcSov; Mon, 11 Oct 2010 19:57:25 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 4F3103A68AF; Mon, 11 Oct 2010 19:57:25 -0700 (PDT)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9C2wSMZ027823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Oct 2010 19:58:28 -0700 (PDT)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9C2wRNv018221; Mon, 11 Oct 2010 19:58:27 -0700 (PDT)
Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9C2wRuM018218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 11 Oct 2010 19:58:27 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 11 Oct 2010 19:58:27 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Washam Fan <washam.fan@gmail.com>
Date: Mon, 11 Oct 2010 19:58:25 -0700
Thread-Topic: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
Thread-Index: ActptmxwHc9uaM77QeW0dNkamqI71QAAFxpA
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C59B79A26@XCH-NW-01V.nw.nos.boeing.com>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com><E1829B60731D1740BB7A0 626B4FAF0A65C59B79387@XCH-NW-01V.nw.nos.boeing.com><E1829B60731D1740BB7A062 6B4FAF0A65C59B79491@XCH-NW-01V.nw.nos.boeing.com><AANLkTik0_9CRSfi_O53MChgt 5QH+-=aR8HO7v+fHiLwY@mail.gmail.com><D8BB9123-C611-4476-AFA1-D0ADEEDB6270@f ree.fr><E1829B60731D1740BB7A0626B4FAF0A65C59B797F3@XCH-NW-01V.nw.nos.boeing .com><279A3292-A291-4BC0-8FCF-53120066931E@free.fr><E1829B60731D1740BB7A0626B4FAF0A65C59B7982A@XCH-NW-01V.nw.nos.boeing.com> <AANLkTimqUL4qADuguJVBCCnTCyaNxgVSbU41ZvGQPZ4d@mail.gmail.com>
In-Reply-To: <AANLkTimqUL4qADuguJVBCCnTCyaNxgVSbU41ZvGQPZ4d@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Softwires <softwires@ietf.org>, "v4tov6transition@ietf.org" <v4tov6transition@ietf.org>
Subject: Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2010 02:57:26 -0000

Hi Washam, 

> -----Original Message-----
> From: Washam Fan [mailto:washam.fan@gmail.com] 
> Sent: Monday, October 11, 2010 7:38 PM
> To: Templin, Fred L
> Cc: Rémi Després; Softwires; v4tov6transition@ietf.org
> Subject: Re: [v4tov6transition] IPv6 VPNs configured over 
> 1280 MTU tunnels
> 
> Hi,
> 
> If 6a44 deployed in a managed ISP network, the 6a44 client could be
> configured with IPv4_MTU-28 for its IPv6 MTU.

My understanding is that the 6a44 server is in the managed
ISP network, and the 6a44 client is in the UNmanaged end
user network.

> For inbound direction,
> 6a44 server would reject any IPv6 packets whose size exceeds
> IPv4_MTU-28 with a ICMPv6 PTB message, so no ICMPv6-ICMPv4 translation
> needed.

Huh? How does the server have any idea what MTU the client
set on its tunnel interface? The client is behind a NAT in
an unmanaged end user network. Are you expecting the server
to probe the path MTU to the client and maintain state? (An
IRON server might be in position to do something like that,
but I was assuming the 6a44 server would be stateless, right?) 

> For outbound direction, 6a44 server would encapsulate any
> ICMPv6 PTB messages it received in UDP in IPv4, and then forward to
> the 6a44 client, so no NAT filtering worried.

Correct, but no one has suggested an MTU problem for what
happens to IPv6 packets *beyond* the tunnel; we are only
discussing the case of MTU issues *within* the tunnel.

Fred
fred.l.templin@boeing.com

> Thanks,
> washam
> 
> 2010/10/12 Templin, Fred L <Fred.L.Templin@boeing.com>om>:
> > Remi,
> >
> >> -----Original Message-----
> >> From: Rémi Després [mailto:remi.despres@free.fr]
> >> Sent: Monday, October 11, 2010 10:05 AM
> >> To: Templin, Fred L
> >> Cc: Washam Fan; Softwires; v4tov6transition@ietf.org
> >> Subject: Re: [v4tov6transition] IPv6 VPNs configured over
> >> 1280 MTU tunnels
> >>
> >>
> >> Le 11 oct. 2010 à 18:42, Templin, Fred L a écrit :
> >>
> >> >> ...
> >> >> Actually, the 6a44 specification should, instead of 1280,
> >> >> require IPv4 MTU - 28 octets, both for hairpinning and
> >> >> traversal cases.
> >> >
> >> > How can you be sure that IPv4 PMTUD will work in
> >> > the traversal case?
> >>
> >> 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.
> >
> >> In the from host direction, one can't be sure, but doesnt' need to.
> >> If a smaller PMTU is encountered further downstream, a PTB
> >> ICMPv6 error message will be returned from there.
> >
> > In the from-host direction, any ICMPv4 returned from
> > the ISP network might not be delivered to the tunnel
> > endpoint due to NAT filtering, and might not have
> > enough information for stateless translation to ICMPv6.
> >
> > Fred
> > fred.l.templin@boeing.com
> >
> >> RD
> >
>