From philip_matthews@magma.ca Mon Aug 2 14:27:17 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF933A6C6D for ; Mon, 2 Aug 2010 14:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.071 X-Spam-Level: * X-Spam-Status: No, score=1.071 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001] 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 TP4RA3ws2f+w for ; Mon, 2 Aug 2010 14:27:17 -0700 (PDT) Received: from mail-01.primus.ca (mail16.primus.ca [216.254.141.183]) by core3.amsl.com (Postfix) with ESMTP id E0F663A67DA for ; Mon, 2 Aug 2010 14:27:16 -0700 (PDT) Received: from bas12-ottawa23-1177806217.dsl.bell.ca ([70.51.229.137] helo=[192.168.2.16]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Og2Xv-0000BO-0d; Mon, 02 Aug 2010 17:27:43 -0400 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-13--342833622 From: Philip Matthews In-Reply-To: <201007262131.o6QLVQmk001896@drugs.dv.isc.org> Date: Mon, 2 Aug 2010 10:32:40 -0400 Message-Id: <28167C07-ED66-4B13-9A27-48B73EF4943C@magma.ca> References: <4C4DAA99.5040500@piuha.net> <201007262131.o6QLVQmk001896@drugs.dv.isc.org> To: Cameron Byrne X-Mailer: Apple Mail (2.1078) X-Authenticated: philip_matthews - bas12-ottawa23-1177806217.dsl.bell.ca ([192.168.2.16]) [70.51.229.137] Cc: Behave WG , Mark Andrews Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 21:27:18 -0000 --Apple-Mail-13--342833622 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom my discussions with a number of providers at the IETF meeting = last week, they are all looking for a bit more private address space to = provide them with a bit of breathing room while they transition to IPv6. = Every provider that I talked to was working on IPv6 transition, but none = of them could turn it on overnight.=20 - Philip On 2010-07-26, at 17:31 , Mark Andrews wrote: >=20 > In message = , Came > ron Byrne writes: >> d. IPv6-only networks with NAT64 / DNS64. This option best >> encourages the use of IPv6 and really gets network and application >> designers focused on the end-game, not wallowing in some middle-state >> of CGN / LSN / and endless NAT444. >=20 > Anything for big networks will require some form of address sharing > between customers. NAT64 / DS-LITE / NAT444. >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 --Apple-Mail-13--342833622 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii =46rom = my discussions with a number of providers at the IETF meeting last week, = they are all looking for a bit more private address space to provide = them with a bit of breathing room while they transition to IPv6. Every = provider that I talked to was working on IPv6 transition, but none of = them could turn it on overnight. 
- = Philip
= --Apple-Mail-13--342833622-- From brian.e.carpenter@gmail.com Mon Aug 2 16:18:13 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8DB3A69F6 for ; Mon, 2 Aug 2010 16:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=-0.283, 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 5XBYTfpZsyy1 for ; Mon, 2 Aug 2010 16:18:11 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8597D3A69E5 for ; Mon, 2 Aug 2010 16:18:11 -0700 (PDT) Received: by vws10 with SMTP id 10so2650476vws.31 for ; Mon, 02 Aug 2010 16:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ox4VRr7Ni5fFiPzZGW1jtMx2wvRZIWKR2lobAI1QkpI=; b=L0w2xpP8M7zBAn/DdF9LjQ2SoafSOcsZ155rSK1DfQt5vTE9xLHYSm3rBuzG3YC3wZ zn3n3InTrgKp7bMiM5cU8CcgHaJL74FOO7CL/kz/FL55UTMHDb2Ajwu0WLwErjgJEO/o ijtC0ecjHkNYxg9r2s2FlhzZS4RhZG/ilu1GM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=lstts/xHMVLBGsRpJ7dRgtxYCQqX6rFo44kvINLui2u6FPM3cMhXIU0nV43iL5Avn5 tpY/IMfbI97sWTBHKb1GdzO56vojuEcT0g9i7prJT0bxPBH3SEx/mTdhvHH4qzEBMXp7 wXmuqjIzADs6O5E0Y+pHP9SXbphto7+bDZOio= Received: by 10.220.128.198 with SMTP id l6mr4653201vcs.219.1280791119116; Mon, 02 Aug 2010 16:18:39 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id w1sm6471132vbl.18.2010.08.02.16.18.36 (version=SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 16:18:38 -0700 (PDT) Message-ID: <4C57524A.3040407@gmail.com> Date: Tue, 03 Aug 2010 11:18:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews References: <4C4DAA99.5040500@piuha.net> <201007262131.o6QLVQmk001896@drugs.dv.isc.org> <28167C07-ED66-4B13-9A27-48B73EF4943C@magma.ca> In-Reply-To: <28167C07-ED66-4B13-9A27-48B73EF4943C@magma.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Cameron Byrne , Behave WG , Mark Andrews Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 23:18:13 -0000 Philip, I have no reason to doubt that many ISPs would like a little bit more private space. But how does that affect the arguments that any such space would create problems, which seems to be the point of this draft? Regards Brian On 2010-08-03 02:32, Philip Matthews wrote: > From my discussions with a number of providers at the IETF meeting last week, they are all looking for a bit more private address space to provide them with a bit of breathing room while they transition to IPv6. Every provider that I talked to was working on IPv6 transition, but none of them could turn it on overnight. > - Philip > > On 2010-07-26, at 17:31 , Mark Andrews wrote: > >> In message , Came >> ron Byrne writes: >>> d. IPv6-only networks with NAT64 / DNS64. This option best >>> encourages the use of IPv6 and really gets network and application >>> designers focused on the end-game, not wallowing in some middle-state >>> of CGN / LSN / and endless NAT444. >> Anything for big networks will require some form of address sharing >> between customers. NAT64 / DS-LITE / NAT444. >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From henning.rogge@fkie.fraunhofer.de Mon Aug 2 22:39:36 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C373A6861 for ; Mon, 2 Aug 2010 22:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[AWL=-2.736, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 J-InPq4kslGj for ; Mon, 2 Aug 2010 22:38:46 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id 9B21A3A683C for ; Mon, 2 Aug 2010 22:38:23 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OgABY-0001vn-GG for behave@ietf.org; Tue, 03 Aug 2010 07:37:08 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OgABY-0003IU-7n for behave@ietf.org; Tue, 03 Aug 2010 07:37:08 +0200 From: Henning Rogge To: behave@ietf.org Date: Tue, 3 Aug 2010 07:36:59 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4081519.Ea18haxO8P"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008030737.05166.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11487/Tue Aug 3 04:16:15 2010) by mailguard.fgan.de X-Scan-Signature: 342e94ff8fe4d6b52457860454fe5b62 Subject: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP-encapsulation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 05:39:38 -0000 --nextPart4081519.Ea18haxO8P Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would like to ask if the addresses in draft-ietf-behave-address-format=20 should also be used for stateless IPIP-encapsulation. We (www.freifunk.net, www.olsr.org) are using large clouds of MANET routers= =20 for free community networks in several cities. Each router might connect to= a=20 local attached ethernet, some are connected to an internet uplink. At the moment all our mesh clouds use IPv4 private addresses (most use=20 10.0.0.0/8) for their interfaces and node identifiers, but we would like to= =20 change this to IPv6. To do this someone from Berlin wrote a linux kernel=20 module to allow stateless generation of IPv4-in-IPv6 tunnel packets. We poi= nt=20 an IPv4 route into a translation device and it generates an IPv6 header aro= und=20 the old packet by adding a prefix to the IPv4 source and destination addres= s.=20 The IPv6 packet will then be send to the target router. At the moment we use the ::ffff:0:0/96 prefix for this, but this does not w= ork=20 well with all operation systems. All IPv6 tunnel packets are only flowing inside our mesh network, the inter= net=20 or the attached local ethernets never see this packets. What would be a good prefix for this scenario that we can use on all mesh=20 routers worldwide, so we can preconfigure it in our firmware. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart4081519.Ea18haxO8P Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxXqvsACgkQRIfGfFXsz+ABHgCfevbRgPbex7TS5US1MOHY7hUm 6/oAn05TgbsDqzBQhq/civGTq/ZF01DN =QiPH -----END PGP SIGNATURE----- --nextPart4081519.Ea18haxO8P-- From philip_matthews@magma.ca Tue Aug 3 03:08:27 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A243A68FB for ; Tue, 3 Aug 2010 03:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[AWL=1.834, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 d9hIL3T4gGZE for ; Tue, 3 Aug 2010 03:08:25 -0700 (PDT) Received: from mail-09.primus.ca (mail16.primus.ca [216.254.141.183]) by core3.amsl.com (Postfix) with ESMTP id AE5A13A68F0 for ; Tue, 3 Aug 2010 03:08:25 -0700 (PDT) Received: from bas12-ottawa23-1177806217.dsl.bell.ca ([70.51.229.137] helo=[192.168.2.16]) by mail-09.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OgEQX-0003uf-07; Tue, 03 Aug 2010 06:08:53 -0400 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-22--272262377 From: Philip Matthews In-Reply-To: <4C57524A.3040407@gmail.com> Date: Tue, 3 Aug 2010 06:08:51 -0400 Message-Id: <39A95334-DF93-4A9A-A9D6-9D48177BB056@magma.ca> References: <4C4DAA99.5040500@piuha.net> <201007262131.o6QLVQmk001896@drugs.dv.isc.org> <28167C07-ED66-4B13-9A27-48B73EF4943C@magma.ca> <4C57524A.3040407@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1078) X-Authenticated: philip_matthews - bas12-ottawa23-1177806217.dsl.bell.ca ([192.168.2.16]) [70.51.229.137] Cc: Cameron Byrne , Behave WG , Mark Andrews Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 10:08:27 -0000 --Apple-Mail-22--272262377 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hmm... Perhaps I missing something, but I just re-read the draft and I = didn't see that it was arguing against allocating additional space. It = pointed out some problems, but they didn't seem unsurmountable to me. = The operators I talked with told me "We know there are problems, but we = are willing to live with them, because we really need extra IPv4 space. = We HAVE to get extra space from somewhere." Some of the operators I talked with are those behind = http://tools.ietf.org/id/draft-weil-opsawg-provider-address-space-00.txt - Philip On 2010-08-02, at 19:18 , Brian E Carpenter wrote: > Philip, >=20 > I have no reason to doubt that many ISPs would like a little bit more > private space. But how does that affect the arguments that any such > space would create problems, which seems to be the point of this = draft? >=20 > Regards > Brian >=20 > On 2010-08-03 02:32, Philip Matthews wrote: >> =46rom my discussions with a number of providers at the IETF meeting = last week, they are all looking for a bit more private address space to = provide them with a bit of breathing room while they transition to IPv6. = Every provider that I talked to was working on IPv6 transition, but none = of them could turn it on overnight.=20 >> - Philip >>=20 >> On 2010-07-26, at 17:31 , Mark Andrews wrote: >>=20 >>> In message = , Came >>> ron Byrne writes: >>>> d. IPv6-only networks with NAT64 / DNS64. This option best >>>> encourages the use of IPv6 and really gets network and application >>>> designers focused on the end-game, not wallowing in some = middle-state >>>> of CGN / LSN / and endless NAT444. >>> Anything for big networks will require some form of address sharing >>> between customers. NAT64 / DS-LITE / NAT444. >>>=20 >>> --=20 >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>>=20 >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 --Apple-Mail-22--272262377 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Some of the operators I talked with are those = behind    http://tools.ietf.org/id/draft-weil-opsawg-provider-address-space-= 00.txt
- Philip

On 2010-08-02, at = 19:18 , Brian E Carpenter wrote:

Philip,

I have no reason to doubt that many = ISPs would like a little bit more
private space. But how does that = affect the arguments that any such
space would create problems, which = seems to be the point of this draft?

Regards
=   Brian

On 2010-08-03 02:32, Philip Matthews = wrote:
=46rom my discussions with a number = of providers at the IETF meeting last week, they are all looking for a = bit more private address space to provide them with a bit of breathing = room while they transition to IPv6. Every provider that I talked to was = working on IPv6 transition, but none of them could turn it on overnight. =
- = Philip

On 2010-07-26, = at 17:31 , Mark Andrews wrote:

In message <AANLkTi=3D65nxb_baJL=3DQDpFyJGuPFXNwZvnis9PZQNTRk@mail.gmail.com>, Came
ron Byrne = writes:
d.  IPv6-only networks = with NAT64 / DNS64.  This option = best
encourages the use of IPv6 and really gets network and = application
designers focused on the end-game, not wallowing in some = middle-state
of CGN = / LSN / and endless = NAT444.
Anything for big networks will = require some form of address = sharing
between customers.  NAT64 / DS-LITE / = NAT444.

-- =
Mark Andrews, ISC
1 Seymour St., Dundas Valley, = NSW 2117, Australia
PHONE: +61 2 9871 4742 =             &n= bsp;   INTERNET: marka@isc.org
_______________________________________________
Behave mailing = list
Behave@ietf.org
https://www.ietf.org= /mailman/listinfo/behave




------------------------------------------------------------= ------------

_______________________________________________
Behave mailing = list
Behave@ietf.org
https://www.ietf.org= /mailman/listinfo/behave

=
= --Apple-Mail-22--272262377-- From simon.perreault@viagenie.ca Tue Aug 3 05:52:23 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2093C3A680D for ; Tue, 3 Aug 2010 05:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 61V4+OPkPQi9 for ; Tue, 3 Aug 2010 05:52:21 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id A93683A63C9 for ; Tue, 3 Aug 2010 05:52:20 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:4844:ab44:b824:8b36]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B26C820D36; Tue, 3 Aug 2010 08:52:48 -0400 (EDT) Message-ID: <4C581120.6050300@viagenie.ca> Date: Tue, 03 Aug 2010 08:52:48 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: Henning Rogge References: <201008030737.05166.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201008030737.05166.henning.rogge@fkie.fraunhofer.de> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP-encapsulation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 12:52:23 -0000 On 2010-08-03 01:36, Henning Rogge wrote: > At the moment all our mesh clouds use IPv4 private addresses (most use > 10.0.0.0/8) for their interfaces and node identifiers, but we would like to > change this to IPv6. To do this someone from Berlin wrote a linux kernel > module to allow stateless generation of IPv4-in-IPv6 tunnel packets. We point > an IPv4 route into a translation device and it generates an IPv6 header around > the old packet by adding a prefix to the IPv4 source and destination address. > The IPv6 packet will then be send to the target router. > At the moment we use the ::ffff:0:0/96 prefix for this, but this does not work > well with all operation systems. > > All IPv6 tunnel packets are only flowing inside our mesh network, the internet > or the attached local ethernets never see this packets. > > What would be a good prefix for this scenario that we can use on all mesh > routers worldwide, so we can preconfigure it in our firmware. First, let me say I'm not convinced that this is the right deployment model. But let's not discuss that and suppose it is. I think each deployment should be using a different prefix. This is probably not what you expect, as it is very different from the IPv4 way of doing things. But I think it will make things easier down the road. I see two possibilities: a. Use a global-scope prefix. For example, just carve a /96 out of any address range you have been assigned by an ISP, and use that. b. Use a unique-local prefix. You can generate a globally-unique local-scope prefix following . I have a small Perl implementation that I could perhaps share with you if you need it. Maybe this could be run automatically by your firmware to generate a prefix on the fly. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From henning.rogge@fkie.fraunhofer.de Tue Aug 3 06:08:50 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17E23A6827 for ; Tue, 3 Aug 2010 06:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 gQfTuDz1jWTY for ; Tue, 3 Aug 2010 06:08:49 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id C9E933A6800 for ; Tue, 3 Aug 2010 06:08:48 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OgHF3-0000P7-Nn; Tue, 03 Aug 2010 15:09:13 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OgHF3-0005L0-FE; Tue, 03 Aug 2010 15:09:13 +0200 From: Henning Rogge To: Simon Perreault Date: Tue, 3 Aug 2010 15:09:02 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <201008030737.05166.henning.rogge@fkie.fraunhofer.de> <4C581120.6050300@viagenie.ca> In-Reply-To: <4C581120.6050300@viagenie.ca> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4434474.YU04PrsziD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008031509.10200.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11488/Tue Aug 3 13:37:10 2010) by mailguard.fgan.de X-Scan-Signature: 990dd1dead5e5990fbbbdf25ebfcda39 Cc: behave@ietf.org Subject: Re: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP-encapsulation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 13:08:50 -0000 --nextPart4434474.YU04PrsziD Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue August 3 2010 14:52:48 Simon Perreault wrote: > On 2010-08-03 01:36, Henning Rogge wrote: > > At the moment all our mesh clouds use IPv4 private addresses (most use > > 10.0.0.0/8) for their interfaces and node identifiers, but we would like > > to change this to IPv6. To do this someone from Berlin wrote a linux > > kernel module to allow stateless generation of IPv4-in-IPv6 tunnel > > packets. We point an IPv4 route into a translation device and it > > generates an IPv6 header around the old packet by adding a prefix to the > > IPv4 source and destination address. The IPv6 packet will then be send > > to the target router. > > At the moment we use the ::ffff:0:0/96 prefix for this, but this does n= ot > > work well with all operation systems. > >=20 > > All IPv6 tunnel packets are only flowing inside our mesh network, the > > internet or the attached local ethernets never see this packets. > >=20 > > What would be a good prefix for this scenario that we can use on all me= sh > > routers worldwide, so we can preconfigure it in our firmware. >=20 > First, let me say I'm not convinced that this is the right deployment > model. But let's not discuss that and suppose it is. We are still experimenting with it, so I am open for a good advice. > I think each deployment should be using a different prefix.=20 > This is > probably not what you expect, as it is very different from the IPv4 way > of doing things. But I think it will make things easier down the road. The problem we see with this is that it's another mayor chance for=20 misconfiguration for the users (each mesh router is installed and configure= d=20 by it's own user). Especially because it has to be configured in the kernel= =20 module and the routing agent (our routing agent automatically set up routes= =20 into the encapsulation device and between the routers for the 4over6 routes= ).=20 > I see two possibilities: >=20 > a. Use a global-scope prefix. For example, just carve a /96 out of any > address range you have been assigned by an ISP, and use that. Most of our networks don't have public IPv6 addresses. =20 > b. Use a unique-local prefix. You can generate a globally-unique > local-scope prefix following > . I have a small Perl > implementation that I could perhaps share with you if you need it. Maybe > this could be run automatically by your firmware to generate a prefix on > the fly. Would be interesting to look at this perl program. So you think it would be better to use a custom prefix instead of a well kn= own=20 one similar to the ones suggested in http://tools.ietf.org/html/draft-ietf- behave-address-format ? Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart4434474.YU04PrsziD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkxYFO4ACgkQRIfGfFXsz+CPbgCfXSIGAzN6IIC+YwXXKxZYPUIq PHcAnAxVmuhwPRb6etSOLpwugstuvgFp =ub+w -----END PGP SIGNATURE----- --nextPart4434474.YU04PrsziD-- From dwing@cisco.com Tue Aug 3 12:34:35 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595D63A69B7 for ; Tue, 3 Aug 2010 12:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.408 X-Spam-Level: X-Spam-Status: No, score=-10.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 k0rsrTsi-mMD for ; Tue, 3 Aug 2010 12:34:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2B4493A68B1 for ; Tue, 3 Aug 2010 12:34:30 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI8LWEyrR7Ht/2dsb2JhbACUVYtBcaktm1SFOQSEFw X-IronPort-AV: E=Sophos;i="4.55,311,1278288000"; d="scan'208";a="348863592" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2010 19:34:58 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o73JYv3i001929; Tue, 3 Aug 2010 19:34:58 GMT From: "Dan Wing" To: "'Henning Rogge'" , "'Simon Perreault'" References: <201008030737.05166.henning.rogge@fkie.fraunhofer.de> <4C581120.6050300@viagenie.ca> <201008031509.10200.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201008031509.10200.henning.rogge@fkie.fraunhofer.de> Date: Tue, 3 Aug 2010 12:34:57 -0700 Message-ID: <04f101cb3342$f50d0380$df270a80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcszDRf57AMBsa2xSta7fFUkfmaQaQANY+0Q Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP-encapsulation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:34:35 -0000 Hi, Henning. You might also ask on SOFTWIRE, where they do mesh networking and = 4-over-6 and 6-over-4 tunnels. Originally, draft-ietf-behave-address-format was intended to cover both translation (BEHAVE) and tunneling (SOFTWIRE), but that scope didn't = work out as originally hoped. However, the ideas in it may still work for = your purposes -- which is effectively what Simon suggested in his post when = he suggested on solution was to 'use the ISP's prefix and pick a /96' --> = which is the same as the Network-Specific Prefix (NSP) described in draft-ietf-behave-address-format. ULA may work well, too, even though over breakfast last week I had some reservations about ULA if/when the MANET network is joined with another network; but the ULAs for the tunnels don't actually need to be known to that other network. -d > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Henning Rogge > Sent: Tuesday, August 03, 2010 6:09 AM > To: Simon Perreault > Cc: behave@ietf.org > Subject: Re: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP- > encapsulation >=20 > On Tue August 3 2010 14:52:48 Simon Perreault wrote: > > On 2010-08-03 01:36, Henning Rogge wrote: > > > At the moment all our mesh clouds use IPv4 private addresses (most > > > use > > > 10.0.0.0/8) for their interfaces and node identifiers, but we = would > > > like to change this to IPv6. To do this someone from Berlin wrote = a > > > linux kernel module to allow stateless generation of IPv4-in-IPv6 > > > tunnel packets. We point an IPv4 route into a translation device > and > > > it generates an IPv6 header around the old packet by adding a > prefix > > > to the > > > IPv4 source and destination address. The IPv6 packet will then be > > > send to the target router. > > > At the moment we use the ::ffff:0:0/96 prefix for this, but this > > > does not work well with all operation systems. > > > > > > All IPv6 tunnel packets are only flowing inside our mesh network, > > > the internet or the attached local ethernets never see this > packets. > > > > > > What would be a good prefix for this scenario that we can use on > all > > > mesh routers worldwide, so we can preconfigure it in our firmware. > > > > First, let me say I'm not convinced that this is the right = deployment > > model. But let's not discuss that and suppose it is. > We are still experimenting with it, so I am open for a good advice. >=20 > > I think each deployment should be using a different prefix. >=20 > > This is > > probably not what you expect, as it is very different from the IPv4 > > way of doing things. But I think it will make things easier down the > road. > The problem we see with this is that it's another mayor chance for > misconfiguration for the users (each mesh router is installed and > configured by it's own user). Especially because it has to be > configured in the kernel module and the routing agent (our routing > agent automatically set up routes into the encapsulation device and > between the routers for the 4over6 routes). >=20 > > I see two possibilities: > > > > a. Use a global-scope prefix. For example, just carve a /96 out of > any > > address range you have been assigned by an ISP, and use that. > Most of our networks don't have public IPv6 addresses. >=20 > > b. Use a unique-local prefix. You can generate a globally-unique > > local-scope prefix following > > . I have a small > > Perl implementation that I could perhaps share with you if you need > > it. Maybe this could be run automatically by your firmware to > generate > > a prefix on the fly. > Would be interesting to look at this perl program. >=20 > So you think it would be better to use a custom prefix instead of a > well known one similar to the ones suggested in > http://tools.ietf.org/html/draft-ietf- > behave-address-format ? >=20 > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, > Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From hrogge@googlemail.com Tue Aug 3 12:41:31 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05FB3A69C9 for ; Tue, 3 Aug 2010 12:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 QKd4ojI4Izgd for ; Tue, 3 Aug 2010 12:41:29 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 84E0D3A68B1 for ; Tue, 3 Aug 2010 12:41:29 -0700 (PDT) Received: by ewy22 with SMTP id 22so1999126ewy.31 for ; Tue, 03 Aug 2010 12:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=Rvn4bhSRZEpQQqrbIgJU+bz2rOLYXPUpLWO9GcJDHoQ=; b=u6i0+HipjkP5hSzZKpR0H3SDPLcqh8xyn8Dza0eHHywupzGOfdSOuhkYLcOdZ/e6TK KdbUUrgTFItthBUCZptzouB+PmLtxdNjpU/uhvlNjIj6kQdq2EiRx21ztp0pwCOV0tEh drDQwdFZVIm0v+eAHLhdgALlRp1HtfP0RRAGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=L7wxLsTkgZBAdhtAo6OIq6Y2K095agztfWEP0gnVYI1PKsr5W0LZMgUHX+U9cElDOA sEkGt8fJdxwuQc/KLUVF/nRfIUIFRcvbxudci8qgu54BO5rsbIVf/uTkEGOMwxJno87x o2ennj7yj+hAxn4nmprDv5OzUxE1LweG2z+Rs= Received: by 10.213.25.130 with SMTP id z2mr6020746ebb.12.1280864517755; Tue, 03 Aug 2010 12:41:57 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id a48sm11338222eei.13.2010.08.03.12.41.56 (version=SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 12:41:56 -0700 (PDT) From: Henning Rogge To: behave@ietf.org Date: Tue, 3 Aug 2010 21:41:27 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r2; KDE/4.4.5; x86_64; ; ) References: <201008030737.05166.henning.rogge@fkie.fraunhofer.de> <201008031509.10200.henning.rogge@fkie.fraunhofer.de> <04f101cb3342$f50d0380$df270a80$@com> In-Reply-To: <04f101cb3342$f50d0380$df270a80$@com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2089130.x5x1Ap1Etc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008032141.47808.hrogge@googlemail.com> Cc: 'Henning Rogge' , Dan Wing Subject: Re: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP-encapsulation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:41:31 -0000 --nextPart2089130.x5x1Ap1Etc Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Dienstag 03 August 2010, 21:34:57 schrieb Dan Wing: > Hi, Henning. >=20 > You might also ask on SOFTWIRE, where they do mesh networking and 4-over-6 > and 6-over-4 tunnels. Thank you for the advice, I will ask there too. =20 > Originally, draft-ietf-behave-address-format was intended to cover both > translation (BEHAVE) and tunneling (SOFTWIRE), but that scope didn't work > out as originally hoped. However, the ideas in it may still work for your > purposes -- which is effectively what Simon suggested in his post when he > suggested on solution was to 'use the ISP's prefix and pick a /96' --> > which is the same as the Network-Specific Prefix (NSP) described in > draft-ietf-behave-address-format. Okay. Is there an implementation of the IPv4/IPv6 stateless translation as a linu= x=20 kernel module ?=20 Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart2089130.x5x1Ap1Etc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAkxYcOwACgkQcenvcwAcHWev8QCfUlXrtMFSMpK2sFPQpi+oiVjy TwUAnAv+rjWTL4V2iLfykoGBI+Wy28yy =ZVxh -----END PGP SIGNATURE----- --nextPart2089130.x5x1Ap1Etc-- From dwing@cisco.com Tue Aug 3 13:04:37 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2494A3A6A86 for ; Tue, 3 Aug 2010 13:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Xhb6v0STHl80 for ; Tue, 3 Aug 2010 13:04:36 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 41F373A6972 for ; Tue, 3 Aug 2010 13:04:36 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAFANQSWEyrR7H+/2dsb2JhbACTOoEbi0BxqSWbU4U5BIQX X-IronPort-AV: E=Sophos;i="4.55,311,1278288000"; d="scan'208";a="166980907" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 03 Aug 2010 20:05:05 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o73K54dx013181 for ; Tue, 3 Aug 2010 20:05:04 GMT From: "Dan Wing" To: Date: Tue, 3 Aug 2010 13:05:04 -0700 Message-ID: <052701cb3347$29f3a8c0$7ddafa40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcszRym8G63pXO0QTNGdSPxsbuQf9Q== Content-Language: en-us Subject: [BEHAVE] new PCP mailing list (port control protocol) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 20:04:37 -0000 A new mailing list has been created for PCP (port control protocol). If interested please subscribe via https://www.ietf.org/mailman/listinfo/pcp After the first post and archive run, archives will be available at http://www.ietf.org/mail-archive/web/pcp -d From dwing@cisco.com Tue Aug 3 13:06:01 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5271F3A69C6 for ; Tue, 3 Aug 2010 13:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 oOFePilYSAcQ for ; Tue, 3 Aug 2010 13:06:00 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 634E23A69A6 for ; Tue, 3 Aug 2010 13:06:00 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA8TWEyrR7Ht/2dsb2JhbACDFZFAi0BxqS+JRZIOgSaDIHMEhBc X-IronPort-AV: E=Sophos;i="4.55,311,1278288000"; d="scan'208";a="234993021" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 03 Aug 2010 20:06:29 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o73K6T0F029347; Tue, 3 Aug 2010 20:06:29 GMT From: "Dan Wing" To: "'Henning Rogge'" , References: <201008030737.05166.henning.rogge@fkie.fraunhofer.de> <201008031509.10200.henning.rogge@fkie.fraunhofer.de> <04f101cb3342$f50d0380$df270a80$@com> <201008032141.47808.hrogge@googlemail.com> In-Reply-To: <201008032141.47808.hrogge@googlemail.com> Date: Tue, 3 Aug 2010 13:06:28 -0700 Message-ID: <052901cb3347$5c384fc0$14a8ef40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcszQ/GiZMN97i5+QmKw9BSqz5eDewAA2DIQ Content-Language: en-us Cc: 'Henning Rogge' Subject: Re: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP-encapsulation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 20:06:01 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Henning Rogge > Sent: Tuesday, August 03, 2010 12:41 PM > To: behave@ietf.org > Cc: 'Henning Rogge'; Dan Wing > Subject: Re: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP- > encapsulation >=20 > Am Dienstag 03 August 2010, 21:34:57 schrieb Dan Wing: > > Hi, Henning. > > > > You might also ask on SOFTWIRE, where they do mesh networking and > > 4-over-6 and 6-over-4 tunnels. > Thank you for the advice, I will ask there too. >=20 > > Originally, draft-ietf-behave-address-format was intended to cover > > both translation (BEHAVE) and tunneling (SOFTWIRE), but that scope > > didn't work out as originally hoped. However, the ideas in it may > > still work for your purposes -- which is effectively what Simon > > suggested in his post when he suggested on solution was to 'use the > > ISP's prefix and pick a /96' --> which is the same as the > > Network-Specific Prefix (NSP) described in = draft-ietf-behave-address- > format. > Okay. >=20 > Is there an implementation of the IPv4/IPv6 stateless translation as a > linux kernel module ? I am aware of http://linux.ivi2.org/impl/ -d > Henning Rogge >=20 > -- > 1) You can't win. > 2) You can't break even. > 3) You can't leave the game. > =E2=80=94 The Laws of Thermodynamics, summarized From remi.despres@free.fr Tue Aug 3 14:10:47 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF583A6B09 for ; Tue, 3 Aug 2010 14:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=-1.639, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3] 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 s05xHiTDVN0k for ; Tue, 3 Aug 2010 14:10:45 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by core3.amsl.com (Postfix) with ESMTP id 5F76F3A681A for ; Tue, 3 Aug 2010 14:10:45 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id 92EFE700008B; Tue, 3 Aug 2010 23:11:13 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id C718B7000087; Tue, 3 Aug 2010 23:11:10 +0200 (CEST) X-SFR-UUID: 20100803211110815.C718B7000087@msfrf2303.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <055d01cb334d$65f478d0$31dd6a70$@com> Date: Tue, 3 Aug 2010 23:11:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47295AD4-7F50-4751-A9EC-45D48D928CD7@free.fr> References: <4FAA72A8-6223-4956-9CB1-D3DB4E555209@cisco.com> <4C577BF2.9000807@gmail.com> <148F4D91-A203-4660-B2D1-59808D86A876@cisco.com> <3D4F97DE-E523-4206-BB87-61281C4A73B4@apnic.net> <040401cb332e$2f5ce380$8e16aa80$@com> <86F21EF8-9C98-4C2A-BAF5-29F4AD6D1426@free.fr> <055d01cb334d$65f478d0$31dd6a70$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1081) Cc: IPv6 v6ops , Behave WG Subject: [BEHAVE] Avoiding the terminology confusion with NAT66 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 21:10:47 -0000 Le 3 ao=FBt 2010 =E0 22:49, Dan Wing a =E9crit : ... >>> If the industry (IETF and the press and authors of books) are going >> to >>> overload the meaning of NAT66 to include Port Address Translation, = it >>> will have the same negative effect as the overloaded NAT(44) name. >>=20 >> In my understanding, this overloading is already here, and is >> unavoidable. >> It is downloading a natural and popular meaning that is IMHO a = mistake. >=20 > If so, I encourage Margaret and Fred to not use NAT66 for their=20 > specification. Rather, "IPv6 Prefix Rewriting". "6pr" almost rolls = off > the tongue. +1 for this new name Other names could do it too, e.g. PT66 for prefix translation, or SPT = for Stateless Prefix Translation, whatever Margaret and:or the majority = would prefer, provided it isn't NAT66. Regards, RD From brian.e.carpenter@gmail.com Tue Aug 3 14:30:26 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1263A6AFF for ; Tue, 3 Aug 2010 14:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=-0.266, 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 2qrZY264HWcr for ; Tue, 3 Aug 2010 14:30:23 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 8306B3A69D2 for ; Tue, 3 Aug 2010 14:30:19 -0700 (PDT) Received: by ewy22 with SMTP id 22so2036614ewy.31 for ; Tue, 03 Aug 2010 14:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oW9Dy3XTSXdSL3QUIRSaa1vbe2PQ3w75xKYcQDicIHE=; b=YlbmCXftg8eOjMqdYPJyTxXPAZDkXTjsrTXnTamnQlyl0RdvC1hM+ig/7gwsHVc175 vf7zY6Z0YkdN1o+GakQOQT7gSHOGRMftYQTZMzdD/m80n/0gPTV0iQh5u/vx2rAQ7tZh Uh82fnfUvDxx+HfmGDBcddF2/WNMIKF1nr90k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=w0ix7E3ngBbzUeUWkHdykoTAW5NsGXGJCjsSGmtN81C81/LeVXuXe0O6rVfvfG+A0U 9ykpWPP5WEvTZqpiiAstWDa4iRJSoBgVALx0xApL1aWMaPTIUqKsa2Nnc0du3IyY/RL1 yOk/R5aRLgm/M3UXtPzuFsZCIvECRoGOE1bUo= Received: by 10.213.32.17 with SMTP id a17mr6075843ebd.11.1280871044700; Tue, 03 Aug 2010 14:30:44 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id u9sm5536736eeh.5.2010.08.03.14.30.40 (version=SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 14:30:43 -0700 (PDT) Message-ID: <4C588A7E.1040502@gmail.com> Date: Wed, 04 Aug 2010 09:30:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews References: <4C4DAA99.5040500@piuha.net> <201007262131.o6QLVQmk001896@drugs.dv.isc.org> <28167C07-ED66-4B13-9A27-48B73EF4943C@magma.ca> <4C57524A.3040407@gmail.com> <39A95334-DF93-4A9A-A9D6-9D48177BB056@magma.ca> In-Reply-To: <39A95334-DF93-4A9A-A9D6-9D48177BB056@magma.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Cameron Byrne , Behave WG , Mark Andrews Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 21:30:26 -0000 Philip, This draft doesn't actually propose to allocate such space, so the fact that some ISPs want it is beside the point of the draft. There are other drafts that do make such a proposal, but as far as I know they aren't in Last Call. Regards Brian On 2010-08-03 22:08, Philip Matthews wrote: > Hmm... Perhaps I missing something, but I just re-read the draft and I didn't see that it was arguing against allocating additional space. It pointed out some problems, but they didn't seem unsurmountable to me. The operators I talked with told me "We know there are problems, but we are willing to live with them, because we really need extra IPv4 space. We HAVE to get extra space from somewhere." > Some of the operators I talked with are those behind http://tools.ietf.org/id/draft-weil-opsawg-provider-address-space-00.txt > - Philip > > On 2010-08-02, at 19:18 , Brian E Carpenter wrote: > >> Philip, >> >> I have no reason to doubt that many ISPs would like a little bit more >> private space. But how does that affect the arguments that any such >> space would create problems, which seems to be the point of this draft? >> >> Regards >> Brian >> >> On 2010-08-03 02:32, Philip Matthews wrote: >>> From my discussions with a number of providers at the IETF meeting last week, they are all looking for a bit more private address space to provide them with a bit of breathing room while they transition to IPv6. Every provider that I talked to was working on IPv6 transition, but none of them could turn it on overnight. >>> - Philip >>> >>> On 2010-07-26, at 17:31 , Mark Andrews wrote: >>> >>>> In message , Came >>>> ron Byrne writes: >>>>> d. IPv6-only networks with NAT64 / DNS64. This option best >>>>> encourages the use of IPv6 and really gets network and application >>>>> designers focused on the end-game, not wallowing in some middle-state >>>>> of CGN / LSN / and endless NAT444. >>>> Anything for big networks will require some form of address sharing >>>> between customers. NAT64 / DS-LITE / NAT444. >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave > > From randy@psg.com Tue Aug 3 14:43:05 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DBA3A6B10 for ; Tue, 3 Aug 2010 14:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3] 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 b1cQ8RDauNW0 for ; Tue, 3 Aug 2010 14:43:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id F188B3A6B0A for ; Tue, 3 Aug 2010 14:43:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OgPGh-000KtQ-Ql; Tue, 03 Aug 2010 21:43:29 +0000 Date: Tue, 03 Aug 2010 23:43:25 +0200 Message-ID: From: Randy Bush To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <47295AD4-7F50-4751-A9EC-45D48D928CD7@free.fr> References: <4FAA72A8-6223-4956-9CB1-D3DB4E555209@cisco.com> <4C577BF2.9000807@gmail.com> <148F4D91-A203-4660-B2D1-59808D86A876@cisco.com> <3D4F97DE-E523-4206-BB87-61281C4A73B4@apnic.net> <040401cb332e$2f5ce380$8e16aa80$@com> <86F21EF8-9C98-4C2A-BAF5-29F4AD6D1426@free.fr> <055d01cb334d$65f478d0$31dd6a70$@com> <47295AD4-7F50-4751-A9EC-45D48D928CD7@free.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 v6ops , Behave WG , Dan Wing Subject: Re: [BEHAVE] Avoiding the terminology confusion with NAT66 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 21:43:05 -0000 >> If so, I encourage Margaret and Fred to not use NAT66 for their >> specification. Rather, "IPv6 Prefix Rewriting". "6pr" almost rolls >> off the tongue. > Other names could do it too, e.g. PT66 for prefix translation, or SPT > for Stateless Prefix Translation, whatever Margaret and:or the > majority would prefer, provided it isn't NAT66. since we're into deceptive marketing, why not call it chocolate ice cream? randy From joelja@bogus.com Tue Aug 3 15:54:56 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF193A6B3D for ; Tue, 3 Aug 2010 15:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=-0.270, 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 7YUeDOqx+UMe for ; Tue, 3 Aug 2010 15:54:55 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 5CEE13A68D3 for ; Tue, 3 Aug 2010 15:54:55 -0700 (PDT) Received: from dhcp-183.nokia.net (dhcp-183.nokia.net [192.103.16.183] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o73MtNgj005993 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 3 Aug 2010 22:55:23 GMT (envelope-from joelja@bogus.com) Message-ID: <4C589E5B.5020704@bogus.com> Date: Tue, 03 Aug 2010 15:55:23 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: behave@ietf.org References: <4C4DAA99.5040500@piuha.net> <201007262131.o6QLVQmk001896@drugs.dv.isc.org> <28167C07-ED66-4B13-9A27-48B73EF4943C@magma.ca> <4C57524A.3040407@gmail.com> <39A95334-DF93-4A9A-A9D6-9D48177BB056@magma.ca> <4C588A7E.1040502@gmail.com> In-Reply-To: <4C588A7E.1040502@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.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 03 Aug 2010 22:55:23 +0000 (UTC) Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 22:54:57 -0000 On 8/3/10 2:30 PM, Brian E Carpenter wrote: > Philip, > > This draft doesn't actually propose to allocate such space, so the fact that > some ISPs want it is beside the point of the draft. > > There are other drafts that do make such a proposal, but as far as I know they > aren't in Last Call. I'm sort of mystified by the intersection of draft-azinger-additional-private-ipv4-space-issues and draft-weil-opsawg-provider-address-space-00 which sites it as an informative reference. Addressing solutions for dealing with the depletion of the IPv4 public address space and the lack of available private addresses within large providers are presented in [I-D.azinger-additional-private-ipv4-space-issues] as well as [I-D.shirasaki-nat444-isp-shared-addr]. For larger Service Providers who require more than the 16 million Net-10 addresses, the preferred method for addressing the problems presented in both draft documents is to direct IANA to reserve a /8 from its unassigned IPv4 address pool. > Regards > Brian > > On 2010-08-03 22:08, Philip Matthews wrote: >> Hmm... Perhaps I missing something, but I just re-read the draft and I didn't see that it was arguing against allocating additional space. It pointed out some problems, but they didn't seem unsurmountable to me. The operators I talked with told me "We know there are problems, but we are willing to live with them, because we really need extra IPv4 space. We HAVE to get extra space from somewhere." >> Some of the operators I talked with are those behind http://tools.ietf.org/id/draft-weil-opsawg-provider-address-space-00.txt >> - Philip >> >> On 2010-08-02, at 19:18 , Brian E Carpenter wrote: >> >>> Philip, >>> >>> I have no reason to doubt that many ISPs would like a little bit more >>> private space. But how does that affect the arguments that any such >>> space would create problems, which seems to be the point of this draft? >>> >>> Regards >>> Brian >>> >>> On 2010-08-03 02:32, Philip Matthews wrote: >>>> From my discussions with a number of providers at the IETF meeting last week, they are all looking for a bit more private address space to provide them with a bit of breathing room while they transition to IPv6. Every provider that I talked to was working on IPv6 transition, but none of them could turn it on overnight. >>>> - Philip >>>> >>>> On 2010-07-26, at 17:31 , Mark Andrews wrote: >>>> >>>>> In message , Came >>>>> ron Byrne writes: >>>>>> d. IPv6-only networks with NAT64 / DNS64. This option best >>>>>> encourages the use of IPv6 and really gets network and application >>>>>> designers focused on the end-game, not wallowing in some middle-state >>>>>> of CGN / LSN / and endless NAT444. >>>>> Anything for big networks will require some form of address sharing >>>>> between customers. NAT64 / DS-LITE / NAT444. >>>>> >>>>> -- >>>>> Mark Andrews, ISC >>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>>>> _______________________________________________ >>>>> Behave mailing list >>>>> Behave@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/behave >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >> >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From vicmank@rogers.com Tue Aug 3 18:38:51 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE26D3A68F1 for ; Tue, 3 Aug 2010 18:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 fW-eQcOX0+U1 for ; Tue, 3 Aug 2010 18:38:50 -0700 (PDT) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by core3.amsl.com (Postfix) with SMTP id 489BD3A6888 for ; Tue, 3 Aug 2010 18:38:50 -0700 (PDT) Received: (qmail 88466 invoked from network); 4 Aug 2010 01:39:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=UBBGz8NAppZLrl56mZQu5+YEJetJ8sMogxRAOUViZnYXvf6nmPWlb6Bqzjb17bIGTyl0LqTgO29jQ2XljbqLRzf6zcwz0GeW0GAFL/bvARm6hg8Mm+f87MLhJ85FYcldPRufuaXslfTil4mPdN6FrtYJurVKRkDTZpHGQ+JktoM= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1280885958; bh=qVWsCB0SFDIISkSUMchO5oagfc8M1DuMEm6joV/qCPc=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=MukX0XTTTwzX+Qwt0FFMV4VzMb1GuMEGoxwoZU8752LkSNEhnYSPUkW7BEnJpM88asNKeFAuyvzN2E359FcW+jjGO2NVWp2EjjISdL31RIsuQipVwSMWDk2P3k2g3/Lyn6jeUx7Joz+oKbeh/jUX0ZJC/dI0Ono/UvjXJDmoM/Q= Received: from [192.168.100.149] (vicmank@67.224.83.162 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 03 Aug 2010 18:39:16 -0700 PDT X-Yahoo-SMTP: f9g07a.swBDGzI9q2Xty6cZwEaZpJ.WouSaMcQ-- X-YMail-OSG: ob4V68cVM1kaObOYviB9OvgxsDb99kzQlkv2diADBUqzya9 AEULA5.Pu X-Yahoo-Newman-Property: ymail-3 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 03 Aug 2010 21:39:16 -0400 From: Victor Kuarsingh To: Joel Jaeggli , Message-ID: Thread-Topic: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC] Thread-Index: AcszddlL4pniVqaHakidgkkrtMIukQ== In-Reply-To: <4C589E5B.5020704@bogus.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 01:38:51 -0000 Joel, [preface - I have a bias] The basic point being made in [draft-weil-opsawg-provider-address-space] was that of the options (all problematic in some fashion), the reservation of a /8 was the most workable option. I do not think anyone is denying that this option has its problems, but all options have their problems and we are trying to choose one that is least impacting. As noted in the OPSAWG WG session, this (/8 from IANA) was noted as the option that "poses the least challenges". This last statement was made in response to the notion (rightfully so) "protocols like 6to4 would be impacted". (by the way there may be a way around this since it's the example brought up the most) Of the options posed in draft-azinger-additional-private-ipv4-issues, many are not workable. IPv6, although the best solution is just not feasible as a "complete" solution in the very near future in many networks (now till past IPv4 run out) since many vendor systems (CPE space, provider space etc) and upstream applications are just not IPv6 ready now (if anyone does not like this, please contact your local vendor). Of the other solutions, the Class E space is not a realistic option, and address swapping is not likely to work (I would almost assert - impossible given the fiasco that will arise after IPv4 run out). Based on these points, the SP will then be left with a couple of options, have access to a new /8 to provide more race track while IPv6 is put online (remember even some transition options need IPv4 space to glue the CPE to the upstream box like 6RD and NAT444) or camp out on IPv4 space anyway (unrouted IPv4 space that is assigned. If the /8 is not provided, then the latter is likely to occur, which will bring all the problems related to a the proposed option (in draft-weil) plus the added problems which arise when camping on other's IP address space. Victor On 03/08/10 6:55 PM, "Joel Jaeggli" wrote: > On 8/3/10 2:30 PM, Brian E Carpenter wrote: >> Philip, >> >> This draft doesn't actually propose to allocate such space, so the fact that >> some ISPs want it is beside the point of the draft. >> >> There are other drafts that do make such a proposal, but as far as I know >> they >> aren't in Last Call. > > I'm sort of mystified by the intersection of > > draft-azinger-additional-private-ipv4-space-issues > > and > > draft-weil-opsawg-provider-address-space-00 > > which sites it as an informative reference. > > Addressing solutions for dealing with the depletion of the IPv4 > public address space and the lack of available private addresses > within large providers are presented in > [I-D.azinger-additional-private-ipv4-space-issues] as well as > [I-D.shirasaki-nat444-isp-shared-addr]. For larger Service Providers > who require more than the 16 million Net-10 addresses, the preferred > method for addressing the problems presented in both draft documents > is to direct IANA to reserve a /8 from its unassigned IPv4 address > pool. > > > > >> Regards >> Brian >> >> On 2010-08-03 22:08, Philip Matthews wrote: >>> Hmm... Perhaps I missing something, but I just re-read the draft and I >>> didn't see that it was arguing against allocating additional space. It >>> pointed out some problems, but they didn't seem unsurmountable to me. The >>> operators I talked with told me "We know there are problems, but we are >>> willing to live with them, because we really need extra IPv4 space. We HAVE >>> to get extra space from somewhere." >>> Some of the operators I talked with are those behind >>> http://tools.ietf.org/id/draft-weil-opsawg-provider-address-space-00.txt >>> - Philip >>> >>> On 2010-08-02, at 19:18 , Brian E Carpenter wrote: >>> >>>> Philip, >>>> >>>> I have no reason to doubt that many ISPs would like a little bit more >>>> private space. But how does that affect the arguments that any such >>>> space would create problems, which seems to be the point of this draft? >>>> >>>> Regards >>>> Brian >>>> >>>> On 2010-08-03 02:32, Philip Matthews wrote: >>>>> From my discussions with a number of providers at the IETF meeting last >>>>> week, they are all looking for a bit more private address space to provide >>>>> them with a bit of breathing room while they transition to IPv6. Every >>>>> provider that I talked to was working on IPv6 transition, but none of them >>>>> could turn it on overnight. >>>>> - Philip >>>>> >>>>> On 2010-07-26, at 17:31 , Mark Andrews wrote: >>>>> >>>>>> In message >>>>>> , Came >>>>>> ron Byrne writes: >>>>>>> d. IPv6-only networks with NAT64 / DNS64. This option best >>>>>>> encourages the use of IPv6 and really gets network and application >>>>>>> designers focused on the end-game, not wallowing in some middle-state >>>>>>> of CGN / LSN / and endless NAT444. >>>>>> Anything for big networks will require some form of address sharing >>>>>> between customers. NAT64 / DS-LITE / NAT444. >>>>>> >>>>>> -- >>>>>> Mark Andrews, ISC >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>>>>> _______________________________________________ >>>>>> Behave mailing list >>>>>> Behave@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/behave >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Behave mailing list >>>>> Behave@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Tue Aug 3 19:52:43 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB473A6B8E for ; Tue, 3 Aug 2010 19:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 9D2-ed1oBB4d for ; Tue, 3 Aug 2010 19:52:42 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id BB9AB3A68EA for ; Tue, 3 Aug 2010 19:52:42 -0700 (PDT) Received: by qyk8 with SMTP id 8so3561468qyk.10 for ; Tue, 03 Aug 2010 19:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bVWcRPLNMrUSk0Cc/bXPaKz1OM1vU2etcV11zJjHEyk=; b=iG4PkVQpBzMUdw/YF23jcY3AUGp5IuoRnfkF8jyuZbtkVxSwyaQa9QibTY74ZmYzBF srF6nKHPEu5F67s0+9tBwRYT0j0OEIEv/WaSUOTJlNSQhVAYqrekcZLcUrewev1+Nhps AHczr0/XOrxajIPHjYrOi3k81wDsqZO/toE34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=XtKtTclXYavmUMnCNBUZ5ZL3Qx9A1SgzlYiVB5OD2wmgP60yRqp9W5BnIe+NB8m1nf oXwCJY/oQ1x+yPEyX+yz5q96j7LXj1N+M0JBPSE8D5p9U8xipVjgFc0PLCOUD+/uQqgd PwoXpFSsmzZnaSVCG7bia1NzdnCdAZJvlgaFI= Received: by 10.229.214.210 with SMTP id hb18mr1887687qcb.68.1280890391653; Tue, 03 Aug 2010 19:53:11 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id r29sm2393628qcs.13.2010.08.03.19.53.09 (version=SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 19:53:11 -0700 (PDT) Message-ID: <4C58D61D.9060903@gmail.com> Date: Wed, 04 Aug 2010 14:53:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Joel Jaeggli , behave@ietf.org Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 02:52:43 -0000 Victor, > IPv6, although the best solution is just not feasible as > a "complete" solution in the very near future in many networks (now till > past IPv4 run out) since many vendor systems (CPE space, provider space etc) > and upstream applications are just not IPv6 ready now (if anyone does not > like this, please contact your local vendor). Sure. See draft-ietf-v6ops-isp-scenarios. But these are *product* issues, and giving those vendors yet more time to fail to meet a requirement that has been clear since 1996 is surely not the right message. IMHO, the IETF's job (as in draft-azinger-) is to document the problems that extra private space would cause. Regards Brian Carpenter From joelja@bogus.com Wed Aug 4 09:29:44 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2213A69FC for ; Wed, 4 Aug 2010 09:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 119dqvNc5h-M for ; Wed, 4 Aug 2010 09:29:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 356183A69E3 for ; Wed, 4 Aug 2010 09:29:40 -0700 (PDT) Received: from dhcp-183.nokia.net (dhcp-183.nokia.net [192.103.16.183] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o74GU8uM068522 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 4 Aug 2010 16:30:09 GMT (envelope-from joelja@bogus.com) Message-ID: <4C599591.3070301@bogus.com> Date: Wed, 04 Aug 2010 09:30:09 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: 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.2 (nagasaki.bogus.com [147.28.0.81]); Wed, 04 Aug 2010 16:30:09 +0000 (UTC) Cc: behave@ietf.org Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 16:29:44 -0000 Victor... On 8/3/10 6:39 PM, Victor Kuarsingh wrote: > Based on these points, the SP will then be left with a couple of options, > have access to a new /8 to provide more race track while IPv6 is put online > (remember even some transition options need IPv4 space to glue the CPE to > the upstream box like 6RD and NAT444) or camp out on IPv4 space anyway > (unrouted IPv4 space that is assigned. If the /8 is not provided, then the > latter is likely to occur, which will bring all the problems related to a > the proposed option (in draft-weil) plus the added problems which arise when > camping on other's IP address space. That's sounds kind of like a shake-down... Provide us more address-space or we'll kill the baby. The fact of the matter is we're going to employee ugly transition schemes anyway and the question is only when and how many times we're going to pay for it not if... Regarding camping on other's IP space, "hey it's not our fault we're camping on a /8 that got assigned out from under us" is a pretty shallow excuse. It was a business decision to do that before just as it is today and the consequences were known then and now. This comes down to venue shopping. The RIRs can't provide what we think you need anymore so we're here at the IETF dicussing whether to soak up an addtional 16.7 million addresses as rfc1918 space... Heck I'm in favor of that, RFC1918 space isn't big enough for my employer either and we're not even a Cable MSO but I think that probably comes to bear on the point of whether and how long you can expect and justification of fewer collisions with net 10 having any merit. From wwwrun@rfc-editor.org Wed Aug 4 16:48:37 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE5D3A69E1; Wed, 4 Aug 2010 16:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.006 X-Spam-Level: X-Spam-Status: No, score=-102.006 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 2GtyAF2GgcqS; Wed, 4 Aug 2010 16:48:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 340EE3A68E9; Wed, 4 Aug 2010 16:48:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6D2EFE06B3; Wed, 4 Aug 2010 16:49:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100804234906.6D2EFE06B3@rfc-editor.org> Date: Wed, 4 Aug 2010 16:49:06 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 5928 on Traversal Using Relays around NAT (TURN) Resolution Mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 23:48:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5928 Title: Traversal Using Relays around NAT (TURN) Resolution Mechanism Author: M. Petit-Huguenin Status: Standards Track Stream: IETF Date: August 2010 Mailbox: petithug@acm.org Pages: 11 Characters: 23993 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-behave-turn-uri-10.txt URL: http://www.rfc-editor.org/rfc/rfc5928.txt This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. [STANDARDS TRACK] This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From randy@psg.com Thu Aug 5 17:46:09 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672643A6861 for ; Thu, 5 Aug 2010 17:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 OWjKRtpOfMwW for ; Thu, 5 Aug 2010 17:46:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 4C74C3A69E1 for ; Thu, 5 Aug 2010 17:46:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OhB4t-0006lb-DE; Fri, 06 Aug 2010 00:46:27 +0000 Date: Thu, 05 Aug 2010 17:46:26 -0700 Message-ID: From: Randy Bush To: Bob Hinden In-Reply-To: References: <4FAA72A8-6223-4956-9CB1-D3DB4E555209@cisco.com> <4C577BF2.9000807@gmail.com> <148F4D91-A203-4660-B2D1-59808D86A876@cisco.com> <3D4F97DE-E523-4206-BB87-61281C4A73B4@apnic.net> <040401cb332e$2f5ce380$8e16aa80$@com> <86F21EF8-9C98-4C2A-BAF5-29F4AD6D1426@free.fr> <055d01cb334d$65f478d0$31dd6a70$@com> <47295AD4-7F50-4751-A9EC-45D48D928CD7@free.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 v6ops , Behave WG , Dan Wing Subject: Re: [BEHAVE] Avoiding the terminology confusion with NAT66 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 00:46:10 -0000 > I think it's the other way around. To use your example, NAT66 is a > name many people are using to describe all flavors of ice cream. > Margaret's draft is a particular flavor of ice cream. It would be > better to call it chocolate ice cream :-) if it translates addresses, that is sufficiently significant that NAT should be in the name. so chocoNAT is fine with me. or maybe cocoNAT randy From bob.hinden@gmail.com Thu Aug 5 14:40:13 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC28B3A6980 for ; Thu, 5 Aug 2010 14:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] 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 xCXdFdKYVgw1 for ; Thu, 5 Aug 2010 14:40:13 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id CE5BD3A69FC for ; Thu, 5 Aug 2010 14:40:12 -0700 (PDT) Received: by pxi20 with SMTP id 20so3013138pxi.31 for ; Thu, 05 Aug 2010 14:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=iyKXCkPBvVNqevzPGRDXkYK4KvGKfSMMfBMbr8hMuIw=; b=b9e+52GU7q1T/7gWwGdt2G/WifEX8uMorBHC/Ib2OVQmlVfI/BcrkUlJShc7YnvxAl MpVyJ2PBPbnmNM3tnpd5HffDv3i7KmXgFmdRIT1RDY6q8dem36uYY2E/rRwDoZqTRHOb H/WPDZf3xDo0Oz+79uN32W1KB1yPPpTiNgB84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=vOuVUVjkbWZgMKH0GecBKXLFPNeJ4qx6M0HV1Ekg2zotTg3bpe/PGoEsxkt2d6SxfO wiHyrL/HRNUi1zwb6RmSjO5Mc8cvcawHcJmWG0yeEsr6dU/7PAuq7hJcqWISI9tXRrGM vLi4V901s+VI1KL4NAtX7IxkSLTnMDjYLhdwE= Received: by 10.142.199.20 with SMTP id w20mr9579366wff.290.1281044443606; Thu, 05 Aug 2010 14:40:43 -0700 (PDT) Received: from dhcp-209.97.124.227.us.checkpoint.com ([209.97.124.227]) by mx.google.com with ESMTPS id w8sm608054wfd.7.2010.08.05.14.40.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 14:40:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Thu, 5 Aug 2010 14:40:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FAA72A8-6223-4956-9CB1-D3DB4E555209@cisco.com> <4C577BF2.9000807@gmail.com> <148F4D91-A203-4660-B2D1-59808D86A876@cisco.com> <3D4F97DE-E523-4206-BB87-61281C4A73B4@apnic.net> <040401cb332e$2f5ce380$8e16aa80$@com> <86F21EF8-9C98-4C2A-BAF5-29F4AD6D1426@free.fr> <055d01cb334d$65f478d0$31dd6a70$@com> <47295AD4-7F50-4751-A9EC-45D48D928CD7@free.fr> To: Randy Bush X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Thu, 05 Aug 2010 19:10:32 -0700 Cc: IPv6 v6ops , Behave WG , Bob Hinden , Dan Wing Subject: Re: [BEHAVE] Avoiding the terminology confusion with NAT66 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 21:40:14 -0000 Randy, On Aug 3, 2010, at 2:43 PM, Randy Bush wrote: >>> If so, I encourage Margaret and Fred to not use NAT66 for their >>> specification. Rather, "IPv6 Prefix Rewriting". "6pr" almost rolls >>> off the tongue. >> Other names could do it too, e.g. PT66 for prefix translation, or SPT >> for Stateless Prefix Translation, whatever Margaret and:or the >> majority would prefer, provided it isn't NAT66. >=20 > since we're into deceptive marketing, why not call it chocolate ice > cream? I think it's the other way around. To use your example, NAT66 is a name = many people are using to describe all flavors of ice cream. Margaret's = draft is a particular flavor of ice cream. It would be better to call = it chocolate ice cream :-) Bob From bob.hinden@gmail.com Thu Aug 5 18:39:23 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D1C3A6934 for ; Thu, 5 Aug 2010 18:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 CofP2n2hc1U9 for ; Thu, 5 Aug 2010 18:39:22 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 2107D3A66B4 for ; Thu, 5 Aug 2010 18:39:22 -0700 (PDT) Received: by qyk1 with SMTP id 1so3632058qyk.10 for ; Thu, 05 Aug 2010 18:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w1ZkoiXaCqMqliLISiryEUUxD5gJzGOPQlXqRgbe81c=; b=sqRPSomnt1SKG4eCNtmNPnZYezGryr6E/qO1A2BlesmnC1f16vDvbxsI4fogDpVr+f PL2KxKPi/YR5dVi1gFvdVxutMUxLaW430VK/6cVmTWLHdL18+h+6rBSoEOcFV1R9kI3j ELx5rZHILqUVivJurQIxG25IGd42aOYKVnbME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KUv5n0Z2LmBvih++RZDzPs04W8PC5bi6wgcOX88D8jGqvppd0KwjzqKXXD0I0bh1un fCTcTBPQT1T2Rh5Xz6ICOFUQ/+WR750OcatOs7kwe44PtnibowiFoJqnnzqj0ZAdvy+2 Bbm7tsKuumpFY/tlBSXWaZ680dlK8U4kbtBtU= MIME-Version: 1.0 Received: by 10.224.18.22 with SMTP id u22mr5697220qaa.18.1281058792772; Thu, 05 Aug 2010 18:39:52 -0700 (PDT) Received: by 10.229.26.132 with HTTP; Thu, 5 Aug 2010 18:39:52 -0700 (PDT) In-Reply-To: References: <4FAA72A8-6223-4956-9CB1-D3DB4E555209@cisco.com> <4C577BF2.9000807@gmail.com> <148F4D91-A203-4660-B2D1-59808D86A876@cisco.com> <3D4F97DE-E523-4206-BB87-61281C4A73B4@apnic.net> <040401cb332e$2f5ce380$8e16aa80$@com> <86F21EF8-9C98-4C2A-BAF5-29F4AD6D1426@free.fr> <055d01cb334d$65f478d0$31dd6a70$@com> <47295AD4-7F50-4751-A9EC-45D48D928CD7@free.fr> Date: Thu, 5 Aug 2010 18:39:52 -0700 Message-ID: From: Bob Hinden To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 05 Aug 2010 19:10:34 -0700 Cc: IPv6 v6ops , Behave WG , Dan Wing Subject: Re: [BEHAVE] Avoiding the terminology confusion with NAT66 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 01:39:23 -0000 On Thu, Aug 5, 2010 at 5:46 PM, Randy Bush wrote: >> I think it's the other way around. =A0To use your example, NAT66 is a >> name many people are using to describe all flavors of ice cream. >> Margaret's draft is a particular flavor of ice cream. =A0It would be >> better to call it chocolate ice cream :-) > > if it translates addresses, that is sufficiently significant that NAT > should be in the name. =A0so chocoNAT is fine with me. =A0or maybe cocoNA= T > How about pomegraNATe :-) Bob From remi.despres@free.fr Sat Aug 7 05:28:57 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587873A6984 for ; Sat, 7 Aug 2010 05:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3] 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 vlejbt6kLGZp for ; Sat, 7 Aug 2010 05:28:56 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id 227933A694A for ; Sat, 7 Aug 2010 05:28:56 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 93D177000091; Sat, 7 Aug 2010 14:29:27 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 37F6E7000086; Sat, 7 Aug 2010 14:29:26 +0200 (CEST) X-SFR-UUID: 20100807122926229.37F6E7000086@msfrf2108.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 7 Aug 2010 14:29:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19829FFA-1B87-4906-BBA4-FE43A2AF8D3D@free.fr> References: <4FAA72A8-6223-4956-9CB1-D3DB4E555209@cisco.com> <4C577BF2.9000807@gmail.com> <148F4D91-A203-4660-B2D1-59808D86A876@cisco.com> <3D4F97DE-E523-4206-BB87-61281C4A73B4@apnic.net> <040401cb332e$2f5ce380$8e16aa80$@com> <86F21EF8-9C98-4C2A-BAF5-29F4AD6D1426@free.fr> <055d01cb334d$65f478d0$31dd6a70$@com> <47295AD4-7F50-4751-A9EC-45D48D928CD7@free.fr> To: Bob Hinden X-Mailer: Apple Mail (2.1081) Cc: Randy Bush , IPv6 v6ops , Behave WG , Dan Wing Subject: Re: [BEHAVE] Avoiding the terminology confusion with NAT66 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 12:28:57 -0000 Le 5 ao=FBt 2010 =E0 23:40, Bob Hinden a =E9crit : > Randy, >=20 > On Aug 3, 2010, at 2:43 PM, Randy Bush wrote: >=20 >>>> If so, I encourage Margaret and Fred to not use NAT66 for their >>>> specification. Rather, "IPv6 Prefix Rewriting". "6pr" almost = rolls >>>> off the tongue. >>> Other names could do it too, e.g. PT66 for prefix translation, or = SPT >>> for Stateless Prefix Translation, whatever Margaret and:or the >>> majority would prefer, provided it isn't NAT66. >>=20 >> since we're into deceptive marketing, why not call it chocolate ice >> cream? >=20 > I think it's the other way around. To use your example, NAT66 is a = name many people are using to describe all flavors of ice cream. =20 Right > Margaret's draft is a particular flavor of ice cream. =20 > It would be better to call it chocolate ice cream :-) +1 ;-) RD >=20 > Bob >=20 >=20 >=20 From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Aug 6 08:57:45 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0116028C0F3 for ; Fri, 6 Aug 2010 08:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 HO+1Hv9Oyh2v for ; Fri, 6 Aug 2010 08:57:44 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by core3.amsl.com (Postfix) with ESMTP id 1F04D3A6A53 for ; Fri, 6 Aug 2010 08:57:44 -0700 (PDT) Received: from 182-239-166-126.ip.adam.com.au ([182.239.166.126] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1OhPJ6-0002Bl-VG; Sat, 07 Aug 2010 01:28:05 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id DD6513B325; Sat, 7 Aug 2010 01:28:05 +0930 (CST) Date: Sat, 7 Aug 2010 01:28:05 +0930 From: Mark Smith To: Bob Hinden Message-ID: <20100807012805.001b574d@opy.nosense.org> In-Reply-To: References: <4FAA72A8-6223-4956-9CB1-D3DB4E555209@cisco.com> <4C577BF2.9000807@gmail.com> <148F4D91-A203-4660-B2D1-59808D86A876@cisco.com> <3D4F97DE-E523-4206-BB87-61281C4A73B4@apnic.net> <040401cb332e$2f5ce380$8e16aa80$@com> <86F21EF8-9C98-4C2A-BAF5-29F4AD6D1426@free.fr> <055d01cb334d$65f478d0$31dd6a70$@com> <47295AD4-7F50-4751-A9EC-45D48D928CD7@free.fr> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 07 Aug 2010 12:22:46 -0700 Cc: Randy Bush , IPv6 v6ops , Behave WG , Dan Wing Subject: Re: [BEHAVE] Avoiding the terminology confusion with NAT66 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 15:57:45 -0000 On Thu, 5 Aug 2010 18:39:52 -0700 Bob Hinden wrote: > On Thu, Aug 5, 2010 at 5:46 PM, Randy Bush wrote: > >> I think it's the other way around. =C2=A0To use your example, NAT66 is= a > >> name many people are using to describe all flavors of ice cream. > >> Margaret's draft is a particular flavor of ice cream. =C2=A0It would be > >> better to call it chocolate ice cream :-) > > > > if it translates addresses, that is sufficiently significant that NAT > > should be in the name. =C2=A0so chocoNAT is fine with me. =C2=A0or mayb= e cocoNAT > > >=20 > How about pomegraNATe :-) >=20 DefiNATely! > Bob >=20 From prvs=08349dfa1f=simon.leinen@switch.ch Fri Aug 6 12:39:44 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3653A6894 for ; Fri, 6 Aug 2010 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, NO_RELAYS=-0.001] 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 oLFnxoCM39kI for ; Fri, 6 Aug 2010 12:39:43 -0700 (PDT) Received: from caval.switch.ch (caval.switch.ch [IPv6:2001:620:0:14::29]) by core3.amsl.com (Postfix) with ESMTP id D751B3A657C for ; Fri, 6 Aug 2010 12:39:42 -0700 (PDT) Received: from [2001:620:0:4:226:8ff:fe05:cfee] (helo=macsl.switch.ch) by caval.switch.ch with esmtp (Exim 4.69) (envelope-from ) id 1OhSm1-0003x3-HJ; Fri, 06 Aug 2010 21:40:09 +0200 From: Simon Leinen To: Bob Hinden In-Reply-To: (Bob Hinden's message of "Thu, 5 Aug 2010 18:39:52 -0700") References: <4FAA72A8-6223-4956-9CB1-D3DB4E555209@cisco.com> <4C577BF2.9000807@gmail.com> <148F4D91-A203-4660-B2D1-59808D86A876@cisco.com> <3D4F97DE-E523-4206-BB87-61281C4A73B4@apnic.net> <040401cb332e$2f5ce380$8e16aa80$@com> <86F21EF8-9C98-4C2A-BAF5-29F4AD6D1426@free.fr> <055d01cb334d$65f478d0$31dd6a70$@com> <47295AD4-7F50-4751-A9EC-45D48D928CD7@free.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (darwin) X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Fri, 06 Aug 2010 21:40:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SWITCH-SCANNER: bypassed X-Mailman-Approved-At: Sat, 07 Aug 2010 12:22:57 -0700 Cc: Randy Bush , IPv6 v6ops , Behave WG , Dan Wing Subject: Re: [BEHAVE] Avoiding the terminology confusion with NAT66 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 19:39:44 -0000 > How about pomegraNATe :-) As in "Prefix-Only Modification for Enhanced Guidance, which Ran^Hdicals Accuse of Nasty Address-Torturing Evilness"? -- Simon. From wwwrun@core3.amsl.com Mon Aug 9 16:38:25 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0E3C83A68B6; Mon, 9 Aug 2010 16:38:24 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100809233825.0E3C83A68B6@core3.amsl.com> Date: Mon, 9 Aug 2010 16:38:25 -0700 (PDT) Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'Traversal Using Relays around NAT (TURN) Extension for IPv6' to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 23:38:25 -0000 The IESG has approved the following document: - 'Traversal Using Relays around NAT (TURN) Extension for IPv6 ' as a Proposed Standard This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are David Harrington and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-11.txt Technical Summary This specification extends TURN (I-D.ietf-behave-turn) to support IPv6 communications to the remote peer. TURN-IPv6 was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE. Working Group Summary There is good consensus in the WG to publish this document. Document Quality There are already implementations of it. And a significant number of vendors have indicated that they are or will implement it. Personnel Dan Wing, dwing@cisco.com is the Document Shepherd for this document. David Harrington, ietfdbh@comcast.net is the Responsible Area Director. From root@core3.amsl.com Sun Aug 15 23:15:02 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0DA8A3A68AE; Sun, 15 Aug 2010 23:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100816061502.0DA8A3A68AE@core3.amsl.com> Date: Sun, 15 Aug 2010 23:15:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-address-format-10.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 06:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IPv6 Addressing of IPv4/IPv6 Translators Author(s) : C. Bao, et al. Filename : draft-ietf-behave-address-format-10.txt Pages : 19 Date : 2010-08-15 This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-address-format-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-15231232.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Mon Aug 16 11:14:49 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 32D413A6A0F; Mon, 16 Aug 2010 11:14:49 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100816181449.32D413A6A0F@core3.amsl.com> Date: Mon, 16 Aug 2010 11:14:49 -0700 (PDT) Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Document Action: 'Framework for IPv4/IPv6 Translation' to Informational RFC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 18:14:49 -0000 The IESG has approved the following document: - 'Framework for IPv4/IPv6 Translation ' as an Informational RFC This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are David Harrington and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-framework-09.txt Technical Summary This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document describes translation as one of the tools networks might use to facilitate coexistence and ultimate transition. Working Group Summary This document represents WG consensus. Document Quality This is not a protocol and is not implementable. Reviewers are acknowledged in the Acknowledgement section. No special expert review is required. Personnel Dan Wing (dwing@cisco.com) is the document shepherd. David Harrington is the Responsible Area Director. This document requires no IANA action From root@core3.amsl.com Tue Aug 17 06:45:01 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 74EBD3A6980; Tue, 17 Aug 2010 06:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100817134501.74EBD3A6980@core3.amsl.com> Date: Tue, 17 Aug 2010 06:45:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-framework-10.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Framework for IPv4/IPv6 Translation Author(s) : F. Baker, et al. Filename : draft-ietf-behave-v6v4-framework-10.txt Pages : 30 Date : 2010-08-17 This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-framework-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-framework-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-17063728.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Aug 17 08:15:02 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5C0163A6AE4; Tue, 17 Aug 2010 08:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100817151502.5C0163A6AE4@core3.amsl.com> Date: Tue, 17 Aug 2010 08:15:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-21.txt Pages : 33 Date : 2010-08-17 This document forms a replacement of the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-21.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-17080937.I-D@ietf.org> --NextPart-- From ietfdbh@comcast.net Tue Aug 17 21:29:13 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF9F3A689E for ; Tue, 17 Aug 2010 21:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.101 X-Spam-Level: X-Spam-Status: No, score=-102.101 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qqWMvX6Z1ssF for ; Tue, 17 Aug 2010 21:29:13 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id DEDBD3A6896 for ; Tue, 17 Aug 2010 21:29:12 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta08.westchester.pa.mail.comcast.net with comcast id vgVp1e0021GhbT858gVprw; Wed, 18 Aug 2010 04:29:49 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta07.westchester.pa.mail.comcast.net with comcast id vgVo1e0042JQnJT3TgVoaG; Wed, 18 Aug 2010 04:29:49 +0000 From: "David Harrington" To: References: <20100804144139.22450.34184.idtracker@localhost> <4C6A8C78.1030708@cernet.edu.cn> Date: Wed, 18 Aug 2010 00:29:42 -0400 Message-ID: <5A58A850FA0A4F16B60B4DAE4B80F4C5@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <4C6A8C78.1030708@cernet.edu.cn> Thread-Index: Acs+M6fRncFD7GC8T0anyqvIV+pBkAAP2CXg Subject: [BEHAVE] document status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 04:29:14 -0000 Hi WG editors, draft-ietf-behave-v6v4-framework and draft-ietf-behave-address-format and draft-ietf-behave-v6v4-xlate-stateful are no longer under WG control. These documents are now under RFC Editor control. Please do not make any changes or publish any further revisions without explicit instructions from me, the RFC Editor or the document shepherd. If you think a change is needed, then please talk to the document shepherd and me about the proposed change. draft-ietf-behave-v6v4-xlate and draft-ietf-behave-dns64 are also no longer under WG control; they are under IESG control, and no revised ID should be published unless I request it. draft-ietf-behave-v6v4-xlate-21 has been published. I am checking whether it satisfies the DISCUSSes. I know that it does not address one discuss - this document obsoletes RFC2765, and special content is required when a document obsoletes another. I have a question - there are 5 interrelated documents; how many of them obsolete sections of RFC2765? Does each document specify that it obsoletes RFC2765? It should. Please let me know asap so I can figure out the best way to get the necessary edits made. draft-ietf-behave-dns64 never was reviewed by the DNS directorate. We have requested that it be reviewed. There is a discuss related to dnssec, which we hope the directorate review will resolve. Thanks for your hard work, David Harrington Area director IETF Transport Area From huitema@microsoft.com Tue Aug 17 23:17:28 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136D63A68EC for ; Tue, 17 Aug 2010 23:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 M0MPYEhC0jir for ; Tue, 17 Aug 2010 23:17:27 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 2D05B3A690A for ; Tue, 17 Aug 2010 23:17:27 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 17 Aug 2010 23:18:02 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.218.10; Tue, 17 Aug 2010 23:18:02 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.171]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 17 Aug 2010 23:18:02 -0700 From: Christian Huitema To: David Harrington , "behave@ietf.org" Thread-Topic: [BEHAVE] document status Thread-Index: Acs+M6fRncFD7GC8T0anyqvIV+pBkAAP2CXgAAn9QGA= Date: Wed, 18 Aug 2010 06:17:59 +0000 Message-ID: <7CF277500761BD408EA4F0B131539B56024ADCE8@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <20100804144139.22450.34184.idtracker@localhost> <4C6A8C78.1030708@cernet.edu.cn> <5A58A850FA0A4F16B60B4DAE4B80F4C5@23FX1C1> In-Reply-To: <5A58A850FA0A4F16B60B4DAE4B80F4C5@23FX1C1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] document status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 06:17:28 -0000 > I have a question - there are 5 interrelated documents; how many of them= =20 > obsolete sections of RFC2765? Does each document specify that it obsolete= s=20 > RFC2765? It should. Please let me know asap so I can figure out the best = way to get=20 > the necessary edits made.=20 RFC 2765 should be made obsolete by draft-ietf-behave-v6v4-xlate. If you place side by side the table of content of RFC 2765 and the xlate dr= aft, you see that xlate is almost a perfect superset of 2765. The titles ar= e in fact quite similar: "IP/ICMP Translation Algorithm" vs. "Stateless IP= /ICMP Translation Algorithm (SIIT)". Moreover, the abstract of xlate explic= itly states: This document forms a replacement of the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). Seems pretty clear.=20 -- Christian Huitema From rvaithia@cisco.com Wed Aug 18 01:24:46 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E81B3A6A4A; Wed, 18 Aug 2010 01:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 UK-M0MxED4Hp; Wed, 18 Aug 2010 01:24:45 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 59C4D3A6A09; Wed, 18 Aug 2010 01:24:45 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEA2a0yrR7Hu/2dsb2JhbACgR3GhMpt7hTcEhDGIJA X-IronPort-AV: E=Sophos;i="4.56,226,1280707200"; d="scan'208";a="273163162" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2010 08:25:20 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7I8PKOY014375; Wed, 18 Aug 2010 08:25:20 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 01:25:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Aug 2010 01:25:16 -0700 Message-ID: In-Reply-To: <20100817151502.5C0163A6AE4@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt Thread-Index: Acs+H1vwVKCb6PDzT/ashBB4NICzTQAf8PoA References: <20100817151502.5C0163A6AE4@core3.amsl.com> From: "Ramji Vaithianathan (rvaithia)" To: , X-OriginalArrivalTime: 18 Aug 2010 08:25:20.0831 (UTC) FILETIME=[E5A664F0:01CB3EAE] Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 08:24:46 -0000 I have questions on few things that changed as part of version 21, with regards to UDP checksum. > 3.1 Translation IPv4 headers into IPv6 headers > ... > 3.5 Transport-layer Header Translation > If the address translation algorithm is not checksum neutral (Section 3 of [I-D.ietr-behave-address-format]), the=20 > recalculation and updating of the transport-layer headers which contain pseudo headers need to be performed. =20 > Translators MUST do this for TCP and ICMP. For UDP, the translator SHOULD provide a configuration function to turn=20 > on/off the updating of the checksum in the UDP headers. This also includes the case when the translator receives an=20 > unfragmented UDP IPv4 packet and the checksum field is zero. > > 4.1 Translating IPv6 Headers into IPv4 headers > ... > 4.5 Transport-layer Header Translation > If the address translation algorithm is not checksum neutral (Section 3 of [I-d.ietf-behave-address-format]), the=20 > recalculation and updating of the transport-layer headers which contain pseudo headers need to be performed. =20 > Translators MUST do this for TCP and ICMP. For UDP, the translator SHOULD provide a configuration function to turn=20 > on/off the updating of the checksum in the UDP headers. When we translate the packet from IPv6 to IPv4, we can have a configuration function to either calculate the UDP checksum or set it to 0, because UDP checksum is not mandatory in IPv4. Is there an advantage not calculating the UDP checksum - only advantage I can see is to save CPU cycles in the translator. We can always do incremental recalculation which does not look at the entire packet. However when we translate the packet from IPv4 to IPv6, we need to calculate UDP checksum unless we plan to drop the pkt. Here it is mentioned that there should be a configuration function to turn on/off the updating of checksum even for unfragmented UDP IPv4 packet. Any reason why there should be an option to turn off updating checksum for unfragmented UDP IPv4 packet - is it to save the CPU cycles in translator? Do we drop these pkts if the configuration function is set to OFF (no calculation of UDP checksum)? If yes can this be documented clearly? Thanks, Ramji -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, August 17, 2010 8:45 PM To: i-d-announce@ietf.org Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-21.txt Pages : 33 Date : 2010-08-17 This document forms a replacement of the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-21.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From dwing@cisco.com Wed Aug 18 13:53:38 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68703A68E8 for ; Wed, 18 Aug 2010 13:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 bmdOe1xnkXub for ; Wed, 18 Aug 2010 13:53:29 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 799C93A6405 for ; Wed, 18 Aug 2010 13:53:28 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,229,1280707200"; d="scan'208";a="173794012" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 18 Aug 2010 20:54:03 +0000 Received: from dwingWS (sjc-vpn3-751.cisco.com [10.21.66.239]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7IKs31k023975; Wed, 18 Aug 2010 20:54:03 GMT From: "Dan Wing" To: "'Ramji Vaithianathan \(rvaithia\)'" References: <20100817151502.5C0163A6AE4@core3.amsl.com> In-Reply-To: Date: Wed, 18 Aug 2010 13:54:02 -0700 Message-ID: <0c2901cb3f17$7d78af50$786a0df0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs+H1vwVKCb6PDzT/ashBB4NICzTQAf8PoAAB3LpZA= Content-Language: en-us Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:53:38 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Ramji Vaithianathan (rvaithia) > Sent: Wednesday, August 18, 2010 1:25 AM > To: Internet-Drafts@ietf.org; i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt > > I have questions on few things that changed as part of version 21, with > regards to UDP checksum. > > > 3.1 Translation IPv4 headers into IPv6 headers > > ... > > 3.5 Transport-layer Header Translation > > If the address translation algorithm is not checksum neutral (Section > 3 of [I-D.ietr-behave-address-format]), the > > recalculation and updating of the transport-layer headers which > contain pseudo headers need to be performed. > > Translators MUST do this for TCP and ICMP. For UDP, the translator > SHOULD provide a configuration function to turn > > on/off the updating of the checksum in the UDP headers. This also > includes the case when the translator receives an > > unfragmented UDP IPv4 packet and the checksum field is zero. > > > > 4.1 Translating IPv6 Headers into IPv4 headers > > ... > > 4.5 Transport-layer Header Translation > > If the address translation algorithm is not checksum neutral (Section > 3 of [I-d.ietf-behave-address-format]), the > > recalculation and updating of the transport-layer headers which > contain pseudo headers need to be performed. > > Translators MUST do this for TCP and ICMP. For UDP, the translator > SHOULD provide a configuration function to turn > > on/off the updating of the checksum in the UDP headers. > > When we translate the packet from IPv6 to IPv4, we can have a > configuration function to either calculate the UDP checksum or set it > to > 0, because UDP checksum is not mandatory in IPv4. Is there an > advantage > not calculating the UDP checksum - only advantage I can see is to save > CPU cycles in the translator. We can always do incremental > recalculation which does not look at the entire packet. > > However when we translate the packet from IPv4 to IPv6, we need to > calculate UDP checksum unless we plan to drop the pkt. Here it is > mentioned that there should be a configuration function to turn on/off > the updating of checksum even for unfragmented UDP IPv4 packet. Any > reason why there should be an option to turn off updating checksum for > unfragmented UDP IPv4 packet - is it to save the CPU cycles in > translator? Do we drop these pkts if the configuration function is set > to OFF (no calculation of UDP checksum)? If yes can this be > documented > clearly? For IPv6, there is a work-in-progress I-D that allows a zero UDP checksum in some cases (mostly for tunnels where there is another checksum), see draft-ietf-6man-udpzero. This is what caused that change in -21. An informational reference to that work might be sufficient in Section 3.5 of draft-ietf-behave-v6v4-xlate to explain the reason for this configuration function, like: OLD: For UDP, the translator SHOULD provide a configuration function to turn on/off the updating of the checksum in the UDP headers. NEW: For UDP, the translator SHOULD provide a configuration function to turn on/off the updating of the checksum in the UDP headers [I-D.ietf-6man-udpzero]. ...^^^^^^^^^^^^^^^^^^^^^^^ Would that be sufficient? (draft-ietf-behave-v6v4-xlate is being processed by IESG, so we can't make that change without our AD's approval.) -d > Thanks, > > Ramji > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf > Of Internet-Drafts@ietf.org > Sent: Tuesday, August 17, 2010 8:45 PM > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. > > > Title : IP/ICMP Translation Algorithm > Author(s) : X. Li, et al. > Filename : draft-ietf-behave-v6v4-xlate-21.txt > Pages : 33 > Date : 2010-08-17 > > This document forms a replacement of the Stateless IP/ICMP Translation > Algorithm (SIIT) described in RFC 2765. The algorithm translates > between IPv4 and IPv6 packet headers (including ICMP headers). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-21.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rvaithia@cisco.com Wed Aug 18 21:12:54 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6273A6820 for ; Wed, 18 Aug 2010 21:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 O0F5WX4Hvt9w for ; Wed, 18 Aug 2010 21:12:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7AA103A6835 for ; Wed, 18 Aug 2010 21:12:52 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPZDbEyrR7H+/2dsb2JhbACgWHGjTZtuhTcEhDGIKg X-IronPort-AV: E=Sophos;i="4.56,231,1280707200"; d="scan'208";a="575645271" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2010 04:13:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7J4DRgT005859; Thu, 19 Aug 2010 04:13:27 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 21:13:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Aug 2010 21:13:24 -0700 Message-ID: In-Reply-To: <0c2901cb3f17$7d78af50$786a0df0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt Thread-Index: Acs+H1vwVKCb6PDzT/ashBB4NICzTQAf8PoAAB3LpZAADzQesA== References: <20100817151502.5C0163A6AE4@core3.amsl.com> <0c2901cb3f17$7d78af50$786a0df0$@com> From: "Ramji Vaithianathan (rvaithia)" To: "Dan Wing (dwing)" X-OriginalArrivalTime: 19 Aug 2010 04:13:27.0626 (UTC) FILETIME=[DFE412A0:01CB3F54] Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 04:12:54 -0000 Hi Dan, Thanks for the clarification on the [I-D.ietf-6man-udpzero]. For IPv4 --> IPv6 translation, when the configuration function to turn on/off UDP checksum is set to OFF: Do we always set the IPv6 UDP checksum to 0? What happens if the IPv4 UDP checksum is non-zero, do we recalculate the IPv6 UDP checksum or still stamp the IPv6 UDP checksum to 0? =20 If yes is there any real advantage of setting the UDP checksum to 0 in this case IPv4 pkt UDP checksum is non-zero? =20 The translator will be handling pkts that not only for tunnels. So if there is a IPv4 UDP checksum, it would be good to always calculate the IPv6 UDP checksum. Basically the configuration function to turn on/off UDP checksum applies only when IPv4 UDP checksum is zero. Thanks, Ramji -----Original Message----- From: Dan Wing (dwing)=20 Sent: Thursday, August 19, 2010 2:24 AM To: Ramji Vaithianathan (rvaithia) Cc: behave@ietf.org; draft-ietf-behave-v6v4-xlate@tools.ietf.org Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Ramji Vaithianathan (rvaithia) > Sent: Wednesday, August 18, 2010 1:25 AM > To: Internet-Drafts@ietf.org; i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt >=20 > I have questions on few things that changed as part of version 21, with > regards to UDP checksum. >=20 > > 3.1 Translation IPv4 headers into IPv6 headers > > ... > > 3.5 Transport-layer Header Translation > > If the address translation algorithm is not checksum neutral (Section > 3 of [I-D.ietr-behave-address-format]), the > > recalculation and updating of the transport-layer headers which > contain pseudo headers need to be performed. > > Translators MUST do this for TCP and ICMP. For UDP, the translator > SHOULD provide a configuration function to turn > > on/off the updating of the checksum in the UDP headers. This also > includes the case when the translator receives an > > unfragmented UDP IPv4 packet and the checksum field is zero. > > > > 4.1 Translating IPv6 Headers into IPv4 headers > > ... > > 4.5 Transport-layer Header Translation > > If the address translation algorithm is not checksum neutral (Section > 3 of [I-d.ietf-behave-address-format]), the > > recalculation and updating of the transport-layer headers which > contain pseudo headers need to be performed. > > Translators MUST do this for TCP and ICMP. For UDP, the translator > SHOULD provide a configuration function to turn > > on/off the updating of the checksum in the UDP headers. >=20 > When we translate the packet from IPv6 to IPv4, we can have a > configuration function to either calculate the UDP checksum or set it > to > 0, because UDP checksum is not mandatory in IPv4. Is there an > advantage > not calculating the UDP checksum - only advantage I can see is to save > CPU cycles in the translator. We can always do incremental > recalculation which does not look at the entire packet. >=20 > However when we translate the packet from IPv4 to IPv6, we need to > calculate UDP checksum unless we plan to drop the pkt. Here it is > mentioned that there should be a configuration function to turn on/off > the updating of checksum even for unfragmented UDP IPv4 packet. Any > reason why there should be an option to turn off updating checksum for > unfragmented UDP IPv4 packet - is it to save the CPU cycles in > translator? Do we drop these pkts if the configuration function is set > to OFF (no calculation of UDP checksum)? If yes can this be > documented > clearly? For IPv6, there is a work-in-progress I-D that allows a zero UDP checksum in some cases (mostly for tunnels where there is another checksum), see=20 draft-ietf-6man-udpzero. This is what caused that change in -21. An informational reference to that work might be sufficient in Section 3.5=20 of draft-ietf-behave-v6v4-xlate to explain the reason for this configuration function, like: OLD: For UDP, the translator SHOULD provide a configuration function to=20 turn on/off the updating of the checksum in the UDP headers. NEW: For UDP, the translator SHOULD provide a configuration function to=20 turn on/off the updating of the checksum in the UDP headers [I-D.ietf-6man-udpzero]. ...^^^^^^^^^^^^^^^^^^^^^^^ Would that be sufficient? (draft-ietf-behave-v6v4-xlate is being processed by IESG, so we can't make that change without our AD's approval.) -d > Thanks, >=20 > Ramji >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf > Of Internet-Drafts@ietf.org > Sent: Tuesday, August 17, 2010 8:45 PM > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-21.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. >=20 >=20 > Title : IP/ICMP Translation Algorithm > Author(s) : X. Li, et al. > Filename : draft-ietf-behave-v6v4-xlate-21.txt > Pages : 33 > Date : 2010-08-17 >=20 > This document forms a replacement of the Stateless IP/ICMP Translation > Algorithm (SIIT) described in RFC 2765. The algorithm translates > between IPv4 and IPv6 packet headers (including ICMP headers). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-21.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From root@core3.amsl.com Sun Aug 22 19:15:02 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B8A763A691B; Sun, 22 Aug 2010 19:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100823021502.B8A763A691B@core3.amsl.com> Date: Sun, 22 Aug 2010 19:15:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-22.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 02:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-22.txt Pages : 33 Date : 2010-08-22 This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC2765. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-22.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-22190047.I-D@ietf.org> --NextPart-- From xing@cernet.edu.cn Sun Aug 22 19:30:58 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1EE3A68F2; Sun, 22 Aug 2010 19:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.445 X-Spam-Level: X-Spam-Status: No, score=-99.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] 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 lQeODIGmlELi; Sun, 22 Aug 2010 19:30:46 -0700 (PDT) Received: from mail1.chu658.uecomm.net.au (mail1.chu658.uecomm.net.au [218.185.10.246]) by core3.amsl.com (Postfix) with ESMTP id AAD483A687D; Sun, 22 Aug 2010 19:30:25 -0700 (PDT) Received: from [10.0.0.78] (unknown [218.185.71.67]) by mail1.chu658.uecomm.net.au (Postfix) with ESMTP id A580328EA; Mon, 23 Aug 2010 12:30:26 +1000 (EST) Message-ID: <4C71DD48.50305@cernet.edu.cn> Date: Mon, 23 Aug 2010 10:30:32 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20100823021502.B8A763A691B@core3.amsl.com> In-Reply-To: <20100823021502.B8A763A691B@core3.amsl.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-22.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 02:31:21 -0000 X-List-Received-Date: Mon, 23 Aug 2010 02:31:21 -0000 Hi, All, This version refines the text concerning the following issues. (1) Security considerations (2) List changes from RFC2765 (3) UDP checksum update algorithm Regards, xing, congxiao Internet-Drafts@ietf.org дµÀ: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > > Title : IP/ICMP Translation Algorithm > Author(s) : X. Li, et al. > Filename : draft-ietf-behave-v6v4-xlate-22.txt > Pages : 33 > Date : 2010-08-22 > > This document describes the Stateless IP/ICMP Translation Algorithm > (SIIT), which translates between IPv4 and IPv6 packet headers > (including ICMP headers). This document obsoletes RFC2765. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-22.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From wwwrun@core3.amsl.com Mon Aug 23 12:14:12 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A77863A6AB1; Mon, 23 Aug 2010 12:14:10 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100823191411.A77863A6AB1@core3.amsl.com> Date: Mon, 23 Aug 2010 12:14:10 -0700 (PDT) Cc: behave@ietf.org, dthaler@microsoft.com, dwing@cisco.com Subject: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:14:12 -0000 A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Monday, August 30, 2010. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- v9, 2010-08-23 Current Status: Active Working Group Chairs: Dan Wing Dave Thaler Transport Area Director(s): David Harrington Lars Eggert Transport Area Advisor: David Harrington Mailing Lists: General Discussion: behave@ietf.org To Subscribe: behave-request@ietf.org In Body: In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The working group creates documents to enable NATs to function in as deterministic a fashion as possible. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. BEHAVE will adopt additional work items to finish four scenarios: An IPv6 network to IPv4 Internet, IPv6 Internet to an IPv4 network, An IPv6 network to an IPv4 network, and An IPv4 network to an IPv6 network. These additional work items include suggestions to application developers to improve application interactions with those translation scenarios. The following scenario remains in scope for discussion, and new milestones can be created to address this scenario: * An IPv4 application running on an IPv6-only connected host to the IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is embedded in the IPv4 host. The following scenarios remain in scope for discussion, but creating new milestones will require re-chartering: * An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. * IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. * multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requireents for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Done Determine relative prioritization of the four translation cases. Documented in IETF74 minutes. Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done Submit to IESG: relaying of a TCP bytestream (std) Done Submit to IESG: relay protocol (std) Done Submit to IESG: TURN-URI document (std) Done Submit to IESG: IPv6 relay protocol (std) Done Submit to IESG: framework for IPv6/IPv4 translation (info) Done Submit to IESG: stateless IPv6/IPv4 translation (std) Done Submit to IESG: stateful IPv6/IPv4 translation (std) Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Done Determine need and scope of multicast 6/4 translation Aug 2010 Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Dec 2010 Submit to IESG: large scale NAT requirements (BCP) Apr 2011 Submit to IESG: SCTP NAT behavior (BCP) Dec 2010 Submit to IESG: Analysis of NAT-PT considerations with IPv6/ IPv4 translation (info) Dec 2010 Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std) Apr 2011 Submit to IESG: NAT64 load balancing (std/info) Apr 2011 Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std) From ietfdbh@comcast.net Mon Aug 23 17:02:31 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F303A6B3F for ; Mon, 23 Aug 2010 17:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 mtVK1oZM5U6a for ; Mon, 23 Aug 2010 17:02:30 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 3FFAA3A6B3D for ; Mon, 23 Aug 2010 17:02:30 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id xrGK1e0050SCNGk56034YK; Tue, 24 Aug 2010 00:03:04 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta09.westchester.pa.mail.comcast.net with comcast id y0321e00y2JQnJT3V033m8; Tue, 24 Aug 2010 00:03:04 +0000 From: "David Harrington" To: References: <20100804144139.22450.34184.idtracker@localhost><4C6A8C78.1030708@cernet.edu.cn> <5A58A850FA0A4F16B60B4DAE4B80F4C5@23FX1C1> Date: Mon, 23 Aug 2010 20:02:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <5A58A850FA0A4F16B60B4DAE4B80F4C5@23FX1C1> Thread-Index: Acs+M6fRncFD7GC8T0anyqvIV+pBkAAP2CXgASrr+sA= Subject: [BEHAVE] draft-ietf-behave-dns64 - revID needed X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 00:02:31 -0000 Hi draft-ietf-behave-dns64 has now been reviewed by the DNS directorate. There are some other comments that should be addressed as well. Please prepare another revision that addresses all known comments. Thanks for the good work, dbh > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of David Harrington > Sent: Wednesday, August 18, 2010 12:30 AM > To: behave@ietf.org > Subject: [BEHAVE] document status > > Hi WG editors, > > draft-ietf-behave-v6v4-framework and > draft-ietf-behave-address-format and > draft-ietf-behave-v6v4-xlate-stateful are no longer under WG control. > These documents are now under RFC Editor control. > Please do not make any changes or publish any further > revisions without explicit instructions from me, the RFC > Editor or the document shepherd. > If you think a change is needed, then please talk to the > document shepherd and me about the proposed change. > > draft-ietf-behave-v6v4-xlate and draft-ietf-behave-dns64 are > also no longer under WG control; they are under IESG control, > and no revised ID should be published unless I request it. > > draft-ietf-behave-v6v4-xlate-21 has been published. I am > checking whether it satisfies the DISCUSSes. I know that it > does not address one discuss - this document obsoletes > RFC2765, and special content is required when a document > obsoletes another. > > I have a question - there are 5 interrelated documents; how > many of them obsolete sections of RFC2765? Does each document > specify that it obsoletes RFC2765? It should. Please let me > know asap so I can figure out the best way to get the > necessary edits made. > > draft-ietf-behave-dns64 never was reviewed by the DNS > directorate. We have requested that it be reviewed. There is > a discuss related to dnssec, which we hope the directorate > review will resolve. > > Thanks for your hard work, > > David Harrington > Area director > IETF Transport Area > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Wed Aug 25 15:09:58 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF463A6A64; Wed, 25 Aug 2010 15:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 GZKnZ8kFNqKF; Wed, 25 Aug 2010 15:09:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 19A903A63C9; Wed, 25 Aug 2010 15:09:57 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,270,1280707200"; d="scan'208";a="578812528" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2010 22:10:30 +0000 Received: from dwingWS (sjc-vpn4-873.cisco.com [10.21.83.104]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7PMATM3005198; Wed, 25 Aug 2010 22:10:29 GMT From: "Dan Wing" To: , , Date: Wed, 25 Aug 2010 15:10:29 -0700 Message-ID: <0e7b01cb44a2$5454b7a0$fcfe26e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActEok5Ei98zlYfQTuij9lq4TseYww== Content-Language: en-us Subject: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: int-area@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:09:58 -0000 Please send replies to int-area@ietf.org Hi. Andrew and I have written two I-D's describing two approaches to solve a problem that occurs when sharing an IPv4 address (NAPT44, NAPT64, HTTP proxy, A+P, dual-IVI, etc.). The abstract is common between the two approaches and summarizes the problem: When an IP address is shared among several subscribers, it is impossible to determine which subscriber has initiated that TCP connection. This memo describes a technique to share the identity of a subscriber that initiated a TCP connection with the TCP server. The proposed method avoids altering the application-level payload and works well with SSL-protected connections. approach 1, new TCP option: http://tools.ietf.org/html/draft-wing-nat-reveal-option approach 2, overload existing TIMESTAMP TSVal option and IP ID: http://tools.ietf.org/html/draft-yourtchenko-nat-reveal-hash We are leaning towards the new TCP option (approach 1). The idea crosses BEHAVE (NAT), INTAREA (address sharing), and TCPM (TCP option). However, to reduce cross-posting and because INTAREA already has a working group document related to address sharing, I propose we discuss the document on the int-area@ietf.org mailing list. Comments and feedback welcome. -d From tena@huawei.com Sat Aug 28 02:18:36 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B73B3A6832 for ; Sat, 28 Aug 2010 02:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.899 X-Spam-Level: X-Spam-Status: No, score=-99.899 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 dadwXm9nWo1T for ; Sat, 28 Aug 2010 02:18:35 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3CF9C3A67FC for ; Sat, 28 Aug 2010 02:18:34 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7U007QNV7J98@szxga05-in.huawei.com> for behave@ietf.org; Sat, 28 Aug 2010 17:18:55 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7U00NJ0V7J54@szxga05-in.huawei.com> for behave@ietf.org; Sat, 28 Aug 2010 17:18:55 +0800 (CST) Received: from z00147053k ([10.70.39.122]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7U004M9V7IU9@szxml06-in.huawei.com> for behave@ietf.org; Sat, 28 Aug 2010 17:18:55 +0800 (CST) Date: Sat, 28 Aug 2010 17:18:54 +0800 From: Tina TSOU To: behave@ietf.org Message-id: <979A43C06A7B488B93D6FFBA8395A033@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_PxMM7wvoP1/X31NJb8wmUw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 09:18:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_PxMM7wvoP1/X31NJb8wmUw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Behaver, Here is an updated version, thanks to the wonderful review from Med. http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01 It is a short, straight forward I-D. I would like to hear your opinion and more comments. What's the next step for it? B. R. Tina http://tinatsou.weebly.com/index.html --Boundary_(ID_PxMM7wvoP1/X31NJb8wmUw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi Behaver,
Here is an updated version, thanks to the wonderful review from Med.
 
