Hi Yiu, This may help but this is not sufficient if supplying "Destination IP + Port (public)" is required.
Technically the BR may extract and record the destination IPv4 address/port and source IPv6 prefix when doing its stateless decapsulation/translation, but this is not a "native" feature of a BR/lwAFTR. Cheers, Med > -----Message d'origine----- > De : Int-area [mailto:[email protected]] De la part de Lee, Yiu > Envoyé : lundi 7 mai 2018 13:16 > À : [email protected] > Cc : [email protected]; [email protected]; [email protected] > Objet : Re: [Int-area] [EXTERNAL] Re: [Softwires] ISP CGN logging inc. > Destination ?? > > 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 > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
