Just a quick thought. Will the dhcpv6 logs help? Sent from mobile device, pardon possible typo.
> On May 7, 2018, at 7:06 AM, "[email protected]" > <[email protected]> wrote: > > Dear Ian, thanks for clarifications. > > Regulator in India mandated to preserve the following details for each flow. > 1. Source IP + Port (private for end subscriber device) > 2. Destination IP + Port (public) > 3. Translated IP + port (public) > 4. Date and time > > There is no brainer and all this is available in NAT44. MAP being stateless, > no such data available from MAP-BR. We are exploring alternate option on BR > to create this data in MAP. > > Pls advise. > > Regds > ramesh > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: 04 May 2018 17:28 > To: Rajiv Asati (rajiva) > Cc: Softwires-wg list; [email protected]; Ramesh R Chandra > Subject: Re: [Softwires] ISP CGN logging inc. Destination ?? > > Hi Rajiv, > > Please see inline. > > Cheers, > Ian > >> On 4. May 2018, at 12:01, Rajiv Asati (rajiva) <[email protected]> wrote: >> >> Ian, >> >> Thanks for sharing the URL. While not explicit, “all metadata” would include >> both source and destination A+P. Is that the right interpretation? > > [if - My understanding is that per-flow logging is necessary to meet the > requirement, but I’m not familiar enough with the legislation to know what > exactly needs to be stored.] > >> >> If an ISP were to use “binding” mode on the BR, then without using net >> flow/IPFIX, How could the compliance be achieved ? > > [if - If there’s address sharing and the requirement is to provide an exact > match to a data retention request (in some countries, a list of e.g. 16 users > is OK), then AFAICS, you have to use IPFIX. > > The implementation problem for this is compounded by the lack of state table > on most BR implementations (e.g. how do you know when a UDP session has > completed without state for that flow?)] > > > "Confidentiality Warning: This message and any attachments are intended only > for the use of the intended recipient(s). > are confidential and may be privileged. If you are not the intended > recipient. you are hereby notified that any > review. re-transmission. conversion to hard copy. copying. circulation or > other use of this message and any attachments is > strictly prohibited. If you are not the intended recipient. please notify the > sender immediately by return email. > and delete this message and any attachments from your system. > > Virus Warning: Although the company has taken reasonable precautions to > ensure no viruses are present in this email. > The company cannot accept responsibility for any loss or damage arising from > the use of this email or attachment." > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
