Re: [v6ops] draft-ietf-v6ops-nat64-experience-02.txt comments

GangChen <phdgang@gmail.com> Thu, 11 July 2013 03:19 UTC

Return-Path: <phdgang@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90CB11E80F1 for <v6ops@ietfa.amsl.com>; Wed, 10 Jul 2013 20:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level:
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5izemWTDPu4 for <v6ops@ietfa.amsl.com>; Wed, 10 Jul 2013 20:19:34 -0700 (PDT)
Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0427A11E80EF for <v6ops@ietf.org>; Wed, 10 Jul 2013 20:19:33 -0700 (PDT)
Received: by mail-qe0-f47.google.com with SMTP id 1so4167950qec.20 for <v6ops@ietf.org>; Wed, 10 Jul 2013 20:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VeE83b8BhvpucFMi8goTrcRXERQ2lbNAxCTIURz1E/8=; b=p1vDXa+vRs4I9/d8NYWwgHT695u1TzPUG1ghk905S4V/U6Zdq7SmaXRZDJvTpFxUAj bgEXwFlbwfKJqYpGWSxGop7ystRE8MMQObfK9/DH4C762YyVu+6+141w9gKbEg32uY5/ 9IH9PVo1/95nfqcBpMgxxA3eRKd85j0p4QVMNtUtP8RGRqacOCQ3pzwIuXNMStJCrnPX 19/NLzrJCrGDSvfWeZj9V2om1LhINqfxYGl8HjnVBs6jxMU1aaJSkJtR84UzSK7Ufwgd slOmTgI8H1lgQFfUYwEw37DWNp0vZpjcs2RacBfU2FiPHps41mPgSqCstGKrUBDUznxs /u4g==
MIME-Version: 1.0
X-Received: by 10.49.29.106 with SMTP id j10mr28649101qeh.37.1373512769346; Wed, 10 Jul 2013 20:19:29 -0700 (PDT)
Received: by 10.224.193.195 with HTTP; Wed, 10 Jul 2013 20:19:29 -0700 (PDT)
In-Reply-To: <51DD789E.8090306@gmail.com>
References: <alpine.DEB.2.00.1307101000270.8891@uplift.swm.pp.se> <CAM+vMET=MdpLgeQXH2Lk_j2YqNdaKxehrzjPjFJsts2qAZmSog@mail.gmail.com> <alpine.DEB.2.00.1307101232120.8891@uplift.swm.pp.se> <51DD789E.8090306@gmail.com>
Date: Thu, 11 Jul 2013 11:19:29 +0800
Message-ID: <CAM+vMEQPVCUX2df+xndtx4BjULe0FGgmObaYiro1QFdoMvJyuQ@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience-02.txt comments
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2013 03:19:35 -0000

2013/7/10, Tom Taylor <tom.taylor.stds@gmail.com>:
> We are working on logging drafts in Behave. Bulk port allocation can
> work as Mikael states. On the other hand, if the provider is using MAP
> or Lightweight 4over6, port allocation happens at provisioning time and
> may if desired be logged by network infrastructure (DHCP, AAA).

I guess the bulk port allocation is a natural part of MAP or
Lightweight4ovr6 or A+P. If the system is aware of the mapping rules,
the log information may not be necessary


> Tom Taylor
>
> On 10/07/2013 6:35 AM, Mikael Abrahamsson wrote:
>> On Wed, 10 Jul 2013, GangChen wrote:
>>
>>> That is an interesting use. How do you implement those IPv4 pool
>>> allocations?  I heard some NAT64 implementations could allocate
>>> different IPv4 pools to each inbound interface. Are you doing in the
>>> similar way?
>>
>> Some vendors allow certain IPv6 source addresses to go to certain
>> outside IPv4 pool of addresses.
>>
>>> If I understand correctly, that is a static port block allocation. A
>>> port block would be reserved to a particular customer. No logging
>>> information needed. will clarify at the next update.
>>
>> Well, actually the block would be allocated upon first traffic seen from
>> a certain source IPv6 address. Perhaps there are references to this in
>> other RFCs that could be useful.
>>
>> For instance (I'm sure there are a lot more):
>>
>> http://www.ietf.org/proceedings/86/slides/slides-86-behave-2
>>
>> http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/cg_nat/configuration/guide/cgnat43cgn.html#wp1015343
>>
>>
>> Bulk Port Allocation
>>
>> The creation and deletion of NAT sessions need to be logged and these
>> create huge amount of data. These are stored on Syslog collector which
>> is supported over UDP. In order to reduce the volume of data generated
>> by the NAT device, bulk port allocation can be enabled. When bulk port
>> allocation is enabled and when a subscriber creates the first session, a
>> number of contiguous outside ports are pre-allocated. A bulk allocation
>> message is logged indicating this allocation. Subsequent session
>> creations will use one of the pre-allocated port and hence does not
>> require logging.
>>
>