Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC]

joel jaeggli <joelja@bogus.com> Thu, 08 August 2013 07:22 UTC

Return-Path: <joelja@bogus.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 9FCDD11E80C5 for <v6ops@ietfa.amsl.com>; Thu, 8 Aug 2013 00:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.165
X-Spam-Level:
X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRG7L5dlV100 for <v6ops@ietfa.amsl.com>; Thu, 8 Aug 2013 00:22:15 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C32E221F9D96 for <v6ops@ietf.org>; Thu, 8 Aug 2013 00:21:46 -0700 (PDT)
Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r787LitY002697 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 8 Aug 2013 07:21:44 GMT (envelope-from joelja@bogus.com)
Message-ID: <52034701.2050806@bogus.com>
Date: Thu, 08 Aug 2013 00:21:37 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "cb.list6" <cb.list6@gmail.com>
References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <CAD6AjGTGL9JVK6egOAVXhMFv77L0b=9eVjKAauwNzLnaM=Mcyw@mail.gmail.com> <52031D69.3070604@gmail.com>
In-Reply-To: <52031D69.3070604@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 08 Aug 2013 07:21:44 +0000 (UTC)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC]
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: Thu, 08 Aug 2013 07:22:15 -0000

On 8/7/13 9:24 PM, Brian E Carpenter wrote:
> On 08/08/2013 16:08, cb.list6 wrote:
>> On Aug 5, 2013 9:49 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
>> wrote:
>>> On a different topic, section 5 covers IPv6-only issues.
>>> I'm a bit concerned that this might need a health warning:
>>> deploying NAT64/DNS64 might cause pain and suffering.
>>> Perhaps after this text:
>>>
>>>>    Together, RFCs
>>>>    6146 and RFC 6147 provide a viable method for an IPv6-only client to
>>>>    initiate communications to an IPv4-only server.
>>> we should add something like:
>>>
>>>    At enterprise level, operating NAT64 and DNS64 services for
>>>    heavy usage may have significant practical implications.
>>>
>> Can you be more specific? Pratical data?
> Not really, because I've never operated one in real life. It doesn't
> strike me as the sort of service that most enterprise network
> managers will be familiar with, and a v6-only site needing a normal
> level of access to v4-land would end up sending most of its external
> traffic via NAT64 and most of its external DNS queries via DNS64.
> Therefore, these would become an important single point of failure
> and a potential bottleneck. The text doesn't seem to point this out.
imho the tools you employ to scale this are about the same as those
employed for for nat44 or service load balancing.

e.g. stateless hashing, horizontal tiers of translators, no state
replication, multiple clusters for different regions/pops/offices etc.

the solutions in the marketplace more or less follow along those lines.

There are implications for both fragmentation and pmtud for some of
those cases that have to be managed, but I don't expect that comes as a
surprise.

>    Brian
>
>> CB
>>
>>> Also, the last paragraph of section 5:
>>>
>>>>    It is worth noting that for IPv6-only access networks that use
>>>>    technologies such as NAT64, the more content providers (and
>>>>    enterprises) that make their content available over IPv6, the less
>>>>    the requirement to apply NAT64 to traffic leaving the access network.
>>> A reference to RFC 6883 would fit nicely there.
>>>
>>> Regards
>>>    Brian
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>