Re: [v6ops] Operational Consensus on deployment

Vízdal Aleš <ales.vizdal@t-mobile.cz> Wed, 06 August 2014 14:54 UTC

Return-Path: <ales.vizdal@t-mobile.cz>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FCC1B2A4A for <v6ops@ietfa.amsl.com>; Wed, 6 Aug 2014 07:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level:
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU4zl-exwN5r for <v6ops@ietfa.amsl.com>; Wed, 6 Aug 2014 07:54:00 -0700 (PDT)
Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8551B2D61 for <v6ops@ietf.org>; Wed, 6 Aug 2014 07:53:47 -0700 (PDT)
From: Vízdal Aleš <ales.vizdal@t-mobile.cz>
To: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>, Gert Doering <gert@space.net>
Thread-Topic: [v6ops] Operational Consensus on deployment
Thread-Index: AQHPsYTdKp4cYlfWs0iK+WcgE96R8pvDqCcQ
Date: Wed, 06 Aug 2014 14:53:44 +0000
Message-ID: <9d8382d1b10f482f81fd26c6e31e602d@srvhk403.rdm.cz>
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no> <m1XEy8M-0000AXC@stereo.hq.phicoh.net> <20140806123243.GU51793@Space.Net> <m1XF2Rg-0000BRC@stereo.hq.phicoh.net>
In-Reply-To: <m1XF2Rg-0000BRC@stereo.hq.phicoh.net>
Accept-Language: en-GB, cs-CZ, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.254.57.29]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Loop: 2
X-CFilter-Loop: Forwarded
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nxU8KIlSX1p1VEe-tcbG1qQCCaw
Cc: IPv6 Ops WG <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
Subject: Re: [v6ops] Operational Consensus on deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 14:54:03 -0000

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of
> Philip Homburg
> Sent: Wednesday, August 06, 2014 4:44 PM
> To: Gert Doering
> Cc: IPv6 Ops WG; Tore Anderson
> Subject: Re: [v6ops] Operational Consensus on deployment
>
> In your letter dated Wed, 6 Aug 2014 14:32:43 +0200 you
> wrote:
> >Why do you find it so hard to accept that "dual-stack
> inside" is not a
> >desirable property?
>
> I find that very easy to accept. Except that from my point of
> view the proposals presented to avoid dual stack are worse.
>
> The way I see it, translating IPv4 into IPv6 is just going to
> bite you.
>
> Now, tunneling IPv4 over IPv6 may work, if the tunneling is
> local and if the tunnel preserves a 1500 octet MTU for IPv4.

I guess you're talking about a softwire, so let me cite RFC5565:

   Transmitting a packet through a softwire always requires that an
   encapsulation header be added to the original packet.  The resulting
   packet is therefore always longer than the encapsulation payload.  As
   an operational matter, the Maximum Transmission Unit (MTU) of the
   softwire's path SHOULD be large enough so that (a) no packet will
   need to be fragmented before being encapsulated, and (b) no
   encapsulated packet will need to be fragmented while it is being
   forwarded along a softwire.  A general discussion of MTU issues in
   the context of tunneled forwarding may be found in [RFC4459].

> At the end of the day, all externally visible stuff still has
> to have IPv4.
> That is dual stack, no matter how you slice it.

I think that Tore's work is showing that there are alternatives to dual-stack.

Ales

Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde  http://www.t-mobile.cz/zasady. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here http://www.t-mobile.cz/principles. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer.