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

[GangChen <[e-mail]>]

Many thanks for the information.
The next update would catch those two points.

BRs

Gang

2013/7/10, Mikael Abrahamsson <[e-mail]>:
> 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.
>
> --
> Mikael Abrahamsson    email: [e-mail]
>