Hi, JF, See inline
James > -----Original Message----- > From: sunset4 [mailto:[email protected]] On Behalf Of JF Tremblay > Sent: Monday, May 04, 2015 10:30 PM > To: GangChen > Cc: [email protected] > Subject: Re: [sunset4] WG Adoption call for > draft-chen-sunset4-nat64-port-allocation > > Inline. > > > On May 3, 2015, at 9:36 AM, GangChen <[email protected]> wrote: > > > > Thank you for the comments. I'd seen it's great useful to improve the > > draft quality. > > Please see my reply inline. > > > > 2015-05-02 4:36 GMT+08:00, JF Tremblay > <[email protected]>: > > > >> 2.4.1 "The storage of log information may pose a challenge to > >> operators, since it requires additional resources and data inspection > >> processes to identify users." > >> The data inspection remark here does not make sense. The NAT might > >> correlate source addresses to user information if it has it > >> available, but it won’t inspect. The NAT does not store either. > > > > the issue is a NAT may don't know what source address should be correlated. > > Therefore, the NAT have to store entire information preparing the searching. > > For your information, the NAT should store at least three-months log > > in our networks. > > In my opinion: > - NATs do not / should not store logs. This is done by an external server > (syslog > or other). > - NATs do not correlate source addresses to users, unless it already has that > information available. This can be done offline by a server with much more > ressources. Agree, log processing is out of the scope of NAT. > This could be guidance to put in this document, if not mentioned elsewhere. > (but I thought that was quite obvious) > > >> 2.4.3: Why not cover port block randomization here as well? > > > > Good to know more if you point me a reference of "port block > randomization”. > > There isn’t a reference. I might have coined the term a couple of years back, > not sure. This is basically the act of randomizing the assignments of blocks > instead or in conjunction with port randomization within the block. > This could be a concept defined and discussed in this document. I think you are talking about the port block randomization algorithms similar to those defined in RFC6431. Will add some analysis and reference > > /JF > > > > _______________________________________________ > sunset4 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sunset4 _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
