Re: [sunset4] draft-tsou-stateless-nat44

"George, Wes" <wesley.george@twcable.com> Sat, 14 July 2012 00:35 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA421F8692 for <sunset4@ietfa.amsl.com>; Fri, 13 Jul 2012 17:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.115
X-Spam-Level:
X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1]
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 xp0rr8POthjz for <sunset4@ietfa.amsl.com>; Fri, 13 Jul 2012 17:35:43 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A2BCC21F8680 for <sunset4@ietf.org>; Fri, 13 Jul 2012 17:35:43 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.77,583,1336363200"; d="scan'208";a="409734804"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jul 2012 20:36:02 -0400
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 13 Jul 2012 20:36:11 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Dan Wing <dwing@cisco.com>, "sunset4@ietf.org" <sunset4@ietf.org>, "'Will Liu (Shucheng)'" <liushucheng@huawei.com>
Date: Fri, 13 Jul 2012 20:36:10 -0400
Thread-Topic: draft-tsou-stateless-nat44
Thread-Index: Ac1hEHgD9fg1lWZuQdqYd+8o14pBMQ==
Message-ID: <DCC302FAA9FE5F4BBA4DCAD4656937791745D3ADF5@PRVPEXVS03.corp.twcable.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sunset4] draft-tsou-stateless-nat44
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: sunset4 working group discussion list <sunset4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sunset4>, <mailto:sunset4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sunset4>
List-Post: <mailto:sunset4@ietf.org>
List-Help: <mailto:sunset4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sunset4>, <mailto:sunset4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jul 2012 00:35:44 -0000

> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Wednesday, July 11, 2012 12:44 PM
> To: George, Wes; sunset4@ietf.org; 'Will Liu (Shucheng)'
> Subject: RE: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou-
> stateless-nat44
>
> This seems to be a MAP solution.  But differs from MAP in that it uses
> an IPv4 network between the subscriber and the ISP's "stateless NAT44"
> device, whereas MAP uses an IPv6 network between the subscriber and the
> ISP's "MAP border relay" device.

[WEG] The chief criticism leveled at IPv4-only NAT solutions is that they do nothing to encourage IPv6 deployment, and instead function as IPv4 life-support by allowing carriers to delay deployment of IPv6. The authors will have a significant burden of justification as to why this is better than MAP in that it doesn't push the implementer to deploy IPv6 on the network (or at least allow the use of IPv6 as transport). Also, there are already multiple competing stateless solutions. I'd rather not add another without a very good statement of what problem it's solving that the existing ones do not. That's actually the reason for question #2 - "existing technologies" also refers to alternate solutions to the same problem that are still in draft, not just existing running code.

>
> > It can also be implemented in dual-stack network(IPv4 traffic pass
> > through stateless NAT44 and IPv6 traffic pass by stateless NAT44), so
> > the network can migrate to IPv6 smoothly.
>
> Typo in that sentence?
[WEG] excepting the typo (bypass vs pass by), the draft should say this, and in fact should probably say it in stronger terms - "a network using this NAT SHOULD deploy IPv6, so that all supporting devices and content can bypass the NAT and maintain end-to-end connectivity" or some similar. This is a drum we need to beat in every draft focused on an IPv4-only solution based on the way that our charter is written and IETF's overall opinion about IPV4 life-extension technologies.

>
> -d

Thanks,
Wes George, speaking as sunset4 co-chair.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.