Re: [Softwires] ISP CGN logging inc. Destination ??

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:int-area-bounces@ietf.org] De la part de Lee, Yiu
> Envoyé : lundi 7 mai 2018 13:16
> À : Ramesh.R.Chandra@ril.com
> Cc : softwires@ietf.org; int-area@ietf.org; ianfarrer@gmx.com
> 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, "Ramesh.R.Chandra@ril.com"
> <Ramesh.R.Chandra@ril.com> 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: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]
> > Sent: 04 May 2018 17:28
> > To: Rajiv Asati (rajiva)
> > Cc: Softwires-wg list; int-area@ietf.org; 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) <rajiva@cisco.com> 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
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area