It is a short, straight forward I-D. I would like to hear your opinion and more comments. What's the next step for it?
 
 
--Boundary_(ID_PxMM7wvoP1/X31NJb8wmUw)-- From fred@cisco.com Sat Aug 28 23:08:42 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99B53A67B1; Sat, 28 Aug 2010 23:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.543 X-Spam-Level: X-Spam-Status: No, score=-108.543 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 sSZBk4-IH6fR; Sat, 28 Aug 2010 23:08:41 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 312EE3A67A7; Sat, 28 Aug 2010 23:08:41 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADGWeUyrR7Ht/2dsb2JhbACDF51GcZ1XiWcIkGCBHoMidwSEHxyFTg X-IronPort-AV: E=Sophos;i="4.56,286,1280707200"; d="scan'208";a="246746139" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 29 Aug 2010 06:09:12 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7T694ik004755; Sun, 29 Aug 2010 06:09:06 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Sat, 28 Aug 2010 23:09:12 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Sat, 28 Aug 2010 23:09:12 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <002a01cb4712$d9f72fb0$8de58f10$@com> Date: Sat, 28 Aug 2010 23:08:58 -0700 Message-Id: References: <002a01cb4712$d9f72fb0$8de58f10$@com> To: YangGL X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: Behave WG , huang cancan , "Yiu L. Lee" , IPv6 v6ops , v4tov6transition@ietf.org Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 06:08:43 -0000 May I ask a question? When you say you tested it with NAT64, what did you test with? There are two modes for translation between IPv4 and IPv6. The stateful = mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially = identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to = connect to IPv4 systems but not the reverse. The stateless mode, = described in draft-ietf-behave-v6v4-xlate, allows connections to be = initiated in either direction. The downside of the stateless mode is = that it requires a direct mapping between an IPv4 and an IPv6 address. = The are two parts of a common framework, use the same addressing plan, = and the same DNS extension. Are you running both modes, or only the stateful mode? If you are only = running the stateful mode, that what you're reporting is what we have = been saying for some time it will behave like. http://datatracker.ietf.org/doc/draft-ietf-behave-address-format http://tools.ietf.org/html/draft-ietf-behave-address-format "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10, http://datatracker.ietf.org/doc/draft-ietf-behave-dns64 http://tools.ietf.org/html/draft-ietf-behave-dns64 "DNS64: DNS extensions for Network Address Translation from IPv6 = Clients to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, Iljitsch van Beijnum, 5-Jul-10, http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao Bao, Kevin Yin, 17-Aug-10, http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, 22-Aug-10, http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch = van Beijnum, 12-Jul-10, On Aug 28, 2010, at 5:40 PM, YangGL wrote: > Tests in my lab have proved that many popular applications cannot work = on IPv6-only network with NAT64, such as IM, P2P, games, and part of = video. WEB and part of mail (Outlook and Outlook express) are the only = applications we can find working properly with NAT64. But there are more = than 50% traffic is P2P, WEB traffic is less than 20% on CT=A1=AFs = network. I think it is not a good news to NAT64. > Tests also prove that almost all of popular applications on Internet = can work on IPv4-only network with single level and double level NAT44, = such as WEB, mail, IM, P2P, games, video and etc. > NAT64 and NAT44 are similar in theory. But what make the difference of = application support? I think it should be timing. NAT44 appears ten = years ago. There are a few applications on internet at that time. = Subsequent applications, such as IM, P2P, were designed to work with = NAT44. NAT64 come after this popular applications, situation is totally = different. If NAT64 is deployed on commercial network now, CT=A1=AFs = network traffic will cut down 70% immediately, and most applications = will release a new version for IPv6-only or NAT64 in the next one year. = But it is not a good idea to providers. > =20 > Best regards, > Yang Guoliang > =20 > =B7=A2=BC=FE=C8=CB: v4tov6transition-bounces@ietf.org = [mailto:v4tov6transition-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA8=D4=C225=C8=D5 22:05 > =CA=D5=BC=FE=C8=CB: huang cancan > =B3=AD=CB=CD: Kurt Erik Lindqvist; IPv6 v6ops; = v4tov6transition@ietf.org > =D6=F7=CC=E2: Re: [v4tov6transition] = draft-arkko-ipv6-transition-guidelines WGLC > =20 > =46rom user=A1=AFs perspective, do they care IPv4 or IPv6? Most = don=A1=AFt. For example: a casual web user wants to access his/her = favorite IPv4-only website. If his web client and PC support IPv6 and on = an IPv6-only network with NAT64, the web traffic will go through the NAT = once. If his web client and PC support IPv4-only on an IPv4 network with = NAT444, the web traffic will go through the NAT twice. In the end, = he/she still gets the same content. =46rom this perspective, both = experience =A1=B0could be=A1=B1 very similar.=20 >=20 > However, this use case is rather limited and not applicable to many = applications. This is why I said =A1=B0could be=A1=B1. Also, both = Cameron and I agree that this is easier to implement IPv6-only on mobile = network than on fixed network because mobile operators have more control = over the devices and apps. IMHO, it will take longer time for fixed = network operators to support NAT64 only solution in the network. >=20 >=20 > On 8/25/10 9:41 AM, "huang cancan" wrote: >=20 > well, I mean: why customer experience of IPv4-only + NAT444 could be = the same as IPv6-only + NAT64? >=20 > On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee = wrote: > In order to deploy IPv6-only + NAT64, the client and network must talk = IPv6. It also requires DNS64. These requirements are not needed for = IPv4-only + NAT444. =46rom the deployment point of view, they are very = different technologies.=20 >=20 >=20 >=20 > On 8/25/10 7:13 AM, "huang cancan" > wrote: >=20 > hi,Yiu: > As you mentioned below: > > All I am saying is the customer > > experience of IPv4-only + NAT444 could be the same as IPv6-only + = NAT64, but > > the technologies and plan to offer these service are very different. > =20 > Do you have any test data to support this conclusion? > =20 > Can-can Huang >=20 >=20 > On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee > wrote: >=20 > > Agreed. The 2x cost is really just the packet core ... which is of > > course a lot of money to double for no tangible benefit ..... talk > > about no business case .... And, still have numbering issues, = customer > > experience is the same as IPv4-only + NAT44 and approximately the = same > > as IPv6-only + NAT64 > > > Life cycle of mobile equipments could be every 2-3 years, but life = cycle of > consumer electronics could be 5+ years. Consider many large TVs with > Internet service selling today are still running IPv4-only, fixed line > operators must prepare to support them in foreseeable future. >=20 > That said, I am not saying an operator must build a dual-stack core = network, > there are technologies such as DS-lite and Softwire Mesh available to = run a > pure IPv6 core network with dual-stack edge. All I am saying is the = customer > experience of IPv4-only + NAT444 could be the same as IPv6-only + = NAT64, but > the technologies and plan to offer these service are very different. >=20 >=20 >=20 > _______________________________________________ > v4tov6transition mailing list > v4tov6transition@ietf.org =20 > https://www.ietf.org/mailman/listinfo/v4tov6transition > =20 >=20 > =20 >=20 > _______________________________________________ > v4tov6transition mailing list > v4tov6transition@ietf.org > https://www.ietf.org/mailman/listinfo/v4tov6transition From dwing@cisco.com Sun Aug 29 21:29:35 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0AF3A690E for ; Sun, 29 Aug 2010 21:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.74 X-Spam-Level: X-Spam-Status: No, score=-108.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 TzOizBjcL-FA for ; Sun, 29 Aug 2010 21:29:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 68B033A68FA for ; Sun, 29 Aug 2010 21:29:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB7RekxAZnwN/2dsb2JhbACUQIwHcZ8Imm+CboJJBIQ7 X-IronPort-AV: E=Sophos;i="4.56,290,1280707200"; d="scan'208";a="153294881" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Aug 2010 04:30:05 +0000 Received: from dwingWS (sjc-vpn6-660.cisco.com [10.21.122.148]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7U4U4uT012783; Mon, 30 Aug 2010 04:30:05 GMT From: "Dan Wing" To: "'Tina TSOU'" , References: <979A43C06A7B488B93D6FFBA8395A033@china.huawei.com> In-Reply-To: <979A43C06A7B488B93D6FFBA8395A033@china.huawei.com> Date: Sun, 29 Aug 2010 21:30:04 -0700 Message-ID: <08d101cb47fc$05140580$0f3c1080$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActGkh3Xa3IZ1z89TNa3B4CfP+cSkgBZ8+DA Content-Language: en-us Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 04:29:35 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Tina TSOU > Sent: Saturday, August 28, 2010 2:19 AM > To: behave@ietf.org > Subject: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs > > Hi Behaver, > Here is an updated version, thanks to the wonderful review from Med. > http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01 > > It is a short, straight forward I-D. I would like to hear your opinion > and more comments. What's the next step for it? Should the block-allocated source ports be re-used? If so, can text be added to describe advantages / disadvantages of such re-use? Can a NAT operator determine when a server operator is logging the source port? What is the impact if a server is not logging the source port? For example, what happens if a subscriber made a post to a web server and law enforcement asked the ISP for the identity of the subscriber, but the server didn't log the source port? This seems to place the ISP in a difficult situation, requiring the ISP to reveal the identity of all subscribers that were using that IP address at that time. In an appendix it would be useful to provide configuration examples for popular server software to log the source port (e.g., Apache, IIS, Postfix, Sendmail, sshd, Cyrus IMAP, UW IMAP). For example, I believe it was in Apache version 2.1 that added the ability to log the source port using "%{remote}p" described at http://httpd.apache.org/docs/2.1/mod/mod_log_config.html. And be sure to mention that, for all log file modifications, the source port needs to be added to the log in a way that will work with the server's log analysis scripts. -d From iesg-secretary@ietf.org Mon Aug 30 06:51:30 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0803A3A6811; Mon, 30 Aug 2010 06:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 I2IMXjS7oR1K; Mon, 30 Aug 2010 06:51:28 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A597C3A6822; Mon, 30 Aug 2010 06:51:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20100830135127.14760.89557.idtracker@localhost> Date: Mon, 30 Aug 2010 06:51:27 -0700 Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'IPv6 Addressing of IPv4/IPv6 Translators' to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 13:51:30 -0000 The IESG has approved the following document: - 'IPv6 Addressing of IPv4/IPv6 Translators' as a Proposed Standard This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are David Harrington and Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-behave-address-format/ Technical Summary This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. Working Group Summary This document represents the WG consensus that accommodates different approaches for the different scenarios Behave was chartered to solve. Document Quality This document is not a protocol, but there are implementations in progress, e.g. http://www.ietf.org/mail-archive/web/behave/current/msg08102.html Several vendors are actively implementing the specification. Special reviewers are listed in the document's acknowledgement section. Personnel Who is the Document Shepherd for this document? Dave Thaler Who is the Responsible Area Director? David Harrington The document doesn't require IANA experts. RFC Editor Note Please be sure IPv6 hex addresses are represented in lowercase hex, as per draft-ietf-6man-text-representation. From iesg-secretary@ietf.org Mon Aug 30 08:02:03 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16AFB3A687A; Mon, 30 Aug 2010 08:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uvgMnL0IR4rY; Mon, 30 Aug 2010 08:02:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD97D3A6888; Mon, 30 Aug 2010 08:02:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20100830150201.8385.94255.idtracker@localhost> Date: Mon, 30 Aug 2010 08:02:01 -0700 Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers' to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 15:02:03 -0000 The IESG has approved the following document: - 'Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers' as a Proposed Standard This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are David Harrington and Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful/ Technical Summary This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. The public IPv4 address can be shared among several IPv6-only clients. When the stateful NAT64 is used in conjunction with DNS64 no changes are usually required in the IPv6 client or the IPv4 server. Working Group Summary The document represents WG consensus Document Quality several vendors are actively implementing the specification. Personnel Responsible AD: David Harrington Dave Thaler (dthaler@microsoft.com) is the document shepherd. The document doesn't require IANA experts. RFC Editor Notes 1. Please provide an informational reference to RFC 5245 for ICE, and RFC 5389 for STUN, and expand the terms on first use. 2. Among the contributors, s/Parreault/Perreault/ 4. Please be sure IPv6 hex addresses are represented in lowercase hex, as per draft-ietf-6man-text-representation. 5. in 3.5.1.1 and in 3.5.2.3 OLD: In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but MAY be in use in the other BIB (referring to the UDP and TCP BIBs) NEW: In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but can be in use in other BIBs (e.g., the UDP and TCP BIBs) From cancanhuang110@gmail.com Mon Aug 30 02:03:45 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09453A679F; Mon, 30 Aug 2010 02:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45] 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 25D9SnSLEGlH; Mon, 30 Aug 2010 02:03:35 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3ED543A67C2; Mon, 30 Aug 2010 02:03:34 -0700 (PDT) Received: by bwz9 with SMTP id 9so4311408bwz.31 for ; Mon, 30 Aug 2010 02:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dPI9AMdPORiar01kN2n2ovLxEvPhGfWlrkdy5KeM+H0=; b=Ls5HvkwR0dKpc41wUG8k+w5DHMsaNjP2nCnabfNs94Bx+tztmWZBlwsSYoyMKEAc8V WSlVs1UldpinOrNITXPCCque5VSmJuyBl6WXmyPFM3bE7j94ONoqY9lDtrRQ+SYzd8iv A/ej863rj8ItbK6NVeoPWM6htP3d5L86yO7/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wlS3Y4qq9uVsVSblHzVqaH+428d/yT8tHAGkvOBOhAXUgG/CQVZos7rLzaH8qyohyA pIA0Z61QGr2A7AUXKUralJDWnOMCerGLn3DUmEzwB2YbM7WDtnvQs8F34c9bIA8+Ztct 1Li+6YCw0euNwO99bbPrfJh9G+SYwd12SO6Qo= MIME-Version: 1.0 Received: by 10.204.85.90 with SMTP id n26mr3004942bkl.109.1283159044775; Mon, 30 Aug 2010 02:04:04 -0700 (PDT) Received: by 10.204.161.193 with HTTP; Mon, 30 Aug 2010 02:04:04 -0700 (PDT) In-Reply-To: References: <002a01cb4712$d9f72fb0$8de58f10$@com> Date: Mon, 30 Aug 2010 17:04:04 +0800 Message-ID: From: huang cancan To: Fred Baker Content-Type: multipart/alternative; boundary=0016e6db5c280de04d048f06bf12 X-Mailman-Approved-At: Mon, 30 Aug 2010 09:36:41 -0700 Cc: Behave WG , YangGL , "Yiu L. Lee" , IPv6 v6ops , v4tov6transition@ietf.org Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 09:03:45 -0000 --0016e6db5c280de04d048f06bf12 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,Fred: We test the statful one and hadn't test the statless one, because there is no commercial device supporting DIVI. 2010/8/29 Fred Baker > > > > May I ask a question? > > When you say you tested it with NAT64, what did you test with? > > There are two modes for translation between IPv4 and IPv6. The stateful > mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially > identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to connec= t > to IPv4 systems but not the reverse. The stateless mode, described in > draft-ietf-behave-v6v4-xlate, allows connections to be initiated in eithe= r > direction. The downside of the stateless mode is that it requires a direc= t > mapping between an IPv4 and an IPv6 address. The are two parts of a commo= n > framework, use the same addressing plan, and the same DNS extension. > > Are you running both modes, or only the stateful mode? If you are only > running the stateful mode, that what you're reporting is what we have bee= n > saying for some time it will behave like. > > http://datatracker.ietf.org/doc/draft-ietf-behave-address-format > http://tools.ietf.org/html/draft-ietf-behave-address-format > "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian > Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10, > > > http://datatracker.ietf.org/doc/draft-ietf-behave-dns64 > http://tools.ietf.org/html/draft-ietf-behave-dns64 > "DNS64: DNS extensions for Network Address Translation from IPv6 Clients > to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, > Iljitsch van Beijnum, 5-Jul-10, > > http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework > http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework > "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao > Bao, Kevin Yin, 17-Aug-10, > > http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate > "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, > 22-Aug-10, > > http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful > "Stateful NAT64: Network Address and Protocol Translation from IPv6 > Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van > Beijnum, 12-Jul-10, > > > On Aug 28, 2010, at 5:40 PM, YangGL wrote: > > > Tests in my lab have proved that many popular applications cannot work = on > IPv6-only network with NAT64, such as IM, P2P, games, and part of video. = WEB > and part of mail (Outlook and Outlook express) are the only applications = we > can find working properly with NAT64. But there are more than 50% traffic= is > P2P, WEB traffic is less than 20% on CT=A1=AFs network. I think it is not= a good > news to NAT64. > > Tests also prove that almost all of popular applications on Internet ca= n > work on IPv4-only network with single level and double level NAT44, such = as > WEB, mail, IM, P2P, games, video and etc. > > NAT64 and NAT44 are similar in theory. But what make the difference of > application support? I think it should be timing. NAT44 appears ten years > ago. There are a few applications on internet at that time. Subsequent > applications, such as IM, P2P, were designed to work with NAT44. NAT64 co= me > after this popular applications, situation is totally different. If NAT64= is > deployed on commercial network now, CT=A1=AFs network traffic will cut do= wn 70% > immediately, and most applications will release a new version for IPv6-on= ly > or NAT64 in the next one year. But it is not a good idea to providers. > > > > Best regards, > > Yang Guoliang > > > > =B7=A2=BC=FE=C8=CB: v4tov6transition-bounces@ietf.org [mailto: > v4tov6transition-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee > > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA8=D4=C225=C8=D5 22:05 > > =CA=D5=BC=FE=C8=CB: huang cancan > > =B3=AD=CB=CD: Kurt Erik Lindqvist; IPv6 v6ops; v4tov6transition@ietf.or= g > > =D6=F7=CC=E2: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidel= ines WGLC > > > > From user=A1=AFs perspective, do they care IPv4 or IPv6? Most don=A1=AF= t. For > example: a casual web user wants to access his/her favorite IPv4-only > website. If his web client and PC support IPv6 and on an IPv6-only networ= k > with NAT64, the web traffic will go through the NAT once. If his web clie= nt > and PC support IPv4-only on an IPv4 network with NAT444, the web traffic > will go through the NAT twice. In the end, he/she still gets the same > content. From this perspective, both experience =A1=B0could be=A1=B1 very= similar. > > > > However, this use case is rather limited and not applicable to many > applications. This is why I said =A1=B0could be=A1=B1. Also, both Cameron= and I agree > that this is easier to implement IPv6-only on mobile network than on fixe= d > network because mobile operators have more control over the devices and > apps. IMHO, it will take longer time for fixed network operators to suppo= rt > NAT64 only solution in the network. > > > > > > On 8/25/10 9:41 AM, "huang cancan" wrote: > > > > well, I mean: why customer experience of IPv4-only + NAT444 could be th= e > same as IPv6-only + NAT64? > > > > On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee > wrote: > > In order to deploy IPv6-only + NAT64, the client and network must talk > IPv6. It also requires DNS64. These requirements are not needed for > IPv4-only + NAT444. From the deployment point of view, they are very > different technologies. > > > > > > > > On 8/25/10 7:13 AM, "huang cancan" http://cancanhuang110@gmail.com> > wrote: > > > > hi,Yiu: > > As you mentioned below: > > > All I am saying is the customer > > > experience of IPv4-only + NAT444 could be the same as IPv6-only + > NAT64, but > > > the technologies and plan to offer these service are very different. > > > > Do you have any test data to support this conclusion? > > > > Can-can Huang > > > > > > On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee http://yiu_lee@cable.comcast.com> > wrote: > > > > > Agreed. The 2x cost is really just the packet core ... which is of > > > course a lot of money to double for no tangible benefit ..... talk > > > about no business case .... And, still have numbering issues, custome= r > > > experience is the same as IPv4-only + NAT44 and approximately the sam= e > > > as IPv6-only + NAT64 > > > > > Life cycle of mobile equipments could be every 2-3 years, but life cycl= e > of > > consumer electronics could be 5+ years. Consider many large TVs with > > Internet service selling today are still running IPv4-only, fixed line > > operators must prepare to support them in foreseeable future. > > > > That said, I am not saying an operator must build a dual-stack core > network, > > there are technologies such as DS-lite and Softwire Mesh available to r= un > a > > pure IPv6 core network with dual-stack edge. All I am saying is the > customer > > experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64= , > but > > the technologies and plan to offer these service are very different. > > > > > > > > _______________________________________________ > > v4tov6transition mailing list > > v4tov6transition@ietf.org > > https://www.ietf.org/mailman/listinfo/v4tov6transition > > > > > > > > > > _______________________________________________ > > v4tov6transition mailing list > > v4tov6transition@ietf.org > > https://www.ietf.org/mailman/listinfo/v4tov6transition > > --0016e6db5c280de04d048f06bf12 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi,Fred:
   We test the statful one and hadn't test the statless = one, because there is no commercial device supporting DIVI.
   
 
 
