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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 15 October 2010 12:55 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 08EFE3A6A94; Fri, 15 Oct 2010 05:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.912
X-Spam-Level:
X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 HNbzphadvCeU; Fri, 15 Oct 2010 05:55:29 -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 A48113A69A4; Fri, 15 Oct 2010 05:55:29 -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 o9FCum2l024810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Oct 2010 05:56:48 -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 o9FCul64016184; Fri, 15 Oct 2010 05:56:47 -0700 (PDT)
Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9FCul6G016179 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 15 Oct 2010 05:56:47 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 15 Oct 2010 05:56:47 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Date: Fri, 15 Oct 2010 05:56:46 -0700
Thread-Topic: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
Thread-Index: Actr7JAyi51DqG1JSNKI+Jdm3AOTTgAe5tQg
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C59BDEBF8@XCH-NW-01V.nw.nos.boeing.com>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com><E1829B60731D1740BB7A0 626B4FAF0A65C59B79A26@XCH-NW-01V.nw.nos.boeing.com><AANLkTimdbMHWRFAJFvahq d s5MySNnQCo2MiUBwDjqDhi@mail.gmail.com><E1829B60731D1740BB7A0626B4FAF0A65C 59BDE53D@XCH-NW-01V.nw.nos.boeing.com> <AANLkTi=LqURq+_q4ftWrbeJH1SO9NbsXs6 rQLuv6ejoh@mail.gmail.com><E1829B60731D1740BB7A0626B4FAF0A65C59BDE87F@XCH-NW-01V.nw.nos.boeing.com> <4CB77FAA.6090901@gmail.com>
In-Reply-To: <4CB77FAA.6090901@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: Fri, 15 Oct 2010 12:55:31 -0000

Hi Brian, 

> -----Original Message-----
> From: v4tov6transition-bounces@ietf.org 
> [mailto:v4tov6transition-bounces@ietf.org] On Behalf Of Brian 
> E Carpenter
> Sent: Thursday, October 14, 2010 3:10 PM
> To: Templin, Fred L
> Cc: Softwires; v4tov6transition@ietf.org
> Subject: Re: [v4tov6transition] IPv6 VPNs configured over 
> 1280 MTU tunnels
> 
> Fred,
> 
> > All of your assumptions are lowest-common-denominator.
> 
> What else can an operator safely do but make such assumptions?

They can roll up their sleeves and probe the paths to
the clients.

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

> Regards
>    Brian
> 
> On 2010-10-15 02:08, Templin, Fred L wrote:
> > Hi Washam, 
> > 
> >> -----Original Message-----
> >> From: Washam Fan [mailto:washam.fan@gmail.com] 
> >> Sent: Thursday, October 14, 2010 5:50 AM
> >> To: Templin, Fred L
> >> Cc: Rémi Després; Softwires; v4tov6transition@ietf.org
> >> Subject: Re: [v4tov6transition] IPv6 VPNs configured over 
> >> 1280 MTU tunnels
> >>
> >> Hi Fred,
> >>
> >> Please see inline. I did have some different assumptions. And those
> >> assumptions might be wrong. It might be better at this stage we let
> >> the tunneled IPv6 MTU be 1280 and tunneling IPv4 MTU not less than
> >> 1308.
> > 
> > All of your assumptions are lowest-common-denominator.
> > All end user networks are made to suffer because of the
> > few that are poorly configured. GigE is a current day
> > reality, and MTUs much larger than the lowest common
> > denominator should be made available to the end user
> > networks that paid good money for them when possible.
> > 
> > Fred
> > fred.l.templin@boeing.com
> > 
> >> 2010/10/13 Templin, Fred L <Fred.L.Templin@boeing.com>om>:
> >>> Hi Washam,
> >>>
> >>>> -----Original Message-----
> >>>> From: Washam Fan [mailto:washam.fan@gmail.com]
> >>>> Sent: Monday, October 11, 2010 10:48 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 Fred,
> >>>>
> >>>> I might see your points.
> >>> Good.
> >>>
> >>>> Let H represents Host, N represents NAT, S represents the 6a44
> >>>> servers. PMTU(H,S) stands for the PMTU between H and S. HOME_MTU
> >>>> represents MTU within home LAN (i.e., unmanaged network), SP_MTU
> >>>> represents MTU within SP network(i.e., managed network). 
> We assume
> >>>> both SP_MTU and SP_MTU should exceed or equal to 1308.
> >>> This is an incomplete characterization. PMTU is not
> >>> necessarily symmetric, e.g., even just within the end
> >>> user it could be different in the H->N direction than
> >>> in the N->H direction. Also, there could be multiple N's
> >>> in the path; each imparting their own MTU uncertainties.
> >> I assume H->N->S PMTU can be probed, Ns in between should 
> be capable
> >> of translating ICMPv4 messages appropriately. As you said, 
> S->N->H can
> >> not be probed as Ss are stateless.
> >>
> >>>> if HOME_MTU>=SP_MTU, PMTU(H,S)=SP_MTU, the H could 
> >> configure SP_MTU-28
> >>>> as the IPv6 virtual interface MTU.
> >>> A couple of things here. First, you seem to be assuming a
> >>> static S instead of a redundantly replicated S with anycast,
> >>> where there may be many distinct paths with varing SP_MTUs to
> >>> reach the multiple S's.
> >> I assume all Ss shared the same MTUs since they are 
> located in managed
> >> networks. Or the MTU on their interfaces attaching SP 
> networks can be
> >> configured with the least IPv4 MTU value.
> >>
> >>> Second, how does H discover SP_MTU;
> >>> by engaging in an initial probing by sending large packets
> >>> and getting a PTB message back?
> >> I assume H can discover PMTU traversing Ns in between.
> >>
> >>> Again, this won't give a
> >>> deterministic SP_MTU value if  S is replicated across paths
> >>> with varying PMTUs.
> >> I assume all Ss configured with the same MTUs on their interfaces
> >> attaching to SP networks.
> >>
> >>>> H->S direction: if S received or trigger any ICMPv6 PTB 
> >> messages, it
> >>>> can forward ICMPv6-in-UDP-in-IPv4 to H.
> >>> You keep saying this, and I keep saying that you are right
> >>> but that this has never been a matter for concern. PMTUD
> >>> *beyond* the tunnel is not in question; it is only PMTUD
> >>> *within* the tunnel that bears further discussion.
> >>>
> >>>> S->H direction: S would reject any IPv6 packets 
> exceeding SP_MTU-28
> >>>> with ICMPv6 PTB.
> >>>> I don't see problems here.
> >>> Huh? Is S supposed to cache the SP_MTU to each and every
> >>> potential host H? I assume the goal is for a completely
> >>> stateless S - right?
> >> I assume MTU is statically configured on Ss' interfaces 
> attaching the
> >> SP networks.
> >>
> >>>> If HOME_MTU<SP_MTU,PMTU(H,S)=HOME_MTU, the H could configure
> >>>> HOME_MTU-28 as IPv6 virtual interface MTU.
> >>> So again, H could discover this only by sending probes?
> >>> And again, any probing would be non-deterministic if S
> >>> is an anycast (and not unicast) address.
> >> See above.
> >>
> >> Thanks,
> >> washam
> >>
> >>>> H->S direction: if S received or trigger any ICMPv6 PTB 
> >> messages, it
> >>>> can forward ICMPv6-in-UDP-in-IPv4 to H.
> >>> Yes, we have confirmed this several times now; not
> >>> a point in question.
> >>>
> >>>> I don't expect the size of the encapsulated packet is too much.
> >>> Encapsulated PTB could be as big as 1280 + 20 + 8.
> >>>
> >>>> S->H direction: if S forward some IPv6 packets whose size 
> >> is between
> >>>> HOME_MTU-28 and SP_MTU-28, N might trigger a ICMPv4 PTB or 
> >> filtering
> >>>> them. For the former, S might don't have enough info to 
> infer which
> >>>> IPv6 original packet it is related,
> >>> Right.
> >>>
> >>>> for the latter, black hole might occur. I see problems here.
> >>> Right.
> >>>
> >>> Fred
> >>> fred.l.templin@boeing.com
> >>>
> >>>> Thanks,
> >>>> washam
> >>>>
> >>>> 2010/10/12 Templin, Fred L <Fred.L.Templin@boeing.com>om>:
> >>>>> 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
> > _______________________________________________
> > v4tov6transition mailing list
> > v4tov6transition@ietf.org
> > https://www.ietf.org/mailman/listinfo/v4tov6transition
> > 
> 
> _______________________________________________
> v4tov6transition mailing list
> v4tov6transition@ietf.org
> https://www.ietf.org/mailman/listinfo/v4tov6transition
>