IETF Logo Mail Archive

Re: [v6ops] discussion of transition technologies

Fred Baker <fredbaker.ietf@gmail.com> Mon, 22 January 2018 17:29 UTC

Return-Path: <fredbaker.ietf@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E92E126E64 for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 09:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 VZ_kAxEBEQ3t for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 09:29:50 -0800 (PST)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31895126CE8 for <v6ops@ietf.org>; Mon, 22 Jan 2018 09:29:50 -0800 (PST)
Received: by mail-pg0-x231.google.com with SMTP id m20so7595528pgc.11 for <v6ops@ietf.org>; Mon, 22 Jan 2018 09:29:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UYBnzPbLYxhoW8SKYPkNf1gQzd4kmTz2vwd9wMH2ACI=; b=qJZJtA1bDgwJZepKyT9X73lGo3TzwbAQZ7pMZwb7/qkoMpxruUut+DiqY8obru2bEK 2NXW3jwbnUms9JoJdnPlWAjYqEWjUYR22ebHPcbS6DkZxqI3WDlrPX3d2pc4Mv0qgAQ1 6qo5zcTMP7YexhVmRoqZGlFdH5fAEMur2LHKVgPgxaHyTdxP04ckGYuUC0vyueksgIW0 z7naHLe+rbZ8f3dG0EveMlx/SNWpCsxAPX+bOuq0+DvLKAhLkhnpsC/5Ij2wr1Kj4Gel O2bpKLw4HToaZx+Oadw15yzfqqWSaY/EfB2V4Xai7fhPiD1aVD/3AhkXekqie8Q+fAXP SiaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UYBnzPbLYxhoW8SKYPkNf1gQzd4kmTz2vwd9wMH2ACI=; b=s+/+4Tfb+00zoe52+8im+LW5t3Cg1Dg50rdKUx5GN9nSE1nvCM73a9CatdYOjeEveW jliodsfbeDX/s78wUGlByF9DuGMkEjCMwt5jr+Cd0gR20+wHeFRRReU8FAbiZ2yuj2C0 f1dMQB6I9160MBp+GWWo6mvPzo1+cuRamPikaUvPqOQk6CrvUGaDordd57dQcah0QAZc lmkbkFuGf/2YxOAFKZbastri8EXd7zP69J7YDminEJoFPOmcEC2Nl59+r/HY8gZu+Ijj MTYkZRPSs4NgsrPTs7N0/za6MvmolnwWXnktOfPbAWgRghOaJE2+c4b6BWD+ZhEBKkh0 RGAw==
X-Gm-Message-State: AKwxytcrMlesNvSnb55uNyOTYmgjhPem7FArVyuFZmw2HKkgVxcP9rn7 Qx0fc2uZasdy4yKZpLq41Mi1Tjvw
X-Google-Smtp-Source: AH8x227+UoOunyCUH3f9enJMwPekRGAkzq2es/Wgm1Zl0ZdYuSdEQW06VMSv9CwIzmoQwXb/OsM42w==
X-Received: by 2002:a17:902:1682:: with SMTP id h2-v6mr3876265plh.116.1516642189839; Mon, 22 Jan 2018 09:29:49 -0800 (PST)
Received: from [192.168.1.20] (ip184-189-218-77.sb.sd.cox.net. [184.189.218.77]) by smtp.gmail.com with ESMTPSA id c83sm1434748pfk.8.2018.01.22.09.29.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 09:29:48 -0800 (PST)
From: Fred Baker <fredbaker.ietf@gmail.com>
Message-Id: <4288F83D-F4B6-4701-9D38-2C736668489F@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_10979FD8-95F9-44EB-9287-A6CDCC4E486B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 22 Jan 2018 09:29:46 -0800
In-Reply-To: <E1F0B499-3C4B-4B80-A23E-201B1FCDBC66@jisc.ac.uk>
Cc: Sander Steffann <sander@steffann.nl>, "v6ops@ietf.org WG" <v6ops@ietf.org>
To: Tim Chown <Tim.Chown@jisc.ac.uk>
References: <D687BC24.92CC1%lee@asgard.org> <A6995969-0C03-4261-92F4-331206825130@gmail.com> <D29099E6-510D-41DA-B998-6BF15E9FDE7F@gmail.com> <2C4759D8-9B79-4380-B7F1-0E0388E63C10@steffann.nl> <E1F0B499-3C4B-4B80-A23E-201B1FCDBC66@jisc.ac.uk>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/W9CyQvn_QDNwcVqoiJdZwrGZUhA>
Subject: Re: [v6ops] discussion of transition technologies
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 22 Jan 2018 17:29:52 -0000


On Jan 22, 2018, at 2:46 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> So what translation mechanisms are you recommending "above the IP layer" ?

The one that comes quickly to mind is a load balancer that terminates one transport connection and relays data to another. It's a transport layer gateway, and so not translation in the SIIT sense of the word. It also has interesting ramifications for ICMP and so on - they don't follow the transport connection and so are invisible to it through such a gateway. The one place that seems to be a headache is with location-based or customer-based services - load balancers will often insert an http header letting the ultimate recipient know the address of its ultimate peer in the session. That, of course, has ramifications for https etc, which might be just as happy to carry the data as some form of login cookie or REST data element.

v2.23.0 | Report a Bug | By Email