Re: [v6ops] draft-ietf-v6ops-ipv6-cpe-router-bis
John Gammons <jgammons@gmail.com> Fri, 01 July 2011 15:44 UTC
Return-Path: <jgammons@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 AE60E11E80D1 for <v6ops@ietfa.amsl.com>; Fri, 1 Jul 2011 08:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 ZMf3a4F9Qi9K for <v6ops@ietfa.amsl.com>; Fri, 1 Jul 2011 08:44:26 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B993C11E80B6 for <v6ops@ietf.org>; Fri, 1 Jul 2011 08:44:25 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2749365qwc.31 for <v6ops@ietf.org>; Fri, 01 Jul 2011 08:44:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=4f36s3QCS5Cos4Fvmv7bJHuAGiFdzT0aXX6tFGn8U+M=; b=sknc53WZ+71nP0ya2XscZB9yE+aCXKNQPTNRJGi81Gon6FfEikEVMh351aoIdJ5tIF aOGWcv1RzV7oUZshPLsh8zi839Rs8f+uzpH6QDcJmaDWVmLPR6nhVE6mSMtQsR37GeDd DZrZGOJzXIwAPHSq7EA+NB9Rg/k6uJTSK3pu0=
Received: by 10.229.43.2 with SMTP id u2mr2560565qce.215.1309535058798; Fri, 01 Jul 2011 08:44:18 -0700 (PDT)
Received: from [192.168.0.10] ([68.0.0.153]) by mx.google.com with ESMTPS id u15sm2643775qcq.12.2011.07.01.08.44.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 08:44:17 -0700 (PDT)
From: John Gammons <jgammons@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 01 Jul 2011 11:44:09 -0400
Message-Id: <E549EE58-A585-4603-85B9-C00FF295D480@gmail.com>
To: IPv6 Operations <v6ops@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-v6ops-ipv6-cpe-router-bis@tools.ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-cpe-router-bis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 01 Jul 2011 15:44:26 -0000
First off, overall, this is a great draft and a much needed one at that. A few thoughts that might be considered overly complex, but I thought I'd throw out there for potential talking points by the group. CGN/LSN(NAT44) environment - What if the WAN interface was provided an RFC1918 address (or potentially draft-weil-shared-transition-space-request-01/ARIN 2011-5 space), the CPE would accept this address as a management IP only, and fallback to bridge operation. The thought here being, that rather than downstream CPE operating in a NAT444 environment, they would then be only NAT44. This would obviously require that the provider no longer deliver only a single v4 address, but an unlimited number for any subscriber routed through a CGN/LSN. There are numerous other potential implications which would need further discussion, but the thought being, all of those _could_ be more preferred over the NAT444 implications. Essentially it would be "moving" the existing NAT44 to a more advantageous v4 location where overloading can be performed, rather than adding an additional layer. No WAN IPv4 address - If, the CPE is delegated a prefix, but does not receive an IPv4 address (public or private) on its WAN interface, and it does not receive a DS-Lite configuration, then it may be beneficial to fallback into a NAT46 operation (draft-liu-behave-nat46). The main benefit here is that if no WAN side IPv4 connectivity is available (due to provider configuration or some failure), legacy IPv4 only devices, would still have some means of Internet reachability. It would also require some implementation of DNS46 proxy (draft-xli-behave-dns46-for-stateless). Potentially being paired with a provider NAT64 solution to provide NAT464 connectivity. My intent is not to make this draft so incredibly complex that no vendor ever implements it, but from my own discussions regarding transition technologies, and my own testing performed thus far surrounding NAT444, I am curious to hear others thoughts. Thanks, John
- Re: [v6ops] draft-ietf-v6ops-ipv6-cpe-router-bis John Gammons
- Re: [v6ops] draft-ietf-v6ops-ipv6-cpe-router-bis Hemant Singh (shemant)
- Re: [v6ops] draft-ietf-v6ops-ipv6-cpe-router-bis james woodyatt