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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 14 October 2010 13:07 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 A58083A6A22; Thu, 14 Oct 2010 06:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.911
X-Spam-Level:
X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=0.088, 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 Mz77RZjYy3hH; Thu, 14 Oct 2010 06:07:22 -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 F38D73A6A02; Thu, 14 Oct 2010 06:07:15 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9ED8Uej008006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Oct 2010 06:08:30 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9ED8TfB004987; Thu, 14 Oct 2010 06:08:29 -0700 (PDT)
Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9ED8T9n004961 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 14 Oct 2010 06:08:29 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Thu, 14 Oct 2010 06:08:29 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Washam Fan <washam.fan@gmail.com>
Date: Thu, 14 Oct 2010 06:08:28 -0700
Thread-Topic: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
Thread-Index: ActrnlaoTBnO5vuLTlCzyR64fhjB9AAAhkcg
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C59BDE87F@XCH-NW-01V.nw.nos.boeing.com>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com><E1829B60731D1740BB7A0 626B4FAF0A65C59B79A26@XCH-NW-01V.nw.nos.boeing.com><AANLkTimdbMHWRFAJFvahqd s5MySNnQCo2MiUBwDjqDhi@mail.gmail.com><E1829B60731D1740BB7A0626B4FAF0A65C59BDE53D@XCH-NW-01V.nw.nos.boeing.com> <AANLkTi=LqURq+_q4ftWrbeJH1SO9NbsXs6rQLuv6ejoh@mail.gmail.com>
In-Reply-To: <AANLkTi=LqURq+_q4ftWrbeJH1SO9NbsXs6rQLuv6ejoh@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: Thu, 14 Oct 2010 13:07:25 -0000

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
> >> >> >
> >> >>
> >>
>