Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 13 October 2010 15:04 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 E92183A6AC4; Wed, 13 Oct 2010 08:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.100, 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 QUVMSRn61h6E; Wed, 13 Oct 2010 08:04:22 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 590F63A696F; Wed, 13 Oct 2010 08:04:22 -0700 (PDT)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9DF5X7Q004540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Oct 2010 08:05:34 -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 o9DF5X9B024603; Wed, 13 Oct 2010 08:05:33 -0700 (PDT)
Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9DF5WZv024485 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 13 Oct 2010 08:05:32 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 13 Oct 2010 08:05:32 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Washam Fan <washam.fan@gmail.com>
Date: Wed, 13 Oct 2010 08:05:30 -0700
Thread-Topic: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
Thread-Index: Actp0RmZK2mjP1ZDSImEWM3vqVmxrQAhKcOA
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C59BDE53D@XCH-NW-01V.nw.nos.boeing.com>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com><279A3292-A291-4BC0-8F CF-53120066931E@free.fr><E1829B60731D1740BB7A0626B4FAF0A65C59B7982A@XCH-NW- 01V.nw.nos.boeing.com><AANLkTimqUL4qADuguJVBCCnTCyaNxgVSbU41ZvGQPZ4d@mail.g mail.com><E1829B60731D1740BB7A0626B4FAF0A65C59B79A26@XCH-NW-01V.nw.nos.boeing.com> <AANLkTimdbMHWRFAJFvahqds5MySNnQCo2MiUBwDjqDhi@mail.gmail.com>
In-Reply-To: <AANLkTimdbMHWRFAJFvahqds5MySNnQCo2MiUBwDjqDhi@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: Wed, 13 Oct 2010 15:04:25 -0000
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. > 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. Second, how does H discover SP_MTU; by engaging in an initial probing by sending large packets and getting a PTB message back? Again, this won't give a deterministic SP_MTU value if S is replicated across paths with varying PMTUs. > 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? > 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. > 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>: > > 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>: > >> > 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] ISP support of Native IPv6 acr… Rémi Després
- Re: [v4tov6transition] [Softwires] ISP support of… Brian E Carpenter
- Re: [v4tov6transition] [Softwires] ISP support of… Ole Troan
- Re: [v4tov6transition] [Softwires] ISP support of… Brian E Carpenter
- Re: [v4tov6transition] [Softwires] ISP support of… Templin, Fred L
- Re: [v4tov6transition] [Softwires] ISP support of… Yiu L. Lee
- Re: [v4tov6transition] [Softwires] ISP support of… Yiu L. Lee
- Re: [v4tov6transition] [Softwires] ISP support of… Rémi Després
- Re: [v4tov6transition] [Softwires] ISP support of… Ole Troan
- Re: [v4tov6transition] [Softwires] ISP support of… Yiu L. Lee
- Re: [v4tov6transition] [Softwires] ISP support of… Rémi Després
- Re: [v4tov6transition] [Softwires] ISP support of… Rémi Després
- Re: [v4tov6transition] [Softwires] ISP support of… Templin, Fred L
- Re: [v4tov6transition] [Softwires] ISP support of… Ole Troan
- Re: [v4tov6transition] [Softwires] ISP support of… Brian E Carpenter
- Re: [v4tov6transition] [Softwires] ISP support of… Brian E Carpenter
- Re: [v4tov6transition] [Softwires] ISP support of… Brian E Carpenter
- Re: [v4tov6transition] [Softwires] ISP support of… Olivier Vautrin
- Re: [v4tov6transition] [Softwires] ISP support of… Cameron Byrne
- Re: [v4tov6transition] [Softwires] ISP support of… Ed Jankiewicz
- Re: [v4tov6transition] [Softwires] ISP support of… Rémi Després
- Re: [v4tov6transition] [Softwires] ISP support of… Ole Troan
- Re: [v4tov6transition] [Softwires] ISP support of… Rémi Després
- Re: [v4tov6transition] [Softwires] ISP support of… Templin, Fred L
- [v4tov6transition] IPv6 VPNs configured over 1280… Templin, Fred L
- Re: [v4tov6transition] IPv6 VPNs configured over … Templin, Fred L
- Re: [v4tov6transition] [Softwires] ISP support of… Yiu L. Lee
- Re: [v4tov6transition] [Softwires] ISP support of… Templin, Fred L
- Re: [v4tov6transition] [Softwires] ISP support of… Yiu L. Lee
- Re: [v4tov6transition] [Softwires] ISP support of… Templin, Fred L
- Re: [v4tov6transition] [Softwires] ISP support of… Yiu L. Lee
- Re: [v4tov6transition] IPv6 VPNs configured over … Washam Fan
- Re: [v4tov6transition] ISP support of Native IPv6… Tina TSOU
- Re: [v4tov6transition] ISP support of Native IPv6… Brian E Carpenter
- Re: [v4tov6transition] IPv6 VPNs configured over … Templin, Fred L
- Re: [v4tov6transition] IPv6 VPNs configured over … Rémi Després
- Re: [v4tov6transition] IPv6 VPNs configured over … Templin, Fred L
- Re: [v4tov6transition] IPv6 VPNs configured over … Rémi Després
- Re: [v4tov6transition] IPv6 VPNs configured over … Templin, Fred L
- Re: [v4tov6transition] [Softwires] IPv6 VPNs conf… Templin, Fred L
- Re: [v4tov6transition] [Softwires] IPv6 VPNs conf… Brian E Carpenter
- Re: [v4tov6transition] [Softwires] IPv6 VPNs conf… Templin, Fred L
- Re: [v4tov6transition] IPv6 VPNs configured over … Washam Fan
- Re: [v4tov6transition] IPv6 VPNs configured over … Templin, Fred L
- Re: [v4tov6transition] IPv6 VPNs configured over … Washam Fan
- Re: [v4tov6transition] [Softwires] 6a44 MTU issues Rémi Després
- Re: [v4tov6transition] IPv6 VPNs configured over … Templin, Fred L
- Re: [v4tov6transition] [Softwires] 6a44 MTU issues Templin, Fred L
- Re: [v4tov6transition] [Softwires] 6a44 MTU issues Rémi Després
- Re: [v4tov6transition] [Softwires] 6a44 MTU issues Templin, Fred L
- Re: [v4tov6transition] [Softwires] 6a44 MTU issues Rémi Després
- Re: [v4tov6transition] IPv6 VPNs configured over … Washam Fan
- Re: [v4tov6transition] [Softwires] 6a44 MTU issues Templin, Fred L
- Re: [v4tov6transition] IPv6 VPNs configured over … Templin, Fred L
- Re: [v4tov6transition] IPv6 VPNs configured over … Brian E Carpenter
- Re: [v4tov6transition] IPv6 VPNs configured over … Templin, Fred L