-Original Message-
From: Washam Fan [mailto:washam@gmail.com]
Sent: Friday, October 08, 2010 8:02 PM
To: Templin, Fred L
Cc: Softwires; v4tov6transit...@ietf.org
Subject: Re: [v4tov6transition] IPv6 VPNs configured over
1280 MTU tunnels
Hi,
2010/10/9 Templin, Fred L
-Original Message-
From: Rémi Després [mailto:remi.desp...@free.fr]
Sent: Monday, October 11, 2010 9:29 AM
To: Washam Fan; Templin, Fred L
Cc: Softwires; v4tov6transit...@ietf.org
Subject: Re: [v4tov6transition] IPv6 VPNs configured over
1280 MTU tunnels
Hi Washam and Fred,
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,
Remi,
-Original Message-
From: Rémi Després [mailto:remi.desp...@free.fr]
Sent: Monday, October 11, 2010 10:05 AM
To: Templin, Fred L
Cc: Washam Fan; Softwires; v4tov6transit...@ietf.org
Subject: Re: [v4tov6transition] IPv6 VPNs configured over
1280 MTU tunnels
Le 11 oct.
(Adding dhc WG chairs to the thread.)
The client behavior in draft-ietf-softwire-ds-lite-tunnel-option-04 did not
describe any mechanism in which the client would combine the FQDN from the
tunnel option with a suffix in the search list option to form a new name to use
as its AFTR, nor did it
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
Hi Brian,
-Original Message-
From: softwires-boun...@ietf.org
[mailto:softwires-boun...@ietf.org] On Behalf Of Brian E Carpenter
Sent: Monday, October 11, 2010 2:26 PM
To: Templin, Fred L
Cc: Softwires; v4tov6transit...@ietf.org
Subject: Re: [Softwires] [v4tov6transition] IPv6
Hi,
If 6a44 deployed in a managed ISP network, the 6a44 client could be
configured with IPv4_MTU-28 for its IPv6 MTU. 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. For outbound
Hi Washam,
-Original Message-
From: Washam Fan [mailto:washam@gmail.com]
Sent: Monday, October 11, 2010 7:38 PM
To: Templin, Fred L
Cc: Rémi Després; Softwires; v4tov6transit...@ietf.org
Subject: Re: [v4tov6transition] IPv6 VPNs configured over
1280 MTU tunnels
Hi,
If
Dear Raplh,
Do you suggest the I-D should elaborate further on the FQDN use cases so this
to be acceptable by the IESG?
Chairs, how should we proceed? The version which passed the WG LC is not the
05.
Cheers,
Med
-Message d'origine-
De : softwires-boun...@ietf.org
Hi Fred,
I might see your points.
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
11 matches
Mail list logo
