[apps-discuss] Review of draft-ietf-v6ops-464xlat-08
Ted Hardie <ted.ietf@gmail.com> Fri, 30 November 2012 21:14 UTC
Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27B721F8495 for <apps-discuss@ietfa.amsl.com>; Fri, 30 Nov 2012 13:14:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.113
X-Spam-Level:
X-Spam-Status: No, score=-3.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAUoDnwZfw94 for <apps-discuss@ietfa.amsl.com>; Fri, 30 Nov 2012 13:14:47 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D88F021F846F for <apps-discuss@ietf.org>; Fri, 30 Nov 2012 13:14:46 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fw7so105697vcb.31 for <apps-discuss@ietf.org>; Fri, 30 Nov 2012 13:14:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2cT3wEs9M+SV2H/L5xNN4Xl9UHKVxAnKtfAQ20TkQNY=; b=PCmI6WcBVtnnc8TDIEzTurWTB85i0WK3iQF5Vg/ex+MzRXeDTkYcNg6C7bySvymFnd zWifH3vCpV5PNmncMlRlwbcNjdp2QEJdhcE4s8TcD+qnvpgAelB6BnMCwy157OWZU+p0 7oFV/phahNGQFq0YXCL7pGi13RowrtV5ML4+ySlsLRvJGhGokAwrpKuQJLk3k2jczUMk LSzYlvoe3U3IqrGTCGkMyr3DhQA0QMXCEv/D+7Xv03Ddew7u34a29eE/1i69Y0UnVQSk GGMDJKP/Kg1+Kq5AmtglZ/wsDS6XIdi/Q+RXdRWqjR36UfAhWAKCFFOk/+XzIsbBZpcU Ovhw==
MIME-Version: 1.0
Received: by 10.52.72.132 with SMTP id d4mr1840325vdv.43.1354310086180; Fri, 30 Nov 2012 13:14:46 -0800 (PST)
Received: by 10.58.164.35 with HTTP; Fri, 30 Nov 2012 13:14:46 -0800 (PST)
Date: Fri, 30 Nov 2012 13:14:46 -0800
Message-ID: <CA+9kkMAF70_cy7wFaWBus38vy2TGfF9sOT34gM7p70iDs0gvrQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: apps-discuss@ietf.org, draft-ietf-v6ops-464xlat.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Nov 2012 21:14:47 -0000
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document:draft-ietf-v6ops-464xlat-08 Title: 464XLAT: Combination of Stateful and Stateless Translation Reviewer: Ted Hardie Review Date: November 30, 2012 Summary: This draft is not ready for publication as a BCP, and it may not be an appropriate candidate for this status. Major Issues: This document provides a v4/v6 inter-working method using a pair of address translators that bracket a network region in which there is no IPv4 routing. It discusses two different potential deployments. In the first, the first address translator is co-resident on the device where the IPv4 address is assigned; in the second, the the first address translator is resident in a nearby network device. In both, the second address translator is at the border of the internal IPv6 routing domain and a global IPv4 routing domain. The document has the following applicability statement: This BCP only applies when the following two criteria are present: 1. There is an IPv6-only network that uses stateful translation [RFC6146] as the only mechanism for providing IPv4 access. 2. There are IPv4-only applications or hosts that must communicate across the IPv6-only network to reach the IPv4 Internet. The first item is problematic. This document describes a method for using stateful translation, but it does not justify why this is the appropriate choice; the encapsulation methods used in something like DS-Lite seem to be an alternative here, and it is not clear either what constraint prevents encapsulation's use in these networks or what the advantage is here to using dual translation over an encapsulation-based method. In other words, this appears circular--it defines it as a best practice for networks using stateful translation, rather than defining when stateful translation is best practice. The document also says this in the introduction, which provides an additional applicability limitation: The 464XLAT architecture only supports IPv4 in the client server model, where the server has a global IPv4 address. This means it is not fit for IPv4 peer-to-peer communication or inbound IPv4 connections If this is true, it is highly problematic, because it provides a constraint on the semantics of an RFC 1918 address that is not currently present. It is not entirely clear, though, that this is true. Systems attempting peer-to-peer communication when using RFC 1918 addresses typically must use ICE to handle the artifacts of network address translation. I was not able to understand how ICE would fail here, either in the case where the CLAT was resident on the node or when it is network resident. In my naive reading, this would work for cases where the ICE server was in the IPv4 global routing domain. Because PLATs are provisioned with a single IP address, the mapped address attribute would always have the same family and address, but it seems it should be distinguishable by port. If this is not the case, or there is a different reason why this mechanism cannot work with ICE, I believe it should be called out in the draft explicitly. An ICE-based peer-to-peer connection would, certainly, provide a severely sub-optimal path for two devices within the same 464xlat region, as it would hairpin out and back. But those are not the only potential peer-to-peer connections and it would work at least to some degree. In the case where the CLAT is resident on a device, but that device provides tethering, the document currently says: The CLAT SHOULD perform router function to facilitate packets forwarding through the stateless translation even if it is an end-node. For proper operation of tethered devices, this would appear to require a MUST, rather than a SHOULD. If it is not MUST, then some description of what will happen is desirable. (Perhaps a statement that CLATs which do not provide this functionality cannot be used when tethering is in place or whether tethered devices require IPv4?) Minor Issues: This draft is currently targeted for BCP. I do not believe that it is appropriate to target it for BCP unless it is preferred over encapsulation-based approaches. I also believe that the marketing material which is currently embedded in the text (see, for example, section 5) should be removed. Nits: The description 3GPP applicability relates to 3GPP "Pre-Release 9", but there is no citation given. I also note that 3GPP specifications currently appear to be on release 12, and there is no notice of whether changes between pre-release 9 and the current release have changed the topology in a way to eliminate the multiple PDP issue raised. If the text means to say that this is not a problem for any version 9 or later, and that the problem exists for any version prior to 9 which supports multiple address families, it needs to be reworded.
- [apps-discuss] Review of draft-ietf-v6ops-464xlat… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-v6ops-464… Byrne, Cameron
- Re: [apps-discuss] Review of draft-ietf-v6ops-464… Cameron Byrne
- Re: [apps-discuss] Review of draft-ietf-v6ops-464… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-v6ops-464… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-v6ops-464… Cameron Byrne
- Re: [apps-discuss] Review of draft-ietf-v6ops-464… Cameron Byrne
- Re: [apps-discuss] Review of draft-ietf-v6ops-464… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-v6ops-464… Cameron Byrne
- [apps-discuss] Other parts of the stack (was: Rev… SM
- Re: [apps-discuss] Other parts of the stack (was:… Claudio Allocchio