Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers
In message <2788466ED3E31C418E9ACC5C316615572FFBAB at mou1wnexmb09.vcorp.ad.vrsn.c
om>, "Hallam-Baker, Phillip" writes:
> This is a multi-part message in MIME format.
>
> Eric,
>
> The problem here is that you assume that the IETF has decision power
> that can magic away NAT66. Clearly it did not for NAT44 and will not for
> NAT66.
>
> So the real question for App designers is:
>
> 1) Should they design protocols that assume no NAT66
> 2) Should they regard the assumption that there is no NAT6 as a design
> fault that may lead to lack of interoperability.
>
> The only way that the effort being expended to kill NAT66 makes any
> sense is if the idea is to allow this type of argument to be rulled out
> of scope as similar arguments were ruled out of scope when they were
> brought up in existing protocols that simply do not work properly
> because the design was intentionally made to be unfriendly to NAT.
>
>From ietf-bounces at ietf.org Wed Nov 26 14:40:33 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 3CE5C28C254;
Wed, 26 Nov 2008 14:40:33 -0800 (PST)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 644763A6914;
Wed, 26 Nov 2008 14:40:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level:
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id kW69xgRBUdpp; Wed, 26 Nov 2008 14:40:31 -0800 (PST)
Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c])
by core3.amsl.com (Postfix) with ESMTP id 56C833A6813;
Wed, 26 Nov 2008 14:40:30 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "farside.isc.org", Issuer "ISC CA" (verified OK))
by mx.isc.org (Postfix) with ESMTPS id 9A2F511402C;
Wed, 26 Nov 2008 22:40:19 +0000 (UTC)
(envelope-from Mark_Andrews at isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org
[IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified))
by farside.isc.org (Postfix) with ESMTP id ED8A6E60A7;
Wed, 26 Nov 2008 22:40:18 +0000 (UTC) (envelope-from marka at isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id mAQMeC6Z045877;
Thu, 27 Nov 2008 09:40:13 +1100 (EST)
(envelope-from marka at drugs.dv.isc.org)
Message-Id: <200811262240.mAQMeC6Z045877 at drugs.dv.isc.org>
To: "Hallam-Baker, Phillip" <pbaker at verisign.com>
From: Mark Andrews <Mark_Andrews at isc.org>
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to
applicationdevelopers
In-reply-to: Your message of "Wed, 26 Nov 2008 09:14:40 -0800."
<2788466ED3E31C418E9ACC5C316615572FFBAB at mou1wnexmb09.vcorp.ad.vrsn.com>
Date: Thu, 27 Nov 2008 09:40:12 +1100
Cc: IAB <iab at ietf.org>, IETF Discussion <ietf at ietf.org>,
Eric Klein <ericlklein.ipv6 at gmail.com>, alh-ietf at tndh.net,
IESG IESG <iesg at ietf.org>, "behave at ietf.org WG" <Behave at ietf.org>,
Fred Baker <fred at cisco.com>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org
In message <2788466ED3E31C418E9ACC5C316615572FFBAB at mou1wnexmb09.vcorp.ad.vrsn.c
om>, "Hallam-Baker, Phillip" writes:
> This is a multi-part message in MIME format.
>
> Eric,
>
> The problem here is that you assume that the IETF has decision power
> that can magic away NAT66. Clearly it did not for NAT44 and will not for
> NAT66.
>
> So the real question for App designers is:
>
> 1) Should they design protocols that assume no NAT66
> 2) Should they regard the assumption that there is no NAT6 as a design
> fault that may lead to lack of interoperability.
>
> The only way that the effort being expended to kill NAT66 makes any
> sense is if the idea is to allow this type of argument to be rulled out
> of scope as similar arguments were ruled out of scope when they were
> brought up in existing protocols that simply do not work properly
> because the design was intentionally made to be unfriendly to NAT.
>
> If we r If we recognize that there is no consensus that applications that are
> not NAT66-agile will work in future then we should agree that the
> reasonable default requirement for an apps WG should be that it should
> build a protocol that is NAT66 tolerant. But I suspect that there will
> be severe pushback against that.
>
>
> Peter Dambier is right in this case,
>
> I would NAT66 my network for the simple reason that very few endpoint
> devices actually tollerate a change in the IP address without at a
> minimum a service interruption. Since I cannot guarantee that my IPv6
> address from my ISP will never change I am going to NAT66 my internal
> network for the sake of having static numbering inside the network.
And if you stop thinking IPv6 == IPv4 + big addresses and
start thinking multiple IPv6 addresses including a ULA IPv6
address + RFC 3484 you get local address stability without
needing a NAT. You use ULAs for internal communication and
global addresses for external communication.
This isn't future stuff, you can do this today. You can
renumber your external addresses daily and keep internal
sessions up for weeks.
> The more infrequent you posit the need for renumbering is, the greater
> my reluctance to allowing it will become. If you have a network event
> that happens only once a year it is going to mean a very serious
> disruption when it happens. DHCP only solves some of the problems, I am
> still effectively forced to perform a reboot, I will lose connections
> and this will cost me real time and money to fix.
If your OS requires a reboot when you renumber get a real OS.
If your apps require that they restart when you renumber get
your apps fixed.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ecognize that there is no consensus that applications that are
> not NAT66-agile will work in future then we should agree that the
> reasonable default requirement for an apps WG should be that it should
> build a protocol that is NAT66 tolerant. But I suspect that there will
> be severe pushback against that.
>
>
> Peter Dambier is right in this case,
>
> I would NAT66 my network for the simple reason that very few endpoint
> devices actually tollerate a change in the IP address without at a
> minimum a service interruption. Since I cannot guarantee that my IPv6
> address from my ISP will never change I am going to NAT66 my internal
> network for the sake of having static numbering inside the network.
And if you stop thinking IPv6 == IPv4 + big addresses and
start thinking multiple IPv6 addresses including a ULA IPv6
address + RFC 3484 you get local address stability without
needing a NAT. You use ULAs for internal communication and
global addresses for external communication.
This isn't future stuff, you can do this today. You can
renumber your external addresses daily and keep internal
sessions up for weeks.
> The more infrequent you posit the need for renumbering is, the greater
> my reluctance to allowing it will become. If you have a network event
> that happens only once a year it is going to mean a very serious
> disruption when it happens. DHCP only solves some of the problems, I am
> still effectively forced to perform a reboot, I will lose connections
> and this will cost me real time and money to fix.
If your OS requires a reboot when you renumber get a real OS.
If your apps require that they restart when you renumber get
your apps fixed.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
