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

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 Jul 2013 10:01:12 +0200 (CEST)

2013/7/10, Mikael Abrahamsson <[email-masked]>:
> On Tue, 9 Jul 2013, GangChen wrote:
>
>> Hi Mikael,
>>
>> Thanks for the message. We are also doing the NAT64 testing recently.
>> Some experiences have been documented in
>> http://www.ietf.org/id/draft-ietf-v6ops-nat64-experience-02.txt
>> Not sure if you have interests to read and comment
>
> 1. "Single stack IPv6 network deployment can simplify the network
>     provisioning. ". I would remove "the" frmo this sentence.
>
> I think it's good that you stress the benefit of having access being
> single stack instead of dual stack.
>
> 3.1
>
> I think it might be beneficial to say a little bit more here why 464xlat
> is important, perhaps just one sentence "464XLAT enables access of IPv4
> only applications or applications that call IPv4 literal addresses" (or
> similar).
>
> About geo-location, perhaps it can be adviced to chop up the outside IPv4
> address pool so that IPv6 addresses are NAT64:ed depending on their
> geographical location (we're doing this on a per country basis).
>
> 5.1
>
> I would like some text on "port block allocation", where a customer gets
> 512 or 1024 ports, this is logged, which means as long as the same
> customer still has this 512 port block, no further logging is needed.
>
>
>
> Apart from that the document looks good, and nothing more came to mind
> when I read it.
>
>
> --
> Mikael Abrahamsson    email: [email-masked]
>

---

From: GangChen <[email-masked]>
Date: Wed, 10 Jul 2013 18:16:51 +0800

Hi Mikael,

>> only applications or applications that call IPv4 literal addresses" (or

Will add the texts to describe the benefits of 464xlat

>> geographical location (we're doing this on a per country basis).

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?

>> customer still has this 512 port block, no further logging is needed.

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.

>> Apart from that the document looks good, and nothing more came to mind

Many thanks for the review.

Best Regards

Gang

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 Jul 2013 12:35:40 +0200 (CEST)

> different IPv4 pools to each inbound interface. Are you doing in the 

Some vendors allow certain IPv6 source addresses to go to certain outside 
IPv4 pool of addresses.

> 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.

---

From: GangChen <[email-masked]>
Date: Wed, 10 Jul 2013 18:50:51 +0800

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

BRs

Gang

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Jul 2013 11:07:10 -0400

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).

Tom Taylor

On 10/07/2013 6:35 AM, Mikael Abrahamsson wrote:
> Some vendors allow certain IPv6 source addresses to go to certain
> outside IPv4 pool of addresses.
>
> 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.
>
> 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.
>

---

From: GangChen <[email-masked]>
Date: Thu, 11 Jul 2013 11:19:29 +0800

> 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