2010/8/29 Fred Baker <fred@cisco.com>
</chair> <!-- v6ops --&= gt;
<author> <!-- draft-ietf-behave-v6v4-xlate -->

Ma= y I ask a question?

When you say you tested it with NAT64, what did you test with?

T= here are two modes for translation between IPv4 and IPv6. The stateful mode= , described in draft-ietf-behave-v6v4-xlate-stateful, is essentially identi= cal in function to IPv4/IPv4 NAT, and allows IPv6 systems to connect to IPv= 4 systems but not the reverse. The stateless mode, described in draft-ietf-= behave-v6v4-xlate, allows connections to be initiated in either direction. = The downside of the stateless mode is that it requires a direct mapping bet= ween an IPv4 and an IPv6 address. The are two parts of a common framework, = use the same addressing plan, and the same DNS extension.

Are you running both modes, or only the stateful mode? If you are only = running the stateful mode, that what you're reporting is what we have b= een saying for some time it will behave like.

ht= tp://datatracker.ietf.org/doc/draft-ietf-behave-address-format
http://tools.ietf.org/html/draft-ietf-behave-address-format<= /a>
 "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao= Bao, Christian
 Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10,
=  <draft-ietf-behave-address-format-10.txt>

htt= p://datatracker.ietf.org/doc/draft-ietf-behave-dns64
http://tools.ietf.org/html/draft-ietf-behave-dns64
 "= ;DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matt= hews,
 Iljitsch van Beijnum, 5-Jul-10, <draft-ietf-behave-dns64-10.txt>= ;

