Hi Jordan, Please see inline below.
Thanks, Ian > On 9. May 2018, at 21:38, Gottlieb, Jordan J <jordan.gottl...@charter.com> > wrote: > > If I understand this correctly it appears that requirement #1 would dictate > the capability must be deployed on the CE. The way I read it you are > attempting to retain the pre-NAPT client address and port. For the > particular use case, is the CPE managed by the service provider? If so, why > not originate the logging from the CPE as it has the necessary visibility and > state maintenance to meet all the requirements? [if – This is a possibility in some networks, but in many countries (most of Europe AFIAK], SP’s must allow customers to attach their own equipment so this can’t be considered a secure device for meeting data retention regulations.] > > There was also a comment in this thread regarding UDP and session completion. > I don’t think this is practical on the BR as support for asymmetrical > routing could result in incomplete session information on a particular BR > (you would have to piece it together) as exit transit BR could be different > from the return transit BR. The only device with a complete view of the flow > is the CE in this case as well. [if – I agree that the collection is complicated if you have multiple BRs, but as stated above, I don’t see the CE being a viable solution for many deployments.] > > Assuming CPE is not an option, MAP-T , and that requirement #1 is not the > privately addressed customer endpoint (laptop, tablet, smartphone, etc..) one > could use netflow pre-BR (IPv6) and some simple program to convert to the > required metadata. Destination address is trivial as it is a fixed set of > bits within the DMR(s). Source address is not hard as long as the conversion > program has an accurate list of active mapping rules. Obviously sampling > rate comes into play but I believe we have the same issue with IPFIX. [if - I’m not sure I follow this proposal. Would the pre-BR device still identify flows, just at a different offset within the header? Would the metadata conversion take place on the same device?] > > Cheers, > > Jordan > > From: Softwires [mailto:softwires-boun...@ietf.org > <mailto:softwires-boun...@ietf.org>] On Behalf Of > mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com> > Sent: Wednesday, May 09, 2018 1:31 AM > To: Rajiv Asati (rajiva); ramesh.r.chan...@ril.com > <mailto:ramesh.r.chan...@ril.com>; yiu_...@comcast.com > <mailto:yiu_...@comcast.com> > Cc: softwires@ietf.org <mailto:softwires@ietf.org>; int-a...@ietf.org > <mailto:int-a...@ietf.org> > Subject: Re: [Softwires] ISP CGN logging inc. Destination ?? > > Hi Rajiv, > > What concerns me with this requirement is that it nullifies one of the > motivations for stateless address sharing: > https://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-05#section-3.1.3 > > <https://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-05#section-3.1.3>(Logging > - No Need for Dynamic Binding Notifications) > > especially, this part: > > Some Service Providers have a requirement to use only existing > logging systems and to avoid introducing new ones (mainly because of > Capital Expenditure (CAPEX) considerations). This requirement is > easily met with stateless solutions. > > Cheers, > Med > > De : Softwires [mailto:softwires-boun...@ietf.org > <mailto:softwires-boun...@ietf.org>] De la part de Rajiv Asati (rajiva) > Envoyé : mardi 8 mai 2018 23:43 > À : ramesh.r.chan...@ril.com <mailto:ramesh.r.chan...@ril.com>; > yiu_...@comcast.com <mailto:yiu_...@comcast.com> > Cc : softwires@ietf.org <mailto:softwires@ietf.org>; int-a...@ietf.org > <mailto:int-a...@ietf.org> > Objet : Re: [Softwires] [EXTERNAL] Re: ISP CGN logging inc. Destination ?? > > Agree with Ramesh. DHCP(v6) helps with logging source IP assignment, but > that’s it. > > The requirement here is about keeping track of not only source IP+port, but > also destination IP+port per connection. DHCP(v6) doesn’t apply here. > > -- > Cheers, > Rajiv > > From: "ramesh.r.chan...@ril.com <mailto:ramesh.r.chan...@ril.com>" > <ramesh.r.chan...@ril.com <mailto:ramesh.r.chan...@ril.com>> > Date: Tuesday, May 8, 2018 at 1:15 AM > To: "yiu_...@comcast.com <mailto:yiu_...@comcast.com>" <yiu_...@comcast.com > <mailto:yiu_...@comcast.com>> > Cc: "ianfar...@gmx.com <mailto:ianfar...@gmx.com>" <ianfar...@gmx.com > <mailto:ianfar...@gmx.com>>, Rajiv Asati <raj...@cisco.com > <mailto:raj...@cisco.com>>, Softwires-wg list <softwires@ietf.org > <mailto:softwires@ietf.org>>, "int-a...@ietf.org <mailto:int-a...@ietf.org>" > <int-a...@ietf.org <mailto:int-a...@ietf.org>> > Subject: RE: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ?? > > Not really. Need IPv4 because desitination IP is on IPv4. <> > > Regds > ramesh chandra > M#: +91 90829 61303 > O#: +91 22 7965 9762 > > -----Original Message----- > From: Lee, Yiu [mailto:yiu_...@comcast.com <mailto:yiu_...@comcast.com>] > Sent: 07 May 2018 16:46 > To: Ramesh R Chandra > Cc: ianfar...@gmx.com <mailto:ianfar...@gmx.com>; raj...@cisco.com > <mailto:raj...@cisco.com>; softwires@ietf.org <mailto:softwires@ietf.org>; > int-a...@ietf.org <mailto:int-a...@ietf.org> > Subject: Re: [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.chan...@ril.com > <mailto:ramesh.r.chan...@ril.com>" <ramesh.r.chan...@ril.com > <mailto:ramesh.r.chan...@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: ianfar...@gmx.com <mailto:ianfar...@gmx.com> [mailto:ianfar...@gmx.com > <mailto:ianfar...@gmx.com>] > Sent: 04 May 2018 17:28 > To: Rajiv Asati (rajiva) > Cc: Softwires-wg list; int-a...@ietf.org <mailto:int-a...@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) <raj...@cisco.com > <mailto:raj...@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 <mailto:Softwires@ietf.org> > https://www.ietf.org/mailman/listinfo/softwires > <https://www.ietf.org/mailman/listinfo/softwires> > "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." > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. _______________________________________________ > Softwires mailing list > Softwires@ietf.org <mailto:Softwires@ietf.org> > https://www.ietf.org/mailman/listinfo/softwires > <https://www.ietf.org/mailman/listinfo/softwires>
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