http://datatracker.ietf.org/doc/draft-ietf-beh= ave-v6v4-framework
http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework<= /a>
 "Framework for IPv4/IPv6 Translation", Fred Baker, X= ing Li, Congxiao
 Bao, Kevin Yin, 17-Aug-10, <draft-ietf-behave-v6v4-framework-10.tx= t>

http://datatracker.ietf.org/doc/draft-ietf-beh= ave-v6v4-xlate
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate
=  "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fre= d Baker,
 22-Aug-10, <draft-ietf-behave-v6v4-xlate-22.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xl= ate-stateful
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate= -stateful
 "Stateful NAT64: Network Address and Protocol T= ranslation from IPv6
 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Ilji= tsch van
 Beijnum, 12-Jul-10, <draft-ietf-behave-v6v4-xlate-stat= eful-12.txt>


On Aug 28, 2010, at 5:40 PM, YangGL wrote:
> Tests in my lab have proved that many popular applications cannot wor= k on IPv6-only network with NAT64, such as IM, P2P, games, and part of vide= o. WEB and part of mail (Outlook and Outlook express) are the only applicat= ions we can find working properly with NAT64. But there are more than 50% t= raffic is P2P, WEB traffic is less than 20% on CT’s network. I think = it is not a good news to NAT64.
> Tests also prove that almost all of popular applications on Internet c= an work on IPv4-only network with single level and double level NAT44, such= as WEB, mail, IM, P2P, games, video and etc.
> NAT64 and NAT44 are s= imilar in theory. But what make the difference of application support? I th= ink it should be timing. NAT44 appears ten years ago. There are a few appli= cations on internet at that time. Subsequent applications, such as IM, P2P,= were designed to work with NAT44. NAT64 come after this popular applicatio= ns, situation is totally different. If NAT64 is deployed on commercial netw= ork now, CT’s network traffic will cut down 70% immediately, and most= applications will release a new version for IPv6-only or NAT64 in the next= one year. But it is not a good idea to providers.
>
> Best regards,
> Yang Guoliang
>
> =B7=A2=BC= =FE=C8=CB: v4tov6trans= ition-bounces@ietf.org [mailto:v4tov6transition-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee=
> =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA8=D4=C225=C8=D5 22:05
> =CA= =D5=BC=FE=C8=CB: huang cancan
> =B3=AD=CB=CD: Kurt Erik Lindqvist; IP= v6 v6ops; v4tov6transition@iet= f.org
> =D6=F7=CC=E2: Re: [v4tov6transition] draft-arkko-ipv6-tra= nsition-guidelines WGLC
>
> From user’s perspective, do they care IPv4 or IPv6? Most= don’t. For example: a casual web user wants to access his/her favori= te IPv4-only website. If his web client and PC support IPv6 and on an IPv6-= only network with NAT64, the web traffic will go through the NAT once. If h= is web client and PC support IPv4-only on an IPv4 network with NAT444, the = web traffic will go through the NAT twice. In the end, he/she still gets th= e same content. From this perspective, both experience “could be&rdqu= o; very similar.
>
> However, this use case is rather limited and not applicable to= many applications. This is why I said “could be”. Also, both C= ameron and I agree that this is easier to implement IPv6-only on mobile net= work than on fixed network because mobile operators have more control over = the devices and apps. IMHO, it will take longer time for fixed network oper= ators to support NAT64 only solution in the network.
>
>
> On 8/25/10 9:41 AM, "huang cancan" <cancanhuang110@gmail.com> wro= te:
>
> well, I mean: why customer experience of IPv4-only + NA= T444 could be the same as IPv6-only + NAT64?
>
> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <yiu_lee@cable.comcast.com> wrote:
= > In order to deploy IPv6-only + NAT64, the client and network must talk= IPv6. It also requires DNS64. These requirements are not needed for IPv4-o= nly + NAT444. From the deployment point of view, they are very different te= chnologies.
>
>
>
> On 8/25/10 7:13 AM, "huang cancan" &= lt;cancanhuang110@gmail.com= <http://cancanhuan= g110@gmail.com> = > wrote:
>
> hi,Yiu:
>   As you mentioned below:
> > Al= l I am saying is the customer
> > experience of IPv4-only + NAT444= could be the same as IPv6-only + NAT64, but
> > the technologies = and plan to offer these service are very different.
>
>   Do you have any test data to support this conclusion?>
> Can-can Huang
>
>
> On Sat, Aug 21, 2010 a= t 7:37 AM, Yiu L. Lee <yiu_= lee@cable.comcast.com <http://yiu_lee@cable.comcast.com> > wrote:
>
> > Agreed.  The 2x cost is really just the packet core = ... which is of
> > course a lot of money to double for no tangibl= e benefit ..... talk
> > about no business case .... And, still ha= ve numbering issues, customer
> > experience is the same as IPv4-only + NAT44 and approximately the= same
> > as IPv6-only + NAT64
> >
> Life cycle of = mobile equipments could be every 2-3 years, but life cycle of
> consu= mer electronics could be 5+ years. Consider many large TVs with
> Internet service selling today are still running IPv4-only, fixed line=
> operators must prepare to support them in foreseeable future.
&= gt;
> That said, I am not saying an operator must build a dual-stack = core network,
> there are technologies such as DS-lite and Softwire Mesh available to = run a
> pure IPv6 core network with dual-stack edge. All I am saying = is the customer
> experience of IPv4-only + NAT444 could be the same = as IPv6-only + NAT64, but
> the technologies and plan to offer these service are very different.>
>
>
> ____________________________________________= ___
> v4tov6transition mailing list
> v4tov6transition@ietf.org <http://v4tov6transition@ietf.org>
> https://www.ietf.org/mailman/listinfo/v4tov6transition>
>
>
>
> ____________________________________= ___________
> v4tov6transition mailing list
> v4tov6transition@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v4tov6transition


--0016e6db5c280de04d048f06bf12-- From cancanhuang110@gmail.com Mon Aug 30 02:26:09 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC1D3A67AB; Mon, 30 Aug 2010 02:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.322 X-Spam-Level: X-Spam-Status: No, score=-0.322 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45] 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 NiQXQUh15ieC; Mon, 30 Aug 2010 02:25:57 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 99E673A679F; Mon, 30 Aug 2010 02:25:56 -0700 (PDT) Received: by bwz9 with SMTP id 9so4323610bwz.31 for ; Mon, 30 Aug 2010 02:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=JXuMpzdd1F5CVvhl2oXqOgPK8EnYdtlvcFgOpKDWQj4=; b=uNxCgfbLFk/u0ji0He8Ac+s0If6hJRwNxhZAtJkdkw72YcbHh9uxwd6ipj0jS9UF/2 cwS8uA1R3YuFQz1uCk6vet8vK90HrRQ5rP5NEPSdcPRaiA7fk/D+l5qSOMSPNMC9p67K V/7OcqEyWL9c4kjZUjHuSdVKv0CcyOGsl/fKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xEIzMF7GuARn40QpKC1o80Fd/Knd7hpEA0MFT2SVnbhil+XOt1nwtK4x3G05I4ivYM 3BlaBUdmLm/BXeEW2HDIQAGGjkhVcb9ts0pzxle/s8HQyZeFX/ohZGdAtIAuva2fmKm3 Rnn2TDE+5HhCtU/JcwooNe4vDvuZ3h5ZnMSps= MIME-Version: 1.0 Received: by 10.204.103.9 with SMTP id i9mr1823497bko.192.1283160386970; Mon, 30 Aug 2010 02:26:26 -0700 (PDT) Received: by 10.204.161.193 with HTTP; Mon, 30 Aug 2010 02:26:26 -0700 (PDT) In-Reply-To: References: <002a01cb4712$d9f72fb0$8de58f10$@com> Date: Mon, 30 Aug 2010 17:26:26 +0800 Message-ID: From: huang cancan To: Fred Baker Content-Type: multipart/alternative; boundary=001636c5979b0e29fe048f070fb5 X-Mailman-Approved-At: Mon, 30 Aug 2010 09:36:42 -0700 Cc: Behave WG , YangGL , "Yiu L. Lee" , IPv6 v6ops , v4tov6transition@ietf.org Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 09:26:09 -0000 --001636c5979b0e29fe048f070fb5 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Another reason why we don't test stateless NAT64 is that there are few application clients support IPv6, we can only test web or mail applications which are also OK with the stateful one. 2010/8/29 Fred Baker > > > > May I ask a question? > > When you say you tested it with NAT64, what did you test with? > > There are two modes for translation between IPv4 and IPv6. The stateful > mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially > identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to connec= t > to IPv4 systems but not the reverse. The stateless mode, described in > draft-ietf-behave-v6v4-xlate, allows connections to be initiated in eithe= r > direction. The downside of the stateless mode is that it requires a direc= t > mapping between an IPv4 and an IPv6 address. The are two parts of a commo= n > framework, use the same addressing plan, and the same DNS extension. > > Are you running both modes, or only the stateful mode? If you are only > running the stateful mode, that what you're reporting is what we have bee= n > saying for some time it will behave like. > > http://datatracker.ietf.org/doc/draft-ietf-behave-address-format > http://tools.ietf.org/html/draft-ietf-behave-address-format > "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian > Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10, > > > http://datatracker.ietf.org/doc/draft-ietf-behave-dns64 > http://tools.ietf.org/html/draft-ietf-behave-dns64 > "DNS64: DNS extensions for Network Address Translation from IPv6 Clients > to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, > Iljitsch van Beijnum, 5-Jul-10, > > http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework > http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework > "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao > Bao, Kevin Yin, 17-Aug-10, > > http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate > "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, > 22-Aug-10, > > http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful > "Stateful NAT64: Network Address and Protocol Translation from IPv6 > Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van > Beijnum, 12-Jul-10, > > > On Aug 28, 2010, at 5:40 PM, YangGL wrote: > > > Tests in my lab have proved that many popular applications cannot work = on > IPv6-only network with NAT64, such as IM, P2P, games, and part of video. = WEB > and part of mail (Outlook and Outlook express) are the only applications = we > can find working properly with NAT64. But there are more than 50% traffic= is > P2P, WEB traffic is less than 20% on CT=A1=AFs network. I think it is not= a good > news to NAT64. > > Tests also prove that almost all of popular applications on Internet ca= n > work on IPv4-only network with single level and double level NAT44, such = as > WEB, mail, IM, P2P, games, video and etc. > > NAT64 and NAT44 are similar in theory. But what make the difference of > application support? I think it should be timing. NAT44 appears ten years > ago. There are a few applications on internet at that time. Subsequent > applications, such as IM, P2P, were designed to work with NAT44. NAT64 co= me > after this popular applications, situation is totally different. If NAT64= is > deployed on commercial network now, CT=A1=AFs network traffic will cut do= wn 70% > immediately, and most applications will release a new version for IPv6-on= ly > or NAT64 in the next one year. But it is not a good idea to providers. > > > > Best regards, > > Yang Guoliang > > > > =B7=A2=BC=FE=C8=CB: v4tov6transition-bounces@ietf.org [mailto: > v4tov6transition-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee > > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA8=D4=C225=C8=D5 22:05 > > =CA=D5=BC=FE=C8=CB: huang cancan > > =B3=AD=CB=CD: Kurt Erik Lindqvist; IPv6 v6ops; v4tov6transition@ietf.or= g > > =D6=F7=CC=E2: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidel= ines WGLC > > > > From user=A1=AFs perspective, do they care IPv4 or IPv6? Most don=A1=AF= t. For > example: a casual web user wants to access his/her favorite IPv4-only > website. If his web client and PC support IPv6 and on an IPv6-only networ= k > with NAT64, the web traffic will go through the NAT once. If his web clie= nt > and PC support IPv4-only on an IPv4 network with NAT444, the web traffic > will go through the NAT twice. In the end, he/she still gets the same > content. From this perspective, both experience =A1=B0could be=A1=B1 very= similar. > > > > However, this use case is rather limited and not applicable to many > applications. This is why I said =A1=B0could be=A1=B1. Also, both Cameron= and I agree > that this is easier to implement IPv6-only on mobile network than on fixe= d > network because mobile operators have more control over the devices and > apps. IMHO, it will take longer time for fixed network operators to suppo= rt > NAT64 only solution in the network. > > > > > > On 8/25/10 9:41 AM, "huang cancan" wrote: > > > > well, I mean: why customer experience of IPv4-only + NAT444 could be th= e > same as IPv6-only + NAT64? > > > > On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee > wrote: > > In order to deploy IPv6-only + NAT64, the client and network must talk > IPv6. It also requires DNS64. These requirements are not needed for > IPv4-only + NAT444. From the deployment point of view, they are very > different technologies. > > > > > > > > On 8/25/10 7:13 AM, "huang cancan" http://cancanhuang110@gmail.com> > wrote: > > > > hi,Yiu: > > As you mentioned below: > > > All I am saying is the customer > > > experience of IPv4-only + NAT444 could be the same as IPv6-only + > NAT64, but > > > the technologies and plan to offer these service are very different. > > > > Do you have any test data to support this conclusion? > > > > Can-can Huang > > > > > > On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee http://yiu_lee@cable.comcast.com> > wrote: > > > > > Agreed. The 2x cost is really just the packet core ... which is of > > > course a lot of money to double for no tangible benefit ..... talk > > > about no business case .... And, still have numbering issues, custome= r > > > experience is the same as IPv4-only + NAT44 and approximately the sam= e > > > as IPv6-only + NAT64 > > > > > Life cycle of mobile equipments could be every 2-3 years, but life cycl= e > of > > consumer electronics could be 5+ years. Consider many large TVs with > > Internet service selling today are still running IPv4-only, fixed line > > operators must prepare to support them in foreseeable future. > > > > That said, I am not saying an operator must build a dual-stack core > network, > > there are technologies such as DS-lite and Softwire Mesh available to r= un > a > > pure IPv6 core network with dual-stack edge. All I am saying is the > customer > > experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64= , > but > > the technologies and plan to offer these service are very different. > > > > > > > > _______________________________________________ > > v4tov6transition mailing list > > v4tov6transition@ietf.org > > https://www.ietf.org/mailman/listinfo/v4tov6transition > > > > > > > > > > _______________________________________________ > > v4tov6transition mailing list > > v4tov6transition@ietf.org > > https://www.ietf.org/mailman/listinfo/v4tov6transition > > --001636c5979b0e29fe048f070fb5 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Another reason why we don't test stateless NAT64 is= that there are few application clients support IPv6, we can only test web = or mail applications which are also OK with the stateful one.
 


 
2010/8/29 Fred Baker <fred@cisco.com>
</chair> <!-- v6ops --&= gt;
<author> <!-- draft-ietf-behave-v6v4-xlate -->

Ma= y I ask a question?

When you say you tested it with NAT64, what did you test with?

T= here are two modes for translation between IPv4 and IPv6. The stateful mode= , described in draft-ietf-behave-v6v4-xlate-stateful, is essentially identi= cal in function to IPv4/IPv4 NAT, and allows IPv6 systems to connect to IPv= 4 systems but not the reverse. The stateless mode, described in draft-ietf-= behave-v6v4-xlate, allows connections to be initiated in either direction. = The downside of the stateless mode is that it requires a direct mapping bet= ween an IPv4 and an IPv6 address. The are two parts of a common framework, = use the same addressing plan, and the same DNS extension.

Are you running both modes, or only the stateful mode? If you are only = running the stateful mode, that what you're reporting is what we have b= een saying for some time it will behave like.

ht= tp://datatracker.ietf.org/doc/draft-ietf-behave-address-format
http://tools.ietf.org/html/draft-ietf-behave-address-format<= /a>
 "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao= Bao, Christian
 Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10,
=  <draft-ietf-behave-address-format-10.txt>

htt= p://datatracker.ietf.org/doc/draft-ietf-behave-dns64
http://tools.ietf.org/html/draft-ietf-behave-dns64
 "= ;DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matt= hews,
 Iljitsch van Beijnum, 5-Jul-10, <draft-ietf-behave-dns64-10.txt>= ;

http://datatracker.ietf.org/doc/draft-ietf-beh= ave-v6v4-framework
http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework<= /a>
 "Framework for IPv4/IPv6 Translation", Fred Baker, X= ing Li, Congxiao
 Bao, Kevin Yin, 17-Aug-10, <draft-ietf-behave-v6v4-framework-10.tx= t>

http://datatracker.ietf.org/doc/draft-ietf-beh= ave-v6v4-xlate
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate
=  "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fre= d Baker,
 22-Aug-10, <draft-ietf-behave-v6v4-xlate-22.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xl= ate-stateful
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate= -stateful
 "Stateful NAT64: Network Address and Protocol T= ranslation from IPv6
 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Ilji= tsch van
 Beijnum, 12-Jul-10, <draft-ietf-behave-v6v4-xlate-stat= eful-12.txt>


On Aug 28, 2010, at 5:40 PM, YangGL wrote:
> Tests in my lab have proved that many popular applications cannot wor= k on IPv6-only network with NAT64, such as IM, P2P, games, and part of vide= o. WEB and part of mail (Outlook and Outlook express) are the only applicat= ions we can find working properly with NAT64. But there are more than 50% t= raffic is P2P, WEB traffic is less than 20% on CT’s network. I think = it is not a good news to NAT64.
> Tests also prove that almost all of popular applications on Internet c= an work on IPv4-only network with single level and double level NAT44, such= as WEB, mail, IM, P2P, games, video and etc.
> NAT64 and NAT44 are s= imilar in theory. But what make the difference of application support? I th= ink it should be timing. NAT44 appears ten years ago. There are a few appli= cations on internet at that time. Subsequent applications, such as IM, P2P,= were designed to work with NAT44. NAT64 come after this popular applicatio= ns, situation is totally different. If NAT64 is deployed on commercial netw= ork now, CT’s network traffic will cut down 70% immediately, and most= applications will release a new version for IPv6-only or NAT64 in the next= one year. But it is not a good idea to providers.
>
> Best regards,
> Yang Guoliang
>
> =B7=A2=BC= =FE=C8=CB: v4tov6trans= ition-bounces@ietf.org [mailto:v4tov6transition-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee=
> =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA8=D4=C225=C8=D5 22:05
> =CA= =D5=BC=FE=C8=CB: huang cancan
> =B3=AD=CB=CD: Kurt Erik Lindqvist; IP= v6 v6ops; v4tov6transition@iet= f.org
> =D6=F7=CC=E2: Re: [v4tov6transition] draft-arkko-ipv6-tra= nsition-guidelines WGLC
>
> From user’s perspective, do they care IPv4 or IPv6? Most= don’t. For example: a casual web user wants to access his/her favori= te IPv4-only website. If his web client and PC support IPv6 and on an IPv6-= only network with NAT64, the web traffic will go through the NAT once. If h= is web client and PC support IPv4-only on an IPv4 network with NAT444, the = web traffic will go through the NAT twice. In the end, he/she still gets th= e same content. From this perspective, both experience “could be&rdqu= o; very similar.
>
> However, this use case is rather limited and not applicable to= many applications. This is why I said “could be”. Also, both C= ameron and I agree that this is easier to implement IPv6-only on mobile net= work than on fixed network because mobile operators have more control over = the devices and apps. IMHO, it will take longer time for fixed network oper= ators to support NAT64 only solution in the network.
>
>
> On 8/25/10 9:41 AM, "huang cancan" <cancanhuang110@gmail.com> wro= te:
>
> well, I mean: why customer experience of IPv4-only + NA= T444 could be the same as IPv6-only + NAT64?
>
> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <yiu_lee@cable.comcast.com> wrote:
= > In order to deploy IPv6-only + NAT64, the client and network must talk= IPv6. It also requires DNS64. These requirements are not needed for IPv4-o= nly + NAT444. From the deployment point of view, they are very different te= chnologies.
>
>
>
> On 8/25/10 7:13 AM, "huang cancan" &= lt;cancanhuang110@gmail.com= <http://cancanhuan= g110@gmail.com> = > wrote:
>
> hi,Yiu:
>   As you mentioned below:
> > Al= l I am saying is the customer
> > experience of IPv4-only + NAT444= could be the same as IPv6-only + NAT64, but
> > the technologies = and plan to offer these service are very different.
>
>   Do you have any test data to support this conclusion?>
> Can-can Huang
>
>
> On Sat, Aug 21, 2010 a= t 7:37 AM, Yiu L. Lee <yiu_= lee@cable.comcast.com <http://yiu_lee@cable.comcast.com> > wrote:
>
> > Agreed.  The 2x cost is really just the packet core = ... which is of
> > course a lot of money to double for no tangibl= e benefit ..... talk
> > about no business case .... And, still ha= ve numbering issues, customer
> > experience is the same as IPv4-only + NAT44 and approximately the= same
> > as IPv6-only + NAT64
> >
> Life cycle of = mobile equipments could be every 2-3 years, but life cycle of
> consu= mer electronics could be 5+ years. Consider many large TVs with
> Internet service selling today are still running IPv4-only, fixed line=
> operators must prepare to support them in foreseeable future.
&= gt;
> That said, I am not saying an operator must build a dual-stack = core network,
> there are technologies such as DS-lite and Softwire Mesh available to = run a
> pure IPv6 core network with dual-stack edge. All I am saying = is the customer
> experience of IPv4-only + NAT444 could be the same = as IPv6-only + NAT64, but
> the technologies and plan to offer these service are very different.>
>
>
> ____________________________________________= ___
> v4tov6transition mailing list
> v4tov6transition@ietf.org <http://v4tov6transition@ietf.org>
> https://www.ietf.org/mailman/listinfo/v4tov6transition>
>
>
>
> ____________________________________= ___________
> v4tov6transition mailing list
> v4tov6transition@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v4tov6transition


--001636c5979b0e29fe048f070fb5-- From brian.e.carpenter@gmail.com Mon Aug 30 15:37:49 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AF603A67B6; Mon, 30 Aug 2010 15:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] 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 3W1B-xVi8dUN; Mon, 30 Aug 2010 15:37:48 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B375C3A6887; Mon, 30 Aug 2010 15:37:47 -0700 (PDT) Received: by qwc9 with SMTP id 9so5891618qwc.31 for ; Mon, 30 Aug 2010 15:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=nXn+KdsWC7qSLuFKuigjB0HbxKtO9YV2kr1gQ0/dHts=; b=n15UePCbp2p7yPcyTzpOs4eqNr8DMYoW77JqRfmw3nRvsUHVqYxq9W4iYusivBKrtW Zte4caGtXQtAcD2asgz1El1cI576GX/rAyljn3GxqP90M4mDLtBFNdj3HVTSo50FXUqE wFb/McQNsL931c1MchbAFUGDVZJAeFXG8UK6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Nj9iOa+9ARx+BwyV2NzCUOMkQ/igjlK1NwNbRWspH83BXHgsZu/erz2AKWdWSmub6Z tlAxSL45tw+f39Cpwe9kvup6Do5mprc/IDZIEPSJollGVAj1Oa2yAq9LZeZLEAtq1aM/ N4SM/fzRkVTPLpcuTMevbxZOGPvhpqWeL36Vs= Received: by 10.220.49.202 with SMTP id w10mr3166095vcf.70.1283207898220; Mon, 30 Aug 2010 15:38:18 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id s29sm2649747vcr.23.2010.08.30.15.38.13 (version=SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 15:38:15 -0700 (PDT) Message-ID: <4C7C32D2.70909@gmail.com> Date: Tue, 31 Aug 2010 10:38:10 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: huang cancan References: <002a01cb4712$d9f72fb0$8de58f10$@com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 v6ops , Behave WG , Fred Baker , v4tov6transition@ietf.org Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 22:37:49 -0000 Hi, On 2010-08-30 21:26, huang cancan wrote: > Another reason why we don't test stateless NAT64 is that there are few > application clients support IPv6, we can only test web or mail applicat= ions > which are also OK with the stateful one. But you reported other applications failing. How can they fail with NAT64= if they have no IPv6 support in the first place? Brian > 2010/8/29 Fred Baker >=20 >> >> >> >> May I ask a question? >> >> When you say you tested it with NAT64, what did you test with? >> >> There are two modes for translation between IPv4 and IPv6. The statefu= l >> mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essential= ly >> identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to con= nect >> to IPv4 systems but not the reverse. The stateless mode, described in >> draft-ietf-behave-v6v4-xlate, allows connections to be initiated in ei= ther >> direction. The downside of the stateless mode is that it requires a di= rect >> mapping between an IPv4 and an IPv6 address. The are two parts of a co= mmon >> framework, use the same addressing plan, and the same DNS extension. >> >> Are you running both modes, or only the stateful mode? If you are only= >> running the stateful mode, that what you're reporting is what we have = been >> saying for some time it will behave like. >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-address-format >> http://tools.ietf.org/html/draft-ietf-behave-address-format >> "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian >> Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10, >> >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-dns64 >> http://tools.ietf.org/html/draft-ietf-behave-dns64 >> "DNS64: DNS extensions for Network Address Translation from IPv6 Clie= nts >> to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, >> Iljitsch van Beijnum, 5-Jul-10, >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework >> http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework >> "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao >> Bao, Kevin Yin, 17-Aug-10, >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate >> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate >> "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, >> 22-Aug-10, >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful >> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful >> "Stateful NAT64: Network Address and Protocol Translation from IPv6 >> Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch = van >> Beijnum, 12-Jul-10, >> >> >> On Aug 28, 2010, at 5:40 PM, YangGL wrote: >> >>> Tests in my lab have proved that many popular applications cannot wor= k on >> IPv6-only network with NAT64, such as IM, P2P, games, and part of vide= o. WEB >> and part of mail (Outlook and Outlook express) are the only applicatio= ns we >> can find working properly with NAT64. But there are more than 50% traf= fic is >> P2P, WEB traffic is less than 20% on CT=E2=80=99s network. I think it = is not a good >> news to NAT64. >>> Tests also prove that almost all of popular applications on Internet = can >> work on IPv4-only network with single level and double level NAT44, su= ch as >> WEB, mail, IM, P2P, games, video and etc. >>> NAT64 and NAT44 are similar in theory. But what make the difference o= f >> application support? I think it should be timing. NAT44 appears ten ye= ars >> ago. There are a few applications on internet at that time. Subsequent= >> applications, such as IM, P2P, were designed to work with NAT44. NAT64= come >> after this popular applications, situation is totally different. If NA= T64 is >> deployed on commercial network now, CT=E2=80=99s network traffic will = cut down 70% >> immediately, and most applications will release a new version for IPv6= -only >> or NAT64 in the next one year. But it is not a good idea to providers.= >>> Best regards, >>> Yang Guoliang >>> >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: v4tov6transition-bounces@ietf.org [mailt= o: >> v4tov6transition-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Yiu L. Lee >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2010=E5=B9=B48=E6=9C=8825=E6=97= =A5 22:05 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: huang cancan >>> =E6=8A=84=E9=80=81: Kurt Erik Lindqvist; IPv6 v6ops; v4tov6transition= @ietf.org >>> =E4=B8=BB=E9=A2=98: Re: [v4tov6transition] draft-arkko-ipv6-transitio= n-guidelines WGLC >>> >>> From user=E2=80=99s perspective, do they care IPv4 or IPv6? Most don=E2= =80=99t. For >> example: a casual web user wants to access his/her favorite IPv4-only >> website. If his web client and PC support IPv6 and on an IPv6-only net= work >> with NAT64, the web traffic will go through the NAT once. If his web c= lient >> and PC support IPv4-only on an IPv4 network with NAT444, the web traff= ic >> will go through the NAT twice. In the end, he/she still gets the same >> content. From this perspective, both experience =E2=80=9Ccould be=E2=80= =9D very similar. >>> However, this use case is rather limited and not applicable to many >> applications. This is why I said =E2=80=9Ccould be=E2=80=9D. Also, bot= h Cameron and I agree >> that this is easier to implement IPv6-only on mobile network than on f= ixed >> network because mobile operators have more control over the devices an= d >> apps. IMHO, it will take longer time for fixed network operators to su= pport >> NAT64 only solution in the network. >>> >>> On 8/25/10 9:41 AM, "huang cancan" wrote: >>> >>> well, I mean: why customer experience of IPv4-only + NAT444 could be = the >> same as IPv6-only + NAT64? >>> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee >> wrote: >>> In order to deploy IPv6-only + NAT64, the client and network must tal= k >> IPv6. It also requires DNS64. These requirements are not needed for >> IPv4-only + NAT444. From the deployment point of view, they are very >> different technologies. >>> >>> >>> On 8/25/10 7:13 AM, "huang cancan" > http://cancanhuang110@gmail.com> > wrote: >>> hi,Yiu: >>> As you mentioned below: >>>> All I am saying is the customer >>>> experience of IPv4-only + NAT444 could be the same as IPv6-only + >> NAT64, but >>>> the technologies and plan to offer these service are very different.= >>> Do you have any test data to support this conclusion? >>> >>> Can-can Huang >>> >>> >>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee > http://yiu_lee@cable.comcast.com> > wrote: >>>> Agreed. The 2x cost is really just the packet core ... which is of >>>> course a lot of money to double for no tangible benefit ..... talk >>>> about no business case .... And, still have numbering issues, custom= er >>>> experience is the same as IPv4-only + NAT44 and approximately the sa= me >>>> as IPv6-only + NAT64 >>>> >>> Life cycle of mobile equipments could be every 2-3 years, but life cy= cle >> of >>> consumer electronics could be 5+ years. Consider many large TVs with >>> Internet service selling today are still running IPv4-only, fixed lin= e >>> operators must prepare to support them in foreseeable future. >>> >>> That said, I am not saying an operator must build a dual-stack core >> network, >>> there are technologies such as DS-lite and Softwire Mesh available to= run >> a >>> pure IPv6 core network with dual-stack edge. All I am saying is the >> customer >>> experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT= 64, >> but >>> the technologies and plan to offer these service are very different. >>> >>> >>> >>> _______________________________________________ >>> v4tov6transition mailing list >>> v4tov6transition@ietf.org >>> https://www.ietf.org/mailman/listinfo/v4tov6transition >>> >>> >>> >>> >>> _______________________________________________ >>> v4tov6transition mailing list >>> v4tov6transition@ietf.org >>> https://www.ietf.org/mailman/listinfo/v4tov6transition >> >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > v4tov6transition mailing list > v4tov6transition@ietf.org > https://www.ietf.org/mailman/listinfo/v4tov6transition From brian.e.carpenter@gmail.com Mon Aug 30 16:10:22 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99543A68CE for ; Mon, 30 Aug 2010 16:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 BF2s2Kh-NxAB for ; Mon, 30 Aug 2010 16:10:21 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 92DB93A69F4 for ; Mon, 30 Aug 2010 16:10:21 -0700 (PDT) Received: by qyk1 with SMTP id 1so3422887qyk.10 for ; Mon, 30 Aug 2010 16:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=2oBx+eDimPn9as/jJBZBfmoC3Mcd8Uk+lkxoRiP1B/U=; b=meJTC/nlqDv25F+2PqhoX9LyjWD3X4D5O58fKBn+mmSeULg6/cPK2ZBNzoI3npRztN OkgBA852AbNxDHe/juvKVqVAPZf1WPtEHQ8KWIEe8Ry0SXZ3fDEhv97dR5299bGKBqXW xnIUxSlEkuuxbAVgHcQ0DSVtq60ZivrtFH2LM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=vkeJaYt76q/qLCDoX6uFPw7HCmW9NaO5qzV1DyvJM8LO/SD3056d5vVIhMRBkHC0rm ztykAx0j4OKW0w+WzEHXK3FOr2l53zTiOWfW1u9d4Bhqi60/JeDrYoFh9kTAD1z4YQ20 2V+oEJCSUtpu661NaX72RQnQlybh74BbbuWpo= Received: by 10.220.161.201 with SMTP id s9mr3579159vcx.137.1283209851997; Mon, 30 Aug 2010 16:10:51 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id b8sm2675966vci.21.2010.08.30.16.10.50 (version=SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 16:10:51 -0700 (PDT) Message-ID: <4C7C3A78.5010505@gmail.com> Date: Tue, 31 Aug 2010 11:10:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] [Fwd: I-D Action:draft-carpenter-referral-ps-01.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 23:10:23 -0000 Hi, A few people believe that the problem of 3rd party referrals really does need to be tackled in a generic way. We've backed off from proposing a solution (as in the GROBJ BOF at IETF 76), since the BOF showed strong consensus that the topic is worth working on, and strong consensus that the requirements need to be clarified first. As the first step in that, here's an update of the problem statement. Comments and discussion welcome, here or on the ad hoc GROBJ mailing list. https://www.ietf.org/mailman/listinfo/grobj Regards Brian Carpenter Sheng Jiang Bo Zhou -------- Original Message -------- From: Date: Mon, Aug 30, 2010 at 1:15 PM Subject: I-D Action:draft-carpenter-referral-ps-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Problem Statement for Referral Author(s) : B. Carpenter, et al. Filename : draft-carpenter-referral-ps-01.txt Pages : 14 Date : 2010-08-29 The purpose of a referral is to enable a given entity in a multiparty Internet application to pass information to another party. It enables a communication initiator to be aware of relevant information of its destination entity before launching the communication. This memo discusses the problems involved in referral scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-referral-ps-01.txt From tena@huawei.com Mon Aug 30 20:14:10 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3DB3A659B; Mon, 30 Aug 2010 20:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.391 X-Spam-Level: X-Spam-Status: No, score=-98.391 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] 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 rn3RGTa645CX; Mon, 30 Aug 2010 20:14:07 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E850E3A6452; Mon, 30 Aug 2010 20:14:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7Z00659Y9NVO@szxga03-in.huawei.com>; Tue, 31 Aug 2010 11:12:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7Z00KXTY9N7A@szxga03-in.huawei.com>; Tue, 31 Aug 2010 11:12:59 +0800 (CST) Received: from z00147053k ([10.70.39.122]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7Z00MV7Y9MO4@szxml06-in.huawei.com>; Tue, 31 Aug 2010 11:12:59 +0800 (CST) Date: Tue, 31 Aug 2010 11:12:58 +0800 From: Tina TSOU To: 'Fred Baker' , YangGL Message-id: <0D2B9D8C199A4D7B80B3B8E2E2389380@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <002a01cb4712$d9f72fb0$8de58f10$@com> <00a701cb48b4$08ff66e0$1afe34a0$@com> Cc: 'IPv6 v6ops' , 'Behave WG' , v4tov6transition@ietf.org Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 03:14:11 -0000 Technically, these drafts are well written and very useful. It is really appreciated. Fred, would you explicitly point out the answers of the following questions from these drafts? Thanks. 1) There are some applications, server, clients don¡¯t support IPv6. These situations will be met regardless of stateful or stateless NAT64. No one has right to request these applications must support IPv6 (Monocrat may have), but these applications have existed and been used for many people. In the migration to IPv6, if these users can¡¯t use these service and applications, it will result in the losing of subscribers for operators, unless all the operators of the world support IPv6 at the same moment. 2) Some applications have supported NAT44 traversal maturely, but in a long period of time in the future these applications would unlikely to support NAT64¡¯s traversal. If adopting NAT64, these applications would be impacted. No one has the right to request these applications must support NAT64 traversal, so after the usage of NAT64, these application will conk out inevitably. Both stateful and stateless NAT64 have the same issues. 3) Some applications contain the senders¡¯ IP address in the packet payload, even in the encrypted packet case. These will have problems when using NAT64. Since these applications are existing applications, no one has right to requesting stop using these applications. These issues will be encountered when using NAT64 (both stateful and stateless ones have the same problem). 4) No one has the right to force all the UE to support IPV6, therefore from the technology evolution point of view, we don't have to consider IPV4 only user actively visits IPv6 only service, but in the actual use people have to consider it, otherwise it may result in the subscriber losing. Yes, it is not NAT64. 5) For some P2P application, after using NAT64, IPv4 only peer is not able to actively scan the IPv6 only peer; some P2P applications don¡¯t consider NAT64 traversal for the time being. Again, these drafts are very practical drafts, any way. B. R. Tina http://tinatsou.weebly.com/index.html ----- Original Message ----- From: "YangGL" To: "'Fred Baker'" Cc: "'Behave WG'" ; "'Kurt Erik Lindqvist'" ; "'IPv6 v6ops'" ; Sent: Tuesday, August 31, 2010 10:27 AM Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC > Hi Fred, > You are really the dictionary of IPv6! Your mail always make me feel > difficult to answer, too many references to read, give me some time, I > will > come back after reading those documents mentioned in your mail. > > > Best regards, > Yang Guoliang > > > > > > May I ask a question? > > When you say you tested it with NAT64, what did you test with? > > There are two modes for translation between IPv4 and IPv6. The stateful > mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially > identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to connect > to IPv4 systems but not the reverse. The stateless mode, described in > draft-ietf-behave-v6v4-xlate, allows connections to be initiated in either > direction. The downside of the stateless mode is that it requires a direct > mapping between an IPv4 and an IPv6 address. The are two parts of a common > framework, use the same addressing plan, and the same DNS extension. > > Are you running both modes, or only the stateful mode? If you are only > running the stateful mode, that what you're reporting is what we have been > saying for some time it will behave like. > > http://datatracker.ietf.org/doc/draft-ietf-behave-address-format > http://tools.ietf.org/html/draft-ietf-behave-address-format > "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian > Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10, > > > http://datatracker.ietf.org/doc/draft-ietf-behave-dns64 > http://tools.ietf.org/html/draft-ietf-behave-dns64 > "DNS64: DNS extensions for Network Address Translation from IPv6 Clients > to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, > Iljitsch van Beijnum, 5-Jul-10, > > http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework > http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework > "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao > Bao, Kevin Yin, 17-Aug-10, > > http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate > "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, > 22-Aug-10, > > http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful > "Stateful NAT64: Network Address and Protocol Translation from IPv6 > Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van > Beijnum, 12-Jul-10, > > > On Aug 28, 2010, at 5:40 PM, YangGL wrote: > >> Tests in my lab have proved that many popular applications cannot work on > IPv6-only network with NAT64, such as IM, P2P, games, and part of video. > WEB > and part of mail (Outlook and Outlook express) are the only applications > we > can find working properly with NAT64. But there are more than 50% traffic > is > P2P, WEB traffic is less than 20% on CT¡¯s network. I think it is not a > good > news to NAT64. >> Tests also prove that almost all of popular applications on Internet can > work on IPv4-only network with single level and double level NAT44, such > as > WEB, mail, IM, P2P, games, video and etc. >> NAT64 and NAT44 are similar in theory. But what make the difference of > application support? I think it should be timing. NAT44 appears ten years > ago. There are a few applications on internet at that time. Subsequent > applications, such as IM, P2P, were designed to work with NAT44. NAT64 > come > after this popular applications, situation is totally different. If NAT64 > is > deployed on commercial network now, CT¡¯s network traffic will cut down > 70% > immediately, and most applications will release a new version for > IPv6-only > or NAT64 in the next one year. But it is not a good idea to providers. >> >> Best regards, >> Yang Guoliang >> >> ·¢¼þÈË: v4tov6transition-bounces@ietf.org > [mailto:v4tov6transition-bounces@ietf.org] ´ú±í Yiu L. Lee >> ·¢ËÍʱ¼ä: 2010Äê8ÔÂ25ÈÕ 22:05 >> ÊÕ¼þÈË: huang cancan >> ³­ËÍ: Kurt Erik Lindqvist; IPv6 v6ops; v4tov6transition@ietf.org >> Ö÷Ìâ: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC >> >> From user¡¯s perspective, do they care IPv4 or IPv6? Most don¡¯t. For > example: a casual web user wants to access his/her favorite IPv4-only > website. If his web client and PC support IPv6 and on an IPv6-only network > with NAT64, the web traffic will go through the NAT once. If his web > client > and PC support IPv4-only on an IPv4 network with NAT444, the web traffic > will go through the NAT twice. In the end, he/she still gets the same > content. From this perspective, both experience ¡°could be¡± very similar. >> >> However, this use case is rather limited and not applicable to many > applications. This is why I said ¡°could be¡±. Also, both Cameron and I > agree that this is easier to implement IPv6-only on mobile network than on > fixed network because mobile operators have more control over the devices > and apps. IMHO, it will take longer time for fixed network operators to > support NAT64 only solution in the network. >> >> >> On 8/25/10 9:41 AM, "huang cancan" wrote: >> >> well, I mean: why customer experience of IPv4-only + NAT444 could be the > same as IPv6-only + NAT64? >> >> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee > wrote: >> In order to deploy IPv6-only + NAT64, the client and network must talk > IPv6. It also requires DNS64. These requirements are not needed for > IPv4-only + NAT444. From the deployment point of view, they are very > different technologies. >> >> >> >> On 8/25/10 7:13 AM, "huang cancan" > wrote: >> >> hi,Yiu: >> As you mentioned below: >> > All I am saying is the customer >> > experience of IPv4-only + NAT444 could be the same as IPv6-only + >> > NAT64, > but >> > the technologies and plan to offer these service are very different. >> >> Do you have any test data to support this conclusion? >> >> Can-can Huang >> >> >> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee > wrote: >> >> > Agreed. The 2x cost is really just the packet core ... which is of >> > course a lot of money to double for no tangible benefit ..... talk >> > about no business case .... And, still have numbering issues, customer >> > experience is the same as IPv4-only + NAT44 and approximately the same >> > as IPv6-only + NAT64 >> > >> Life cycle of mobile equipments could be every 2-3 years, but life cycle > of >> consumer electronics could be 5+ years. Consider many large TVs with >> Internet service selling today are still running IPv4-only, fixed line >> operators must prepare to support them in foreseeable future. >> >> That said, I am not saying an operator must build a dual-stack core > network, >> there are technologies such as DS-lite and Softwire Mesh available to run > a >> pure IPv6 core network with dual-stack edge. All I am saying is the > customer >> experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, > but >> the technologies and plan to offer these service are very different. >> >> >> >> _______________________________________________ >> v4tov6transition mailing list >> v4tov6transition@ietf.org >> https://www.ietf.org/mailman/listinfo/v4tov6transition >> >> >> >> >> _______________________________________________ >> v4tov6transition mailing list >> v4tov6transition@ietf.org >> https://www.ietf.org/mailman/listinfo/v4tov6transition > > _______________________________________________ > v4tov6transition mailing list > v4tov6transition@ietf.org > https://www.ietf.org/mailman/listinfo/v4tov6transition > From joelja@bogus.com Mon Aug 30 21:24:04 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D613A672F; Mon, 30 Aug 2010 21:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.551 X-Spam-Level: X-Spam-Status: No, score=-100.551 tagged_above=-999 required=5 tests=[AWL=-1.602, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_83=0.6, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] 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 zY2DuVc4YgWH; Mon, 30 Aug 2010 21:24:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id D02943A68C7; Mon, 30 Aug 2010 21:23:56 -0700 (PDT) Received: from joelja-mac.lan (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o7V4NaLe059422 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 31 Aug 2010 04:23:37 GMT (envelope-from joelja@bogus.com) Message-ID: <4C7C83C8.9060201@bogus.com> Date: Mon, 30 Aug 2010 21:23:36 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Tina TSOU References: <002a01cb4712$d9f72fb0$8de58f10$@com> <00a701cb48b4$08ff66e0$1afe34a0$@com> <0D2B9D8C199A4D7B80B3B8E2E2389380@china.huawei.com> In-Reply-To: <0D2B9D8C199A4D7B80B3B8E2E2389380@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 31 Aug 2010 04:23:38 +0000 (UTC) Cc: 'IPv6 v6ops' , YangGL , 'Behave WG' , 'Fred Baker' , v4tov6transition@ietf.org Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 04:24:04 -0000 Just a few observations without the wg-cochair hat on. On 8/30/10 8:12 PM, Tina TSOU wrote: > Technically, these drafts are well written and very useful. It is really > appreciated. Fred, would you explicitly point out the answers of the > following questions from these drafts? Thanks. > > 1) There are some applications, server, clients don¡¯t support IPv6. > These situations will be met regardless of stateful or stateless NAT64. > No one has right to request these applications must support IPv6 > (Monocrat may have), but these applications have existed and been used > for many people. In the migration to IPv6, if these users can¡¯t use > these service and applications, it will result in the losing of > subscribers for operators, unless all the operators of the world support > IPv6 at the same moment. Legacy ipv4 only apps aren't going to support v6 period, it has nothing to do with when operators support or don't support ipv6. legacy applications do not become new again. see (3) for dicussion of rights. > 2) Some applications have supported NAT44 traversal maturely, but in a > long period of time in the future these applications would unlikely to > support NAT64¡¯s traversal. If adopting NAT64, these applications would > be impacted. No one has the right to request these applications must > support NAT64 traversal, so after the usage of NAT64, these application > will conk out inevitably. Both stateful and stateless NAT64 have the > same issues. An application that supports nat64 traversal is fact a native ipv6 application that isn't dependent on layer violations for it's signaling of among other things ip address port numbers or security bindings. You sort of characterized this in (3). > 3) Some applications contain the senders¡¯ IP address in the packet > payload, even in the encrypted packet case. These will have problems > when using NAT64. Since these applications are existing applications, no > one has right to requesting stop using these applications. These issues > will be encountered when using NAT64 (both stateful and stateless ones > have the same problem). The word "right" is a challenge to me here. Supporting a protocol on a network is a business decision(for example, when do I add ipv6 aaaa records to a service in my network). It is is in the interests of internet service providers to induce as little deliberate breakage into the network as possible. As a content and services provider (which is what I do) if I don't adhere to this axiom I get to look for a new job. > 4) No one has the right to force all the UE to support IPV6, therefore > from the technology evolution point of view, we don't have to consider > IPV4 only user actively visits IPv6 only service, but in the actual use > people have to consider it, otherwise it may result in the subscriber > losing. Yes, it is not NAT64. There is going to be a time where ipv4 only users cannot access a resource because it only accessible via v6, in superficial cases this happens all the time. It is in the interests of most if perhaps not all network operators, application vendors and end users, to push the time in which that occurs routinely, beyond the window in which ipv6 deployment largely occurs. That said it seems like that workarounds associated with ipv4 support post-runout will result in a gradually less usable ipv4 network, which is if anything and incentive against holding out to the bitter end. > 5) For some P2P application, after using NAT64, IPv4 only peer is not > able to actively scan the IPv6 only peer; some P2P applications don¡¯t > consider NAT64 traversal for the time being. p2p applications have a built-in assumption of the existence of usable endpoint identifiers. To the extent that ipv4 identifiers become progressively less usable, p2p applications will prefer ipv6, that will require upgrade or substitution. > Again, these drafts are very practical drafts, any way. It is useful to understand what on a v6 native host is not going to work well through a 6to4 gateway. It is not so useful to have an existence-proof for problems with ipv4 only applications, given that we have ipv4-only-hosts to support into the immediately forseeable future. The assumption that I make with those devices be they embedded systems, pc's, mobile phones, etc, Is that I have the luxury of zero stack change. > B. R. > Tina > http://tinatsou.weebly.com/index.html > > ----- Original Message ----- From: "YangGL" > To: "'Fred Baker'" > Cc: "'Behave WG'" ; "'Kurt Erik Lindqvist'" > ; "'IPv6 v6ops'" ; > > Sent: Tuesday, August 31, 2010 10:27 AM > Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC > > >> Hi Fred, >> You are really the dictionary of IPv6! Your mail always make me feel >> difficult to answer, too many references to read, give me some time, I >> will >> come back after reading those documents mentioned in your mail. >> >> >> Best regards, >> Yang Guoliang >> >> >> >> >> >> May I ask a question? >> >> When you say you tested it with NAT64, what did you test with? >> >> There are two modes for translation between IPv4 and IPv6. The stateful >> mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially >> identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to >> connect >> to IPv4 systems but not the reverse. The stateless mode, described in >> draft-ietf-behave-v6v4-xlate, allows connections to be initiated in >> either >> direction. The downside of the stateless mode is that it requires a >> direct >> mapping between an IPv4 and an IPv6 address. The are two parts of a >> common >> framework, use the same addressing plan, and the same DNS extension. >> >> Are you running both modes, or only the stateful mode? If you are only >> running the stateful mode, that what you're reporting is what we have >> been >> saying for some time it will behave like. >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-address-format >> http://tools.ietf.org/html/draft-ietf-behave-address-format >> "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian >> Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10, >> >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-dns64 >> http://tools.ietf.org/html/draft-ietf-behave-dns64 >> "DNS64: DNS extensions for Network Address Translation from IPv6 Clients >> to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, >> Iljitsch van Beijnum, 5-Jul-10, >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework >> http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework >> "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao >> Bao, Kevin Yin, 17-Aug-10, >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate >> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate >> "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, >> 22-Aug-10, >> >> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful >> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful >> "Stateful NAT64: Network Address and Protocol Translation from IPv6 >> Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van >> Beijnum, 12-Jul-10, >> >> >> On Aug 28, 2010, at 5:40 PM, YangGL wrote: >> >>> Tests in my lab have proved that many popular applications cannot >>> work on >> IPv6-only network with NAT64, such as IM, P2P, games, and part of >> video. WEB >> and part of mail (Outlook and Outlook express) are the only >> applications we >> can find working properly with NAT64. But there are more than 50% >> traffic is >> P2P, WEB traffic is less than 20% on CT¡¯s network. I think it is not a >> good >> news to NAT64. >>> Tests also prove that almost all of popular applications on Internet can >> work on IPv4-only network with single level and double level NAT44, >> such as >> WEB, mail, IM, P2P, games, video and etc. >>> NAT64 and NAT44 are similar in theory. But what make the difference of >> application support? I think it should be timing. NAT44 appears ten years >> ago. There are a few applications on internet at that time. Subsequent >> applications, such as IM, P2P, were designed to work with NAT44. NAT64 >> come >> after this popular applications, situation is totally different. If >> NAT64 is >> deployed on commercial network now, CT¡¯s network traffic will cut down >> 70% >> immediately, and most applications will release a new version for >> IPv6-only >> or NAT64 in the next one year. But it is not a good idea to providers. >>> >>> Best regards, >>> Yang Guoliang >>> >>> ·¢¼þÈË: v4tov6transition-bounces@ietf.org >> [mailto:v4tov6transition-bounces@ietf.org] ´ú±í Yiu L. Lee >>> ·¢ËÍʱ¼ä: 2010Äê8ÔÂ25ÈÕ 22:05 >>> ÊÕ¼þÈË: huang cancan >>> ³­ËÍ: Kurt Erik Lindqvist; IPv6 v6ops; v4tov6transition@ietf.org >>> Ö÷Ìâ: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC >>> >>> From user¡¯s perspective, do they care IPv4 or IPv6? Most don¡¯t. For >> example: a casual web user wants to access his/her favorite IPv4-only >> website. If his web client and PC support IPv6 and on an IPv6-only >> network >> with NAT64, the web traffic will go through the NAT once. If his web >> client >> and PC support IPv4-only on an IPv4 network with NAT444, the web traffic >> will go through the NAT twice. In the end, he/she still gets the same >> content. From this perspective, both experience ¡°could be¡± very similar. >>> >>> However, this use case is rather limited and not applicable to many >> applications. This is why I said ¡°could be¡±. Also, both Cameron and I >> agree that this is easier to implement IPv6-only on mobile network >> than on >> fixed network because mobile operators have more control over the devices >> and apps. IMHO, it will take longer time for fixed network operators to >> support NAT64 only solution in the network. >>> >>> >>> On 8/25/10 9:41 AM, "huang cancan" wrote: >>> >>> well, I mean: why customer experience of IPv4-only + NAT444 could be the >> same as IPv6-only + NAT64? >>> >>> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee >> wrote: >>> In order to deploy IPv6-only + NAT64, the client and network must talk >> IPv6. It also requires DNS64. These requirements are not needed for >> IPv4-only + NAT444. From the deployment point of view, they are very >> different technologies. >>> >>> >>> >>> On 8/25/10 7:13 AM, "huang cancan" > > wrote: >>> >>> hi,Yiu: >>> As you mentioned below: >>> > All I am saying is the customer >>> > experience of IPv4-only + NAT444 could be the same as IPv6-only + > >>> NAT64, >> but >>> > the technologies and plan to offer these service are very different. >>> >>> Do you have any test data to support this conclusion? >>> >>> Can-can Huang >>> >>> >>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee > > wrote: >>> >>> > Agreed. The 2x cost is really just the packet core ... which is of >>> > course a lot of money to double for no tangible benefit ..... talk >>> > about no business case .... And, still have numbering issues, customer >>> > experience is the same as IPv4-only + NAT44 and approximately the same >>> > as IPv6-only + NAT64 >>> > >>> Life cycle of mobile equipments could be every 2-3 years, but life cycle >> of >>> consumer electronics could be 5+ years. Consider many large TVs with >>> Internet service selling today are still running IPv4-only, fixed line >>> operators must prepare to support them in foreseeable future. >>> >>> That said, I am not saying an operator must build a dual-stack core >> network, >>> there are technologies such as DS-lite and Softwire Mesh available to >>> run >> a >>> pure IPv6 core network with dual-stack edge. All I am saying is the >> customer >>> experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, >> but >>> the technologies and plan to offer these service are very different. >>> >>> >>> >>> _______________________________________________ >>> v4tov6transition mailing list >>> v4tov6transition@ietf.org >>> https://www.ietf.org/mailman/listinfo/v4tov6transition >>> >>> >>> >>> >>> _______________________________________________ >>> v4tov6transition mailing list >>> v4tov6transition@ietf.org >>> https://www.ietf.org/mailman/listinfo/v4tov6transition >> >> _______________________________________________ >> v4tov6transition mailing list >> v4tov6transition@ietf.org >> https://www.ietf.org/mailman/listinfo/v4tov6transition >> > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From tena@huawei.com Tue Aug 31 02:25:42 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DBF3A6927 for ; Tue, 31 Aug 2010 02:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.893 X-Spam-Level: X-Spam-Status: No, score=-99.893 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] 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 0OG8MTTX2hbC for ; Tue, 31 Aug 2010 02:25:34 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 85CB03A6803 for ; Tue, 31 Aug 2010 02:25:34 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L80009JFFIG5Y@szxga04-in.huawei.com> for behave@ietf.org; Tue, 31 Aug 2010 17:25:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L80007K0FIGZX@szxga04-in.huawei.com> for behave@ietf.org; Tue, 31 Aug 2010 17:25:28 +0800 (CST) Received: from z00147053k ([10.70.39.122]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8000EEQFIF1G@szxml04-in.huawei.com> for behave@ietf.org; Tue, 31 Aug 2010 17:25:27 +0800 (CST) Date: Tue, 31 Aug 2010 17:25:27 +0800 From: Tina TSOU To: behave@ietf.org, Dan Wing Message-id: <1016810CB66A46DBAB30910B68816730@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <979A43C06A7B488B93D6FFBA8395A033@china.huawei.com> <08d101cb47fc$05140580$0f3c1080$@com> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 09:25:42 -0000 B. R. Tina http://tinatsou.weebly.com/index.html ----- Original Message ----- From: "Dan Wing" To: "'Tina TSOU'" ; Sent: Monday, August 30, 2010 12:30 PM Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Tina TSOU >> Sent: Saturday, August 28, 2010 2:19 AM >> To: behave@ietf.org >> Subject: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs >> >> Hi Behaver, >> Here is an updated version, thanks to the wonderful review from Med. >> http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01 >> >> It is a short, straight forward I-D. I would like to hear your opinion >> and more comments. What's the next step for it? > > Should the block-allocated source ports be re-used? If so, can text > be added to describe advantages / disadvantages of such re-use? [Tina] Thanks for your thorough review. OK, will add a section to describe the advantages/disadvantages Source port blocks could be reused. When a port block is not used by a user for a while, the NAT device could allocate this port block to another user. If a port block is not reusable, there could be two scenarios: 1. Statically configure the same number of ports for each user, e.g. each can have 2000 ports in this case, there may be a waste of source port resource, because maybe not all the users would need so many ports; meanwhile some users may need more ports DS-Lite draft has some discussion about port allocation, http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-06#section-8.4 2. Initially, give a user a port block, e.g. a block of 300 ports; when the user need more port, give the user another port block, e.g. a block of 100 ports, and so on In this case, a user may need a lot of ports for a while, but later this user does not need so many ports, one or more port blocks could be released. Compared to the above two cases, if a port block is reusable, I can increase the usage of port resource. However, if the block is not reusable, the implementation could be a bit simpler, e.g. timeout for a port block would not be necessary. > > Can a NAT operator determine when a server operator is logging the > source port? [Tina] No, a NAT operator can not determine that. > > What is the impact if a server is not logging the source port? For > example, what happens if a subscriber made a post to a web > server and law enforcement asked the ISP for the identity of the > subscriber, but the server didn't log the source port? This seems > to place the ISP in a difficult situation, requiring the ISP to > reveal the identity of all subscribers that were using that IP > address at that time. [Tina] The impact is that it may not be possible to trace back to a single if a server is not logging the source port. A NAT device can log the destination IP address of each session, though that would not resolve all the problems. Now a CGN (Carrier Grade NAT) may need to support 10000+ users, it is quite possible that some users behind a same NAT would visit a same famous web server, like YouTube, at the same time. In such a case, if the server does not log the source port and the NAT log the destination IP address, I can not trace back to a single user, even if "the ISP to reveal the identity of all subscribers that were using that IP address at that time". Since it is required by regulations (rather than by ISP), the server should be liable to log the source port. This is discussed in draft-ietf-intarea-shared-addressing-issues-01 http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-01#section-11 > > In an appendix it would be useful to provide configuration examples > for popular server software to log the source port (e.g., Apache, > IIS, Postfix, Sendmail, sshd, Cyrus IMAP, UW IMAP). For example, I > believe it was in Apache version 2.1 that added the ability to log > the source port using "%{remote}p" described at > http://httpd.apache.org/docs/2.1/mod/mod_log_config.html. > And be sure to mention that, for all log file modifications, the > source port needs to be added to the log in a way that will work > with the server's log analysis scripts. [Tina] To be honest, I do not know much about all kinds of the server software, I only do network devices. However I will try to find out whether/how they could log source port, and if possible I will add an appendix. I need help from the list for this point. > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Tue Aug 31 08:47:11 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB3B3A6804 for ; Tue, 31 Aug 2010 08:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.464 X-Spam-Level: X-Spam-Status: No, score=-110.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 qVkqT-+w1Soy for ; Tue, 31 Aug 2010 08:46:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2BC6A3A69B9 for ; Tue, 31 Aug 2010 08:46:25 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABPBfEyrR7Hu/2dsb2JhbACUVIwCcaM/nBKCbQGCSQSEPZB0 X-IronPort-AV: E=Sophos;i="4.56,299,1280707200"; d="scan'208";a="356863139" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 31 Aug 2010 15:46:55 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7VFktgl002629; Tue, 31 Aug 2010 15:46:55 GMT From: "Dan Wing" To: "'Tina TSOU'" , References: <979A43C06A7B488B93D6FFBA8395A033@china.huawei.com> <08d101cb47fc$05140580$0f3c1080$@com> <1016810CB66A46DBAB30910B68816730@china.huawei.com> In-Reply-To: <1016810CB66A46DBAB30910B68816730@china.huawei.com> Date: Tue, 31 Aug 2010 08:46:55 -0700 Message-ID: <0df901cb4923$bd04c300$370e4900$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActI7nRAvV+8mDSdTUmDex1apY+rvgAM5Pyw Content-Language: en-us Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 15:47:11 -0000 > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Tuesday, August 31, 2010 2:25 AM > To: behave@ietf.org; Dan Wing > Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale > NATs > > > B. R. > Tina > http://tinatsou.weebly.com/index.html > ----- Original Message ----- > From: "Dan Wing" > To: "'Tina TSOU'" ; > Sent: Monday, August 30, 2010 12:30 PM > Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale > NATs > > > >> -----Original Message----- > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> Behalf Of Tina TSOU > >> Sent: Saturday, August 28, 2010 2:19 AM > >> To: behave@ietf.org > >> Subject: [BEHAVE] Port Management To Reduce Logging In Large-Scale > NATs > >> > >> Hi Behaver, > >> Here is an updated version, thanks to the wonderful review from Med. > >> http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01 > >> > >> It is a short, straight forward I-D. I would like to hear your > opinion > >> and more comments. What's the next step for it? > > > > Should the block-allocated source ports be re-used? If so, can text > > be added to describe advantages / disadvantages of such re-use? > [Tina] Thanks for your thorough review. OK, will add a section to > describe > the advantages/disadvantages > > > > Source port blocks could be reused. When a port block is not used by a > user > for a while, the NAT device could allocate this port block to another > user. > > If a port block is not reusable, there could be two scenarios: > > 1. Statically configure the same number of ports for each user, e.g. > each > can have 2000 ports in this case, there may be a waste of source port > resource, because maybe not all the users would need so many ports; > meanwhile some users may need more ports > > DS-Lite draft has some discussion about port allocation, > http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite- > 06#section-8.4 > > > > 2. Initially, give a user a port block, e.g. a block of 300 ports; when > the > user need more port, give the user another port block, e.g. a block of > 100 > ports, and so on > > In this case, a user may need a lot of ports for a while, but later > this > user does not need so many ports, one or more port blocks could be > released. > > > > Compared to the above two cases, if a port block is reusable, I can > increase > the usage of port resource. > > > > However, if the block is not reusable, the implementation could be a > bit > simpler, e.g. timeout for a port block would not be necessary. > > > > > > Can a NAT operator determine when a server operator is logging the > > source port? > [Tina] No, a NAT operator can not determine that. It is useful to point that out in the I-D. > > What is the impact if a server is not logging the source port? For > > example, what happens if a subscriber made a post to a web > > server and law enforcement asked the ISP for the identity of the > > subscriber, but the server didn't log the source port? This seems > > to place the ISP in a difficult situation, requiring the ISP to > > reveal the identity of all subscribers that were using that IP > > address at that time. > [Tina] The impact is that it may not be possible to trace back to a > single > if a server is not logging the source port. Agreed. It is useful to point that out in the I-D. > A NAT device can log the destination IP address of each session, though > that would not resolve all the problems. > > Now a CGN (Carrier Grade NAT) may need to support 10000+ users, it is > quite > possible that some users behind a same NAT would visit a same famous > web > server, like YouTube, at the same time. In such a case, if the server > does > not log the source port and the NAT log the destination IP address, I > can > not trace back to a single user, even if "the ISP to reveal the > identity of > all subscribers that were using that IP address at that time". Agreed. It is useful to point that out in the I-D. So, the scenarios are: 1. IF server logs source port of incoming connections, THEN the NAT does not need to log destination. The server's logs and the NAT's source port logs will be sufficient to identify the subscriber. 2. IF server does not log source port of incoming connections, AND the NAT does not log destination THEN the ISP cannot identify which subscriber made the connection to the server. This might mean the ISP has to disclose the identity of all the subscribers that were sharing that IP address. 3. If server does not log source port of incoming connections, AND the NAT does log destination THEN the ISP can identify the subset of users that were accessing that server at that time, but the ISP cannot identify the specific user in that subset. (And, as we agreed above, it is impossible for the NAT to determine if the server is logging the source port, so the NAT cannot distinguish between 1 and 2 or between 1 and 3). > Since it is required by regulations (rather than by ISP), the server > should be liable to log the source port. What is "it"? I guess you are referring to regulatory requirements that servers log ports? I am aware of some activity with some regulatory agencies to include source port in their recommended/required logging, but I also know that those changes are not yet final. > This is discussed in draft-ietf-intarea-shared-addressing-issues-01 > > http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues- > 01#section-11 > > > > > > In an appendix it would be useful to provide configuration examples > > for popular server software to log the source port (e.g., Apache, > > IIS, Postfix, Sendmail, sshd, Cyrus IMAP, UW IMAP). For example, I > > believe it was in Apache version 2.1 that added the ability to log > > the source port using "%{remote}p" described at > > http://httpd.apache.org/docs/2.1/mod/mod_log_config.html. > > And be sure to mention that, for all log file modifications, the > > source port needs to be added to the log in a way that will work > > with the server's log analysis scripts. > [Tina] To be honest, I do not know much about all kinds of the server > software, I only do network devices. However I will try to find out > whether/how they could log source port, and if possible I will add an > appendix. I need help from the list for this point. The I-D is explaining the drawbacks of logging destination port and the I-D is encouraging server operators to log the source port. It seems useful to point out how easily the server operators can add source port logging. -d > > > > > > -d > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > From rpenno@juniper.net Tue Aug 31 09:04:48 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964643A6846 for ; Tue, 31 Aug 2010 09:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 do9Wyiv2DD8h for ; Tue, 31 Aug 2010 09:04:47 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id F16B73A6827 for ; Tue, 31 Aug 2010 09:04:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTH0oPNKDScjs6jmHBIeYF5ESU5g48tdr@postini.com; Tue, 31 Aug 2010 09:05:18 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 31 Aug 2010 08:49:22 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 31 Aug 2010 11:49:22 -0400 From: Reinaldo Penno To: Tina TSOU , "behave@ietf.org" Date: Tue, 31 Aug 2010 11:49:20 -0400 Thread-Topic: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs Thread-Index: ActGkhR0/IZg3J5TSXqRa4i6guDv8QCkf68q Message-ID: In-Reply-To: <979A43C06A7B488B93D6FFBA8395A033@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.6.0.100712 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 16:04:48 -0000 Hello Tina, We have experience with this method and would like to suggest the following be explained in the draft. 1 - What is a user? A private source IP address? 2 - Sessions that use the ports within a block will end at different times. Do you return the ports to the main port pool? 2.1 - If you return the ports individually to the pool you will not have contiguous ports after some time (even if you want to). If you do not not, your basically statically carving out resources and making poor use of the port space. 3 - If you log the deallocation for every port how much are you actually saving? If you wait for all ports to be freed to send a single log, it migh= t take a long time and you are back to statically carving out resources. 4 - If the port are not contiguous you save the source IP and Dest IP but still need to list every port. The main effect of not having contiguous por= t is that the allocation of ports takes much longer whenever a 'user' is seen= . 4.1 - When will you 'forget' about a user? If you forget about it when all his/her sessions are are gone, you will be trying to allocate blocks of ports often. Thanks, Reinaldo On 8/28/10 2:18 AM, "Tina TSOU" wrote: > Hi Behaver, > Here is an updated version, thanks to the wonderful review from Med. > http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01 >=20 > It is a short, straight forward I-D. I would like to hear your opinion an= d > more comments. What's the next step for it? >=20 >=20 > B. R. > Tina > http://tinatsou.weebly.com/index.html From jmh@joelhalpern.com Tue Aug 31 09:07:38 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3333A69B7 for ; Tue, 31 Aug 2010 09:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 c0iILSfzeSx4 for ; Tue, 31 Aug 2010 09:07:36 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id BF7373A690F for ; Tue, 31 Aug 2010 09:07:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CA5793236DB8; Tue, 31 Aug 2010 09:08:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id BDBC7322822D; Tue, 31 Aug 2010 09:08:06 -0700 (PDT) Message-ID: <4C7D28E2.9010202@joelhalpern.com> Date: Tue, 31 Aug 2010 12:08:02 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dan Wing References: <979A43C06A7B488B93D6FFBA8395A033@china.huawei.com> <08d101cb47fc$05140580$0f3c1080$@com> <1016810CB66A46DBAB30910B68816730@china.huawei.com> <0df901cb4923$bd04c300$370e4900$@com> In-Reply-To: <0df901cb4923$bd04c300$370e4900$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, 'Tina TSOU' Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 16:07:38 -0000 I may be missing something, but given the variations, it seems a heck of a lot more reliable, and more compliant with rules, for operator NATs to log what information they can, and for server logging to be a separate matter. The quesiton of how the NAT writes its logs, and what it writes, depends upon the style of NAT and other implementation details. (For full cone NAT, it seems that logs which show source port allocation, with timestamps, are sufficient to meet most regulatory regimes.) Yours, Joel Dan Wing wrote: >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: Tuesday, August 31, 2010 2:25 AM >> To: behave@ietf.org; Dan Wing >> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale >> NATs >> >> >> B. R. >> Tina >> http://tinatsou.weebly.com/index.html >> ----- Original Message ----- >> From: "Dan Wing" >> To: "'Tina TSOU'" ; >> Sent: Monday, August 30, 2010 12:30 PM >> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale >> NATs >> >> >>>> -----Original Message----- >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>> Behalf Of Tina TSOU >>>> Sent: Saturday, August 28, 2010 2:19 AM >>>> To: behave@ietf.org >>>> Subject: [BEHAVE] Port Management To Reduce Logging In Large-Scale >> NATs >>>> Hi Behaver, >>>> Here is an updated version, thanks to the wonderful review from Med. >>>> http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01 >>>> >>>> It is a short, straight forward I-D. I would like to hear your >> opinion >>>> and more comments. What's the next step for it? >>> Should the block-allocated source ports be re-used? If so, can text >>> be added to describe advantages / disadvantages of such re-use? >> [Tina] Thanks for your thorough review. OK, will add a section to >> describe >> the advantages/disadvantages >> >> >> >> Source port blocks could be reused. When a port block is not used by a >> user >> for a while, the NAT device could allocate this port block to another >> user. >> >> If a port block is not reusable, there could be two scenarios: >> >> 1. Statically configure the same number of ports for each user, e.g. >> each >> can have 2000 ports in this case, there may be a waste of source port >> resource, because maybe not all the users would need so many ports; >> meanwhile some users may need more ports >> >> DS-Lite draft has some discussion about port allocation, >> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite- >> 06#section-8.4 >> >> >> >> 2. Initially, give a user a port block, e.g. a block of 300 ports; when >> the >> user need more port, give the user another port block, e.g. a block of >> 100 >> ports, and so on >> >> In this case, a user may need a lot of ports for a while, but later >> this >> user does not need so many ports, one or more port blocks could be >> released. >> >> >> >> Compared to the above two cases, if a port block is reusable, I can >> increase >> the usage of port resource. >> >> >> >> However, if the block is not reusable, the implementation could be a >> bit >> simpler, e.g. timeout for a port block would not be necessary. >> >> >>> Can a NAT operator determine when a server operator is logging the >>> source port? >> [Tina] No, a NAT operator can not determine that. > > It is useful to point that out in the I-D. > >>> What is the impact if a server is not logging the source port? For >>> example, what happens if a subscriber made a post to a web >>> server and law enforcement asked the ISP for the identity of the >>> subscriber, but the server didn't log the source port? This seems >>> to place the ISP in a difficult situation, requiring the ISP to >>> reveal the identity of all subscribers that were using that IP >>> address at that time. >> [Tina] The impact is that it may not be possible to trace back to a >> single >> if a server is not logging the source port. > > Agreed. It is useful to point that out in the I-D. > >> A NAT device can log the destination IP address of each session, though >> that would not resolve all the problems. >> >> Now a CGN (Carrier Grade NAT) may need to support 10000+ users, it is >> quite >> possible that some users behind a same NAT would visit a same famous >> web >> server, like YouTube, at the same time. In such a case, if the server >> does >> not log the source port and the NAT log the destination IP address, I >> can >> not trace back to a single user, even if "the ISP to reveal the >> identity of >> all subscribers that were using that IP address at that time". > > Agreed. It is useful to point that out in the I-D. > > So, the scenarios are: > > 1. IF server logs source port of incoming connections, > THEN the NAT does not need to log destination. The > server's logs and the NAT's source port logs will be > sufficient to identify the subscriber. > > 2. IF server does not log source port of incoming connections, > AND the NAT does not log destination > THEN the ISP cannot identify which subscriber made the > connection to the server. This might mean the > ISP has to disclose the identity of all the > subscribers that were sharing that IP address. > > 3. If server does not log source port of incoming connections, > AND the NAT does log destination > THEN the ISP can identify the subset of users that > were accessing that server at that time, but > the ISP cannot identify the specific user in > that subset. > > (And, as we agreed above, it is impossible for the NAT to > determine if the server is logging the source port, so the > NAT cannot distinguish between 1 and 2 or between 1 and 3). > >> Since it is required by regulations (rather than by ISP), the server >> should be liable to log the source port. > > What is "it"? I guess you are referring to regulatory requirements that > servers log ports? I am aware of some activity with some regulatory > agencies to include source port in their recommended/required logging, > but I also know that those changes are not yet final. > >> This is discussed in draft-ietf-intarea-shared-addressing-issues-01 >> >> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues- >> 01#section-11 >> >> >>> In an appendix it would be useful to provide configuration examples >>> for popular server software to log the source port (e.g., Apache, >>> IIS, Postfix, Sendmail, sshd, Cyrus IMAP, UW IMAP). For example, I >>> believe it was in Apache version 2.1 that added the ability to log >>> the source port using "%{remote}p" described at >>> http://httpd.apache.org/docs/2.1/mod/mod_log_config.html. >>> And be sure to mention that, for all log file modifications, the >>> source port needs to be added to the log in a way that will work >>> with the server's log analysis scripts. >> [Tina] To be honest, I do not know much about all kinds of the server >> software, I only do network devices. However I will try to find out >> whether/how they could log source port, and if possible I will add an >> appendix. I need help from the list for this point. > > The I-D is explaining the drawbacks of logging destination port and > the I-D is encouraging server operators to log the source port. It seems > useful to point out how easily the server operators can add source port > logging. > > -d > > >> >>> -d >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From iamyanggl@gmail.com Mon Aug 30 19:26:52 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C5D3A67E9; Mon, 30 Aug 2010 19:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45] 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 pL7for2876Hj; Mon, 30 Aug 2010 19:26:49 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 650013A6452; Mon, 30 Aug 2010 19:26:49 -0700 (PDT) Received: by pvg7 with SMTP id 7so2766781pvg.31 for ; Mon, 30 Aug 2010 19:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=gGpTd5+Vf+orFFzAmzyxFP6z4pOKjFnPyt14BOYHfuQ=; b=dVOdU2kIjK0EXXWbgtUfQ9bxU7I6ipUHaZRneh5okpdzTY4dXPNxfmqiNwuKSyRvqW 9Ic5Df9oan1tKn3rdedvc2mtk5zW6q0cSXsN/lDLDlFiDRox6pu5tjGyqJe0BKwEnG0V FUWuiKkVR+UfnpFez0XEV5PHDcK01k2XtEFPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=PUAHTuKi5bA0JeOyQTl9ID5zUWAnf56zAsEqFi/kzF+BYncKVHeeWVfjli0eMsasQQ Pflsm7+oKuYbDjaLVIXS0tEd52bSyuufKXLbT9YZz7G2wKUxr+CluyoJlskR/LDUEVAp jBM00ectzT0ughVRfuGFGJY21XjqB08MgEIyw= Received: by 10.114.26.16 with SMTP id 16mr6273764waz.15.1283221639858; Mon, 30 Aug 2010 19:27:19 -0700 (PDT) Received: from LocalHost ([120.88.10.132]) by mx.google.com with ESMTPS id o17sm9179073wal.21.2010.08.30.19.27.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 19:27:19 -0700 (PDT) From: "YangGL" To: "'Fred Baker'" References: <002a01cb4712$d9f72fb0$8de58f10$@com> In-Reply-To: Date: Tue, 31 Aug 2010 10:27:10 +0800 Message-ID: <00a701cb48b4$08ff66e0$1afe34a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: ActHQLRirzq1ZXVVSzyfKiC4NNyD/QBcX7/A Content-Language: zh-cn X-Mailman-Approved-At: Tue, 31 Aug 2010 09:26:37 -0700 Cc: 'Behave WG' , 'huang cancan' , "'Yiu L. Lee'" , 'IPv6 v6ops' , v4tov6transition@ietf.org Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 02:26:52 -0000 Hi Fred, You are really the dictionary of IPv6! Your mail always make me feel difficult to answer, too many references to read, give me some time, I = will come back after reading those documents mentioned in your mail. Best regards, Yang Guoliang May I ask a question? When you say you tested it with NAT64, what did you test with? There are two modes for translation between IPv4 and IPv6. The stateful mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to = connect to IPv4 systems but not the reverse. The stateless mode, described in draft-ietf-behave-v6v4-xlate, allows connections to be initiated in = either direction. The downside of the stateless mode is that it requires a = direct mapping between an IPv4 and an IPv6 address. The are two parts of a = common framework, use the same addressing plan, and the same DNS extension. Are you running both modes, or only the stateful mode? If you are only running the stateful mode, that what you're reporting is what we have = been saying for some time it will behave like. http://datatracker.ietf.org/doc/draft-ietf-behave-address-format http://tools.ietf.org/html/draft-ietf-behave-address-format "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10, http://datatracker.ietf.org/doc/draft-ietf-behave-dns64 http://tools.ietf.org/html/draft-ietf-behave-dns64 "DNS64: DNS extensions for Network Address Translation from IPv6 = Clients to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, Iljitsch van Beijnum, 5-Jul-10, http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao Bao, Kevin Yin, 17-Aug-10, http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, 22-Aug-10, http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch = van Beijnum, 12-Jul-10, On Aug 28, 2010, at 5:40 PM, YangGL wrote: > Tests in my lab have proved that many popular applications cannot work = on IPv6-only network with NAT64, such as IM, P2P, games, and part of video. = WEB and part of mail (Outlook and Outlook express) are the only applications = we can find working properly with NAT64. But there are more than 50% = traffic is P2P, WEB traffic is less than 20% on CT=A1=AFs network. I think it is = not a good news to NAT64. > Tests also prove that almost all of popular applications on Internet = can work on IPv4-only network with single level and double level NAT44, such = as WEB, mail, IM, P2P, games, video and etc. > NAT64 and NAT44 are similar in theory. But what make the difference of application support? I think it should be timing. NAT44 appears ten = years ago. There are a few applications on internet at that time. Subsequent applications, such as IM, P2P, were designed to work with NAT44. NAT64 = come after this popular applications, situation is totally different. If = NAT64 is deployed on commercial network now, CT=A1=AFs network traffic will cut = down 70% immediately, and most applications will release a new version for = IPv6-only or NAT64 in the next one year. But it is not a good idea to providers. > =20 > Best regards, > Yang Guoliang > =20 > =B7=A2=BC=FE=C8=CB: v4tov6transition-bounces@ietf.org [mailto:v4tov6transition-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA8=D4=C225=C8=D5 22:05 > =CA=D5=BC=FE=C8=CB: huang cancan > =B3=AD=CB=CD: Kurt Erik Lindqvist; IPv6 v6ops; = v4tov6transition@ietf.org > =D6=F7=CC=E2: Re: [v4tov6transition] = draft-arkko-ipv6-transition-guidelines WGLC > =20 > From user=A1=AFs perspective, do they care IPv4 or IPv6? Most = don=A1=AFt. For example: a casual web user wants to access his/her favorite IPv4-only website. If his web client and PC support IPv6 and on an IPv6-only = network with NAT64, the web traffic will go through the NAT once. If his web = client and PC support IPv4-only on an IPv4 network with NAT444, the web traffic will go through the NAT twice. In the end, he/she still gets the same content. From this perspective, both experience =A1=B0could be=A1=B1 = very similar.=20 >=20 > However, this use case is rather limited and not applicable to many applications. This is why I said =A1=B0could be=A1=B1. Also, both = Cameron and I agree that this is easier to implement IPv6-only on mobile network than = on fixed network because mobile operators have more control over the = devices and apps. IMHO, it will take longer time for fixed network operators to support NAT64 only solution in the network. >=20 >=20 > On 8/25/10 9:41 AM, "huang cancan" wrote: >=20 > well, I mean: why customer experience of IPv4-only + NAT444 could be = the same as IPv6-only + NAT64? >=20 > On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee = wrote: > In order to deploy IPv6-only + NAT64, the client and network must talk IPv6. It also requires DNS64. These requirements are not needed for IPv4-only + NAT444. From the deployment point of view, they are very different technologies.=20 >=20 >=20 >=20 > On 8/25/10 7:13 AM, "huang cancan" > wrote: >=20 > hi,Yiu: > As you mentioned below: > > All I am saying is the customer > > experience of IPv4-only + NAT444 could be the same as IPv6-only + = NAT64, but > > the technologies and plan to offer these service are very different. > =20 > Do you have any test data to support this conclusion? > =20 > Can-can Huang >=20 >=20 > On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee > wrote: >=20 > > Agreed. The 2x cost is really just the packet core ... which is of > > course a lot of money to double for no tangible benefit ..... talk > > about no business case .... And, still have numbering issues, = customer > > experience is the same as IPv4-only + NAT44 and approximately the = same > > as IPv6-only + NAT64 > > > Life cycle of mobile equipments could be every 2-3 years, but life = cycle of > consumer electronics could be 5+ years. Consider many large TVs with > Internet service selling today are still running IPv4-only, fixed line > operators must prepare to support them in foreseeable future. >=20 > That said, I am not saying an operator must build a dual-stack core network, > there are technologies such as DS-lite and Softwire Mesh available to = run a > pure IPv6 core network with dual-stack edge. All I am saying is the customer > experience of IPv4-only + NAT444 could be the same as IPv6-only + = NAT64, but > the technologies and plan to offer these service are very different. >=20 >=20 >=20 > _______________________________________________ > v4tov6transition mailing list > v4tov6transition@ietf.org =20 > https://www.ietf.org/mailman/listinfo/v4tov6transition > =20 >=20 > =20 >=20 > _______________________________________________ > v4tov6transition mailing list > v4tov6transition@ietf.org > https://www.ietf.org/mailman/listinfo/v4tov6transition From cancanhuang110@gmail.com Mon Aug 30 18:38:19 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53943A68CF; Mon, 30 Aug 2010 18:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45] 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 uaJc1a54etkU; Mon, 30 Aug 2010 18:38:06 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5FD0A3A6A1F; Mon, 30 Aug 2010 18:38:05 -0700 (PDT) Received: by bwz9 with SMTP id 9so5022498bwz.31 for ; Mon, 30 Aug 2010 18:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PXH7l4oJQJp/EJRkG/QBPD+TqyWVLSOKbYz213s1i2c=; b=KtEtgt6Zz4Pjr9T6zJ7Wf9n6NYVri3XCb8UGH2O3+dHHsKCa5bUR7w011U77Gl8v1F RNpYacjCDGwhOvBy+ng4iPYnTClPjs338NkITc+yPgpJn5tgqY2U7tp2/sVRl9qHCNKQ +WPYfOIcHuATyVFbNcNHiA4XyOVpAWYjGnaXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=u5XkYZKTKTEjcTNA0xOkoThVIJhRXPJ6q2MfOwHW0DxlDYhnSqiz2bAsZhU8b/6sLt +5h9YjIXXEZRB8fwgnfkX0kZl4BJMA5HLBWBHbeUqxaurdpqymKrvQvCUo6xxFuTyE8A sVbvGgOBhfec9rUp9RkxXcJAev8M8thTSMgU4= MIME-Version: 1.0 Received: by 10.204.57.130 with SMTP id c2mr3914690bkh.110.1283218715422; Mon, 30 Aug 2010 18:38:35 -0700 (PDT) Received: by 10.204.161.193 with HTTP; Mon, 30 Aug 2010 18:38:34 -0700 (PDT) In-Reply-To: <4C7C32D2.70909@gmail.com> References: <002a01cb4712$d9f72fb0$8de58f10$@com> <4C7C32D2.70909@gmail.com> Date: Tue, 31 Aug 2010 09:38:34 +0800 Message-ID: From: huang cancan To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001636c5b324b3b171048f14a3be X-Mailman-Approved-At: Tue, 31 Aug 2010 09:26:50 -0700 Cc: IPv6 v6ops , Behave WG , Fred Baker , v4tov6transition@ietf.org Subject: Re: [BEHAVE] [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 01:38:19 -0000 --001636c5b324b3b171048f14a3be Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Brian: Yes, we didn't test the applications with clients installed in people's PC no matter the NAT64 is a stateful one or a stateless one. I think we have a little different understanding about the original question:"why customer experience of IPv4-only + NAT444 could be the same a= s IPv6-only + NAT64? Do you have any test data?" I asked this question for th= e sake of making up our migration strategy. What we focus on is the customer experiences, so if now the clients cannot support IPv6, we think the customer experience when we using NAT64 i= n our network in the first phase is worse than using NAT444+IPv4 because most clients supporting NAT444. And what you focus on is the NAT64, the technology itself, so you think if there is no test on NAT64, we cannot draw the conclusion that NAT444 is better than NAT64. By the way, we also think it NAT444+IPv4-only cannot solve the problem ultimately, NAT444+IPv6 should be better in the first phase. Thanks. On Tue, Aug 31, 2010 at 6:38 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > On 2010-08-30 21:26, huang cancan wrote: > > Another reason why we don't test stateless NAT64 is that there are few > > application clients support IPv6, we can only test web or mail > applications > > which are also OK with the stateful one. > > But you reported other applications failing. How can they fail with NAT64 > if > they have no IPv6 support in the first place? > > Brian > > > 2010/8/29 Fred Baker > > > >> > >> > >> > >> May I ask a question? > >> > >> When you say you tested it with NAT64, what did you test with? > >> > >> There are two modes for translation between IPv4 and IPv6. The statefu= l > >> mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essential= ly > >> identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to > connect > >> to IPv4 systems but not the reverse. The stateless mode, described in > >> draft-ietf-behave-v6v4-xlate, allows connections to be initiated in > either > >> direction. The downside of the stateless mode is that it requires a > direct > >> mapping between an IPv4 and an IPv6 address. The are two parts of a > common > >> framework, use the same addressing plan, and the same DNS extension. > >> > >> Are you running both modes, or only the stateful mode? If you are only > >> running the stateful mode, that what you're reporting is what we have > been > >> saying for some time it will behave like. > >> > >> http://datatracker.ietf.org/doc/draft-ietf-behave-address-format > >> http://tools.ietf.org/html/draft-ietf-behave-address-format > >> "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian > >> Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10, > >> > >> > >> http://datatracker.ietf.org/doc/draft-ietf-behave-dns64 > >> http://tools.ietf.org/html/draft-ietf-behave-dns64 > >> "DNS64: DNS extensions for Network Address Translation from IPv6 > Clients > >> to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, > >> Iljitsch van Beijnum, 5-Jul-10, > >> > >> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework > >> http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework > >> "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao > >> Bao, Kevin Yin, 17-Aug-10, > >> > >> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate > >> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate > >> "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, > >> 22-Aug-10, > >> > >> http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful > >> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful > >> "Stateful NAT64: Network Address and Protocol Translation from IPv6 > >> Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch > van > >> Beijnum, 12-Jul-10, > >> > >> > >> On Aug 28, 2010, at 5:40 PM, YangGL wrote: > >> > >>> Tests in my lab have proved that many popular applications cannot wor= k > on > >> IPv6-only network with NAT64, such as IM, P2P, games, and part of vide= o. > WEB > >> and part of mail (Outlook and Outlook express) are the only applicatio= ns > we > >> can find working properly with NAT64. But there are more than 50% > traffic is > >> P2P, WEB traffic is less than 20% on CT=A1=AFs network. I think it is = not a > good > >> news to NAT64. > >>> Tests also prove that almost all of popular applications on Internet > can > >> work on IPv4-only network with single level and double level NAT44, su= ch > as > >> WEB, mail, IM, P2P, games, video and etc. > >>> NAT64 and NAT44 are similar in theory. But what make the difference o= f > >> application support? I think it should be timing. NAT44 appears ten > years > >> ago. There are a few applications on internet at that time. Subsequent > >> applications, such as IM, P2P, were designed to work with NAT44. NAT64 > come > >> after this popular applications, situation is totally different. If > NAT64 is > >> deployed on commercial network now, CT=A1=AFs network traffic will cut= down > 70% > >> immediately, and most applications will release a new version for > IPv6-only > >> or NAT64 in the next one year. But it is not a good idea to providers. > >>> Best regards, > >>> Yang Guoliang > >>> > >>> =B7=A2=BC=FE=C8=CB: v4tov6transition-bounces@ietf.org [mailto: > >> v4tov6transition-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee > >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA8=D4=C225=C8=D5 22:05 > >>> =CA=D5=BC=FE=C8=CB: huang cancan > >>> =B3=AD=CB=CD: Kurt Erik Lindqvist; IPv6 v6ops; v4tov6transition@ietf.= org > >>> =D6=F7=CC=E2: Re: [v4tov6transition] draft-arkko-ipv6-transition-guid= elines WGLC > >>> > >>> From user=A1=AFs perspective, do they care IPv4 or IPv6? Most don=A1= =AFt. For > >> example: a casual web user wants to access his/her favorite IPv4-only > >> website. If his web client and PC support IPv6 and on an IPv6-only > network > >> with NAT64, the web traffic will go through the NAT once. If his web > client > >> and PC support IPv4-only on an IPv4 network with NAT444, the web traff= ic > >> will go through the NAT twice. In the end, he/she still gets the same > >> content. From this perspective, both experience =A1=B0could be=A1=B1 v= ery similar. > >>> However, this use case is rather limited and not applicable to many > >> applications. This is why I said =A1=B0could be=A1=B1. Also, both Came= ron and I > agree > >> that this is easier to implement IPv6-only on mobile network than on > fixed > >> network because mobile operators have more control over the devices an= d > >> apps. IMHO, it will take longer time for fixed network operators to > support > >> NAT64 only solution in the network. > >>> > >>> On 8/25/10 9:41 AM, "huang cancan" wrote: > >>> > >>> well, I mean: why customer experience of IPv4-only + NAT444 could be > the > >> same as IPv6-only + NAT64? > >>> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee > > >> wrote: > >>> In order to deploy IPv6-only + NAT64, the client and network must tal= k > >> IPv6. It also requires DNS64. These requirements are not needed for > >> IPv4-only + NAT444. From the deployment point of view, they are very > >> different technologies. > >>> > >>> > >>> On 8/25/10 7:13 AM, "huang cancan" >> http://cancanhuang110@gmail.com> > wrote: > >>> hi,Yiu: > >>> As you mentioned below: > >>>> All I am saying is the customer > >>>> experience of IPv4-only + NAT444 could be the same as IPv6-only + > >> NAT64, but > >>>> the technologies and plan to offer these service are very different. > >>> Do you have any test data to support this conclusion? > >>> > >>> Can-can Huang > >>> > >>> > >>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee >> http://yiu_lee@cable.comcast.com> > wrote: > >>>> Agreed. The 2x cost is really just the packet core ... which is of > >>>> course a lot of money to double for no tangible benefit ..... talk > >>>> about no business case .... And, still have numbering issues, custom= er > >>>> experience is the same as IPv4-only + NAT44 and approximately the sa= me > >>>> as IPv6-only + NAT64 > >>>> > >>> Life cycle of mobile equipments could be every 2-3 years, but life > cycle > >> of > >>> consumer electronics could be 5+ years. Consider many large TVs with > >>> Internet service selling today are still running IPv4-only, fixed lin= e > >>> operators must prepare to support them in foreseeable future. > >>> > >>> That said, I am not saying an operator must build a dual-stack core > >> network, > >>> there are technologies such as DS-lite and Softwire Mesh available to > run > >> a > >>> pure IPv6 core network with dual-stack edge. All I am saying is the > >> customer > >>> experience of IPv4-only + NAT444 could be the same as IPv6-only + > NAT64, > >> but > >>> the technologies and plan to offer these service are very different. > >>> > >>> > >>> > >>> _______________________________________________ > >>> v4tov6transition mailing list > >>> v4tov6transition@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v4tov6transition > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> v4tov6transition mailing list > >>> v4tov6transition@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v4tov6transition > >> > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > v4tov6transition mailing list > > v4tov6transition@ietf.org > > https://www.ietf.org/mailman/listinfo/v4tov6transition > > --001636c5b324b3b171048f14a3be Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
hi, Brian:
   Yes, we didn't test the applications with clients ins= talled in people's PC no matter the NAT64 is a stateful one or a s= tateless one.
    I think we have a little different understanding ab= out the original question:"why customer experience of IPv4-only + NAT4= 44 could be the same as IPv6-only + NAT64? Do you have any test data?"=  I asked this question for the sake of making up our migration strateg= y.
    What we focus on is the customer experiences, so if= now the clients cannot support IPv6, we think the customer experience when= we using NAT64 in our network in the first phase is worse than u= sing NAT444+IPv4 because most clients supporting NAT444.
   And what you focus on is the NAT64, the technology itself= , so you think if there is no test on NAT64, we cannot draw the conclusion = that NAT444 is better than NAT64.
   By the way, we also think it NAT444+IPv4-only cannot solv= e the problem ultimately, NAT444+IPv6 should be better in the first phase.<= /div>
 
  Thanks.
   

On Tue, Aug 31, 2010 at 6:38 AM, Brian E Carpent= er <bri= an.e.carpenter@gmail.com> wrote:
Hi,

On 2010-08-30 21:26, huang cancan wrote:
> Anot= her reason why we don't test stateless NAT64 is that there are few
&= gt; application clients support IPv6, we can only test web or mail applicat= ions
> which are also OK with the stateful one.

But you reported= other applications failing. How can they fail with NAT64 if
they have n= o IPv6 support in the first place?

  Br= ian

> 2010/8/29 Fred Baker <fred@cisco.com>
>
>> </chair> <!-= - v6ops -->
>> <author> <!-- draft-ietf-behave-v6v4-xl= ate -->
>>
>> May I ask a question?
>>
>> When you= say you tested it with NAT64, what did you test with?
>>
>&= gt; There are two modes for translation between IPv4 and IPv6. The stateful=
>> mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essen= tially
>> identical in function to IPv4/IPv4 NAT, and allows IPv6 = systems to connect
>> to IPv4 systems but not the reverse. The sta= teless mode, described in
>> draft-ietf-behave-v6v4-xlate, allows connections to be initiated i= n either
>> direction. The downside of the stateless mode is that = it requires a direct
>> mapping between an IPv4 and an IPv6 addres= s. The are two parts of a common
>> framework, use the same addressing plan, and the same DNS extensio= n.
>>
>> Are you running both modes, or only the stateful= mode? If you are only
>> running the stateful mode, that what you= 're reporting is what we have been
>> saying for some time it will behave like.
>>
>> = http://datatracker.ietf.org/doc/draft-ietf-behave-addre= ss-format
>> http://tools.ietf.org/html/draft-ietf-behave-addres= s-format
>>  "IPv6 Addressing of IPv4/IPv6 Translato= rs", Congxiao Bao, Christian
>>  Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Au= g-10,
>>  <draft-ietf-behave-address-format-10.txt>
= >>
>> http://datatracker.ietf.org/doc/draft-ietf-= behave-dns64
>> http://tools.ietf.org/html/draft-ietf-behave-dns64
&g= t;>  "DNS64: DNS extensions for Network Address Translation fr= om IPv6 Clients
>>  to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Phi= lip Matthews,
>>  Iljitsch van Beijnum, 5-Jul-10, <draft-i= etf-behave-dns64-10.txt>
>>
>> htt= p://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework
>> http://tools.ietf.org/html/draft-ietf-behave-v6v4-f= ramework
>>  "Framework for IPv4/IPv6 Translation&qu= ot;, Fred Baker, Xing Li, Congxiao
>>  Bao, Kevin Yin, 17-Aug-10, <draft-ietf-behave-v6v4-framew= ork-10.txt>
>>
>> http://datatracker.i= etf.org/doc/draft-ietf-behave-v6v4-xlate
>> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate=
>>  "IP/ICMP Translation Algorithm", Xing Li, = Congxiao Bao, Fred Baker,
>>  22-Aug-10, <draft-ietf-behave-v6v4-xlate-22.txt>
&g= t;>
>> http://datatracker.ietf.org/doc= /draft-ietf-behave-v6v4-xlate-stateful
>> http://tools.ietf.org/html/draft-ietf-behave-v= 6v4-xlate-stateful
>>  "Stateful NAT64: Network Addr= ess and Protocol Translation from IPv6
>>  Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matth= ews, Iljitsch van
>>  Beijnum, 12-Jul-10, <draft-ietf-beha= ve-v6v4-xlate-stateful-12.txt>
>>
>>
>> On Au= g 28, 2010, at 5:40 PM, YangGL wrote:
>>
>>> Tests in my lab have proved that many popular appl= ications cannot work on
>> IPv6-only network with NAT64, such as I= M, P2P, games, and part of video. WEB
>> and part of mail (Outlook= and Outlook express) are the only applications we
>> can find working properly with NAT64. But there are more than 50% = traffic is
>> P2P, WEB traffic is less than 20% on CT’s netw= ork. I think it is not a good
>> news to NAT64.
>>> Te= sts also prove that almost all of popular applications on Internet can
>> work on IPv4-only network with single level and double level NAT44= , such as
>> WEB, mail, IM, P2P, games, video and etc.
>>= > NAT64 and NAT44 are similar in theory. But what make the difference of=
>> application support? I think it should be timing. NAT44 appears te= n years
>> ago. There are a few applications on internet at that t= ime. Subsequent
>> applications, such as IM, P2P, were designed to= work with NAT44. NAT64 come
>> after this popular applications, situation is totally different. I= f NAT64 is
>> deployed on commercial network now, CT’s netwo= rk traffic will cut down 70%
>> immediately, and most applications= will release a new version for IPv6-only
>> or NAT64 in the next one year. But it is not a good idea to provid= ers.
>>> Best regards,
>>> Yang Guoliang
>>= ;>
>>> =B7=A2=BC=FE=C8=CB: v4tov6transition-bounces@ietf.org [mailto:
>> v4tov6transit= ion-bounces@ietf.org] =B4=FA=B1=ED Yiu L. Lee
>>> =B7=A2=CB= =CD=CA=B1=BC=E4: 2010=C4=EA8=D4=C225=C8=D5 22:05
>>> =CA=D5=BC= =FE=C8=CB: huang cancan
>>> =B3=AD=CB=CD: Kurt Erik Lindqvist; = IPv6 v6ops; v4tov6transition@i= etf.org
>>> =D6=F7=CC=E2: Re: [v4tov6transition] draft-arkko-ipv6-transiti= on-guidelines WGLC
>>>
>>> From user’s perspe= ctive, do they care IPv4 or IPv6? Most don’t. For
>> example= : a casual web user wants to access his/her favorite IPv4-only
>> website. If his web client and PC support IPv6 and on an IPv6-only= network
>> with NAT64, the web traffic will go through the NAT on= ce. If his web client
>> and PC support IPv4-only on an IPv4 netwo= rk with NAT444, the web traffic
>> will go through the NAT twice. In the end, he/she still gets the s= ame
>> content. From this perspective, both experience “coul= d be” very similar.
>>> However, this use case is rather = limited and not applicable to many
>> applications. This is why I said “could be”. Also, bot= h Cameron and I agree
>> that this is easier to implement IPv6-onl= y on mobile network than on fixed
>> network because mobile operat= ors have more control over the devices and
>> apps. IMHO, it will take longer time for fixed network operators t= o support
>> NAT64 only solution in the network.
>>>>>> On 8/25/10 9:41 AM, "huang cancan" <cancanhuang110@gmail.com> wrote: >>>
>>> well, I mean: why customer experience of IPv4-= only + NAT444 could be the
>> same as IPv6-only + NAT64?
>&g= t;> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <yiu_lee@cable.comcast.com>
>> wrote:
>>> In order to deploy IPv6-only + NAT64, the c= lient and network must talk
>> IPv6. It also requires DNS64. These= requirements are not needed for
>> IPv4-only + NAT444. From the d= eployment point of view, they are very
>> different technologies.
>>>
>>>
>>= ;> On 8/25/10 7:13 AM, "huang cancan" <cancanhuang110@gmail.com <
>> http://cancanhuang110@<= a href=3D"http://gmail.com/" target=3D"_blank">gmail.com> > wrote= :
>>> hi,Yiu:
>>>   As you mentioned below:
>= >>> All I am saying is the customer
>>>> experience= of IPv4-only + NAT444 could be the same as IPv6-only +
>> NAT64, = but
>>>> the technologies and plan to offer these service are very = different.
>>>   Do you have any test data to support this= conclusion?
>>>
>>> Can-can Huang
>>><= br> >>>
>>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee &l= t;yiu_lee@cable.comcast.com <
>> http://yiu= _lee@cable.comc= ast.com> > wrote:
>>>> Agreed.  The 2x cost is really just the packet core .= .. which is of
>>>> course a lot of money to double for no t= angible benefit ..... talk
>>>> about no business case .... = And, still have numbering issues, customer
>>>> experience is the same as IPv4-only + NAT44 and approximat= ely the same
>>>> as IPv6-only + NAT64
>>>>>>> Life cycle of mobile equipments could be every 2-3 years, bu= t life cycle
>> of
>>> consumer electronics could be 5+ years. Conside= r many large TVs with
>>> Internet service selling today are st= ill running IPv4-only, fixed line
>>> operators must prepare to= support them in foreseeable future.
>>>
>>> That said, I am not saying an operator must bu= ild a dual-stack core
>> network,
>>> there are techno= logies such as DS-lite and Softwire Mesh available to run
>> a
>>> pure IPv6 core network with dual-stack edge. All I am saying i= s the
>> customer
>>> experience of IPv4-only + NAT444= could be the same as IPv6-only + NAT64,
>> but
>>> th= e technologies and plan to offer these service are very different.
>>>
>>>
>>>
>>> ______________= _________________________________
>>> v4tov6transition mailing = list
>>> v4tov6tra= nsition@ietf.org <http://v4tov6transition@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/v4tov6transiti= on
>>>
>>>
>>>
>>>
&= gt;>> _______________________________________________
>>> v4tov6transition mailing list
>>> v4tov6transition@ietf.org
>>> = https://www.ietf.org/mailman/listinfo/v4tov6transition
>>
>
>
> ------------------------------= ------------------------------------------
>
> ____________________________________________= ___
> v4tov6transition mailing list
> v4tov6transition@ietf.org
> https:/= /www.ietf.org/mailman/listinfo/v4tov6transition


--001636c5b324b3b171048f14a3be-- From tena@huawei.com Tue Aug 31 20:59:44 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B843A68C5 for ; Tue, 31 Aug 2010 20:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.924 X-Spam-Level: X-Spam-Status: No, score=-99.924 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] 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 Ys8hlogLzKt2 for ; Tue, 31 Aug 2010 20:59:42 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E36593A63EC for ; Tue, 31 Aug 2010 20:59:41 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8100387V41OA@szxga02-in.huawei.com> for behave@ietf.org; Wed, 01 Sep 2010 12:00:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L81006JZV41B3@szxga02-in.huawei.com> for behave@ietf.org; Wed, 01 Sep 2010 12:00:01 +0800 (CST) Received: from z00147053k ([10.70.39.122]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8100GA9V418S@szxml06-in.huawei.com> for behave@ietf.org; Wed, 01 Sep 2010 12:00:01 +0800 (CST) Date: Wed, 01 Sep 2010 12:00:01 +0800 From: Tina TSOU To: behave@ietf.org, Dan Wing Message-id: <19E23FDFCBDE4616B28238550D8D4C9A@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <979A43C06A7B488B93D6FFBA8395A033@china.huawei.com> <08d101cb47fc$05140580$0f3c1080$@com> <1016810CB66A46DBAB30910B68816730@china.huawei.com> <0df901cb4923$bd04c300$370e4900$@com> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 03:59:44 -0000 B. R. Tina http://tinatsou.weebly.com/index.html ----- Original Message ----- From: "Dan Wing" To: "'Tina TSOU'" ; Sent: Tuesday, August 31, 2010 11:46 PM Subject: RE: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: Tuesday, August 31, 2010 2:25 AM >> To: behave@ietf.org; Dan Wing >> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale >> NATs >> >> >> B. R. >> Tina >> http://tinatsou.weebly.com/index.html >> ----- Original Message ----- >> From: "Dan Wing" >> To: "'Tina TSOU'" ; >> Sent: Monday, August 30, 2010 12:30 PM >> Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale >> NATs >> >> >> >> -----Original Message----- >> >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> >> Behalf Of Tina TSOU >> >> Sent: Saturday, August 28, 2010 2:19 AM >> >> To: behave@ietf.org >> >> Subject: [BEHAVE] Port Management To Reduce Logging In Large-Scale >> NATs >> >> >> >> Hi Behaver, >> >> Here is an updated version, thanks to the wonderful review from Med. >> >> http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01 >> >> >> >> It is a short, straight forward I-D. I would like to hear your >> opinion >> >> and more comments. What's the next step for it? >> > >> > Should the block-allocated source ports be re-used? If so, can text >> > be added to describe advantages / disadvantages of such re-use? >> [Tina] Thanks for your thorough review. OK, will add a section to >> describe >> the advantages/disadvantages >> >> >> >> Source port blocks could be reused. When a port block is not used by a >> user >> for a while, the NAT device could allocate this port block to another >> user. >> >> If a port block is not reusable, there could be two scenarios: >> >> 1. Statically configure the same number of ports for each user, e.g. >> each >> can have 2000 ports in this case, there may be a waste of source port >> resource, because maybe not all the users would need so many ports; >> meanwhile some users may need more ports >> >> DS-Lite draft has some discussion about port allocation, >> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite- >> 06#section-8.4 >> >> >> >> 2. Initially, give a user a port block, e.g. a block of 300 ports; when >> the >> user need more port, give the user another port block, e.g. a block of >> 100 >> ports, and so on >> >> In this case, a user may need a lot of ports for a while, but later >> this >> user does not need so many ports, one or more port blocks could be >> released. >> >> >> >> Compared to the above two cases, if a port block is reusable, I can >> increase >> the usage of port resource. >> >> >> >> However, if the block is not reusable, the implementation could be a >> bit >> simpler, e.g. timeout for a port block would not be necessary. >> >> >> > >> > Can a NAT operator determine when a server operator is logging the >> > source port? >> [Tina] No, a NAT operator can not determine that. > > It is useful to point that out in the I-D. [Tina] OK, will add it in -02 version. > >> > What is the impact if a server is not logging the source port? For >> > example, what happens if a subscriber made a post to a web >> > server and law enforcement asked the ISP for the identity of the >> > subscriber, but the server didn't log the source port? This seems >> > to place the ISP in a difficult situation, requiring the ISP to >> > reveal the identity of all subscribers that were using that IP >> > address at that time. >> [Tina] The impact is that it may not be possible to trace back to a >> single >> if a server is not logging the source port. > > Agreed. It is useful to point that out in the I-D. [Tina] OK, will add it in -02 version. > >> A NAT device can log the destination IP address of each session, though >> that would not resolve all the problems. >> >> Now a CGN (Carrier Grade NAT) may need to support 10000+ users, it is >> quite >> possible that some users behind a same NAT would visit a same famous >> web >> server, like YouTube, at the same time. In such a case, if the server >> does >> not log the source port and the NAT log the destination IP address, I >> can >> not trace back to a single user, even if "the ISP to reveal the >> identity of >> all subscribers that were using that IP address at that time". > > Agreed. It is useful to point that out in the I-D. > > So, the scenarios are: > > 1. IF server logs source port of incoming connections, > THEN the NAT does not need to log destination. The > server's logs and the NAT's source port logs will be > sufficient to identify the subscriber. > > 2. IF server does not log source port of incoming connections, > AND the NAT does not log destination > THEN the ISP cannot identify which subscriber made the > connection to the server. This might mean the > ISP has to disclose the identity of all the > subscribers that were sharing that IP address. > > 3. If server does not log source port of incoming connections, > AND the NAT does log destination > THEN the ISP can identify the subset of users that > were accessing that server at that time, but > the ISP cannot identify the specific user in > that subset. > > (And, as we agreed above, it is impossible for the NAT to > determine if the server is logging the source port, so the > NAT cannot distinguish between 1 and 2 or between 1 and 3). [Tina] OK, will add it in -02 version. > >> Since it is required by regulations (rather than by ISP), the server >> should be liable to log the source port. > > What is "it"? I guess you are referring to regulatory requirements that > servers log ports? I am aware of some activity with some regulatory > agencies to include source port in their recommended/required logging, > but I also know that those changes are not yet final. [Tina] Yes, you are right. > >> This is discussed in draft-ietf-intarea-shared-addressing-issues-01 >> >> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues- >> 01#section-11 >> >> >> > >> > In an appendix it would be useful to provide configuration examples >> > for popular server software to log the source port (e.g., Apache, >> > IIS, Postfix, Sendmail, sshd, Cyrus IMAP, UW IMAP). For example, I >> > believe it was in Apache version 2.1 that added the ability to log >> > the source port using "%{remote}p" described at >> > http://httpd.apache.org/docs/2.1/mod/mod_log_config.html. >> > And be sure to mention that, for all log file modifications, the >> > source port needs to be added to the log in a way that will work >> > with the server's log analysis scripts. >> [Tina] To be honest, I do not know much about all kinds of the server >> software, I only do network devices. However I will try to find out >> whether/how they could log source port, and if possible I will add an >> appendix. I need help from the list for this point. > > The I-D is explaining the drawbacks of logging destination port and > the I-D is encouraging server operators to log the source port. It seems > useful to point out how easily the server operators can add source port > logging. [Tina] will try to add it in -02 version. > > -d > > >> >> >> > >> > -d >> > >> > >> > _______________________________________________ >> > Behave mailing list >> > Behave@ietf.org >> > https://www.ietf.org/mailman/listinfo/behave >> > > > >