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

[Gottlieb, Jordan J]

Hi Ian,

Agree and understand why CE is not always managed by the provider.  I suggested 
this as I have heard that there is a provider out there that was using MAP-T 
for public WiFi and who had full management access to the CE.  Without managing 
the CE there is no differentiate device (other than attempting to fingerprint 
which is not likely to result with the desired source IP/port)  behind a NAPT 
device without some additional layer on a per-client-device basis.

Quick answers to your questions:
Would the pre-BR device still identify flows, just at a different offset within 
the header?
Yes pre-BR device(s) Netflow data will have applicable src/dst port information 
and src/dst IPv4 information embedded within the IPv6 addresses.  You are just 
using plain old IPv6 Netflow data and extracting the IPv4 addresses that MAP-T 
bit-offsets within the IPv6 address.

Would the metadata conversion take place on the same device?
This should occur as augment to the SPs existing Netflow collection 
infrastructure.  I see no reason to add these use cases to generic SP routing 
infrastructure.

I would like to clarify a couple of items regarding my Netflow suggestion.  
First, I am suggesting Netflow as it is typically already in use in most 
service provider networks and could be leveraged without significant 
investment.  Netflow records are processed off the device as the provider is 
probably already doing this with their existing Netflow collector.

Another approach would be to take the Netflow records north of the BR in pure 
IPv4 form.  There is no conversion required here to obtain the source IPv4/port 
and destination IPv4/port.  Tying it to the subscriber requires is a little 
more work using the mapping rules to derive the originating subscriber by their 
IPv6 prefix allocations.  The drawback to this approach is that you could 
possibly miss some peer-to-peer traffic in the case where the BR is hairpinning 
all traffic (no FMRs).  Benefit to this approach is that it supports a MAP-E 
implementation where the pre-BR does not.

Both approaches will get you all the source/destination address and port 
metadata as well as the IPv6 unique identifier for the subscriber.  What you 
don’t get is any visibility to the addressing/port utilization for each 
subscriber device residing behind their gateway.

A while back I hacked (not the prettiest Python) together some tools that I 
built in Python3 that can do all the described bit manipulations 
(https://github.com/ejordangottlieb/pyswmap).  I have examples that demonstrate 
some of what I have described for extracting and doing some of the MAP 
calculations.

Thanks,

Jordan

From: ianfar...@gmx.com [mailto:ianfar...@gmx.com]
Sent: Friday, May 11, 2018 2:28 AM
To: Gottlieb, Jordan J
Cc: mohamed.boucad...@orange.com; Rajiv Asati (rajiva); 
ramesh.r.chan...@ril.com; yiu_...@comcast.com; softwires@ietf.org; 
int-a...@ietf.org
Subject: Re: [Softwires] ISP CGN logging inc. Destination ??

Hi Jordan,

Please see inline below.

Thanks,
Ian


On 9. May 2018, at 21:38, Gottlieb, Jordan J 
mailto: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, jus

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

[ianfarrer]

Hi Jordan,

Please see inline below.

Thanks,
Ian

> On 9. May 2018, at 21:38, Gottlieb, Jordan J  
> 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>" 
> mailto:ramesh.r.chan...@ril.com>>
> Date: Tuesday, May 8, 2018 at 1:15 AM
> To: "yiu_...@comcast.com <mailto:yiu_...@comcast.com>"  <mailto:yiu_...@comcast.com>>
> Cc: "ianfar...@gmx.com <mailto:ianfar...@gmx.com>"  <mailto:ianfar...@gmx.com>>, Rajiv Asati  <mailto:raj...@cisco.com>>, Softwires-wg list  <mailto:softwires@ietf.org>>, "int-a...@ietf.org <mailto:int-a...@ietf.org&g

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

[Gottlieb, Jordan J]

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?

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.

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.

Cheers,

Jordan

From: Softwires [mailto:softwires-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Wednesday, May 09, 2018 1:31 AM
To: Rajiv Asati (rajiva); ramesh.r.chan...@ril.com; yiu_...@comcast.com
Cc: softwires@ietf.org; 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
 (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] De la part de Rajiv Asati 
(rajiva)
Envoyé : mardi 8 mai 2018 23:43
À : ramesh.r.chan...@ril.com; yiu_...@comcast.com
Cc : softwires@ietf.org; 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>" 
mailto:ramesh.r.chan...@ril.com>>
Date: Tuesday, May 8, 2018 at 1:15 AM
To: "yiu_...@comcast.com<mailto:yiu_...@comcast.com>" 
mailto:yiu_...@comcast.com>>
Cc: "ianfar...@gmx.com<mailto:ianfar...@gmx.com>" 
mailto:ianfar...@gmx.com>>, Rajiv Asati 
mailto:raj...@cisco.com>>, Softwires-wg list 
mailto:softwires@ietf.org>>, 
"int-a...@ietf.org<mailto: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]
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>" 
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]
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

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

[Rajiv Asati (rajiva)]

Hi Med,

I share the same concern. While such a requirement may be deemed reasonable, it 
does not warrant nullifying the very advantage stateless 4o6 techniques such as 
MAP bring to bear.

If such a requirement carries over to native IPv6 communication (involving no 
address translation), then it would warrant a solution such as IPFIX anyway, in 
which case, it would also implicitly solve for the stateless 4o6 techniques.

--
Cheers,
Rajiv

From: "mohamed.boucad...@orange.com" 
Date: Wednesday, May 9, 2018 at 3:30 AM
To: Rajiv Asati , "ramesh.r.chan...@ril.com" 
, "yiu_...@comcast.com" 
Cc: Softwires-wg list , "int-a...@ietf.org" 

Subject: RE: [Softwires] Re: 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
 (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] De la part de Rajiv Asati 
(rajiva)
Envoyé : mardi 8 mai 2018 23:43
À : ramesh.r.chan...@ril.com; yiu_...@comcast.com
Cc : softwires@ietf.org; 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>" 
mailto:ramesh.r.chan...@ril.com>>
Date: Tuesday, May 8, 2018 at 1:15 AM
To: "yiu_...@comcast.com<mailto:yiu_...@comcast.com>" 
mailto:yiu_...@comcast.com>>
Cc: "ianfar...@gmx.com<mailto:ianfar...@gmx.com>" 
mailto:ianfar...@gmx.com>>, Rajiv Asati 
mailto:raj...@cisco.com>>, Softwires-wg list 
mailto:softwires@ietf.org>>, 
"int-a...@ietf.org<mailto: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]
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>" 
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]
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) 
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 witho

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

[Rajiv Asati (rajiva)]

For native ipv4 communication (or ipv6 communication for that matter), 
netflow/IPFIX are the in-band means to help log the IPv4-tuple (or IPv6-tuple) 
information.

Sure, that can help.

--
Cheers,
Rajiv

From: "ramesh.r.chan...@ril.com" 
Date: Wednesday, May 9, 2018 at 3:25 AM
To: "yiu_...@comcast.com" , Rajiv Asati 
Cc: "ianfar...@gmx.com" , Softwires-wg list 
, "int-a...@ietf.org" 
Subject: RE: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ??

Hi Lee,  good thought. If we enable 5 tuple on BR for IPv4, required DA+P shall 
meet DA+P requirement. Using SA+P from 5-tuple should help to correlate with 
user IP based on DHCP assignment.

Key here is on BR to do 5-tuple after de-encapsulation of IPv6. Rajiv, pls 
check if we can do this on ASR9k as BNG.


Regds
Ramesh

From: Lee, Yiu [mailto:yiu_...@comcast.com]
Sent: 09 May 2018 08:35
To: Rajiv Asati (rajiva); Ramesh R Chandra
Cc: ianfar...@gmx.com; softwires@ietf.org; int-a...@ietf.org
Subject: Re: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ??

Let’s me be precise. This regulation must exist today. So there must exist a 
way to log the five-IPv4-tuple. If Ramesh combines the dhcpv6 logs with the 
current five-IPv4-tuple logs, will this be enough?

From: "Rajiv Asati (rajiva)" mailto:raj...@cisco.com>>
Date: Tuesday, May 8, 2018 at 5:42 PM
To: "ramesh.r.chan...@ril.com<mailto:ramesh.r.chan...@ril.com>" 
mailto:ramesh.r.chan...@ril.com>>, "Lee, Yiu" 
mailto:yiu_...@cable.comcast.com>>
Cc: "ianfar...@gmx.com<mailto:ianfar...@gmx.com>" 
mailto:ianfar...@gmx.com>>, 
"softwires@ietf.org<mailto:softwires@ietf.org>" 
mailto:softwires@ietf.org>>, 
"int-a...@ietf.org<mailto:int-a...@ietf.org>" 
mailto:int-a...@ietf.org>>
Subject: Re: [EXTERNAL] Re: [Softwires] 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>" 
mailto:ramesh.r.chan...@ril.com>>
Date: Tuesday, May 8, 2018 at 1:15 AM
To: "yiu_...@comcast.com<mailto:yiu_...@comcast.com>" 
mailto:yiu_...@comcast.com>>
Cc: "ianfar...@gmx.com<mailto:ianfar...@gmx.com>" 
mailto:ianfar...@gmx.com>>, Rajiv Asati 
mailto:raj...@cisco.com>>, Softwires-wg list 
mailto:softwires@ietf.org>>, 
"int-a...@ietf.org<mailto: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]
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>" 
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]
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) 
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 ?
[

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

[mohamed.boucadair]

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
 (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] De la part de Rajiv Asati 
(rajiva)
Envoyé : mardi 8 mai 2018 23:43
À : ramesh.r.chan...@ril.com; yiu_...@comcast.com
Cc : softwires@ietf.org; 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>" 
mailto:ramesh.r.chan...@ril.com>>
Date: Tuesday, May 8, 2018 at 1:15 AM
To: "yiu_...@comcast.com<mailto:yiu_...@comcast.com>" 
mailto:yiu_...@comcast.com>>
Cc: "ianfar...@gmx.com<mailto:ianfar...@gmx.com>" 
mailto:ianfar...@gmx.com>>, Rajiv Asati 
mailto:raj...@cisco.com>>, Softwires-wg list 
mailto:softwires@ietf.org>>, 
"int-a...@ietf.org<mailto: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]
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>" 
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]
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) 
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 arisi

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

[Rajiv Asati (rajiva)]

Thanks, Med. This makes it very explicit.

--
Cheers,
Rajiv

From: "mohamed.boucad...@orange.com" 
Date: Monday, May 7, 2018 at 1:30 AM
To: Rajiv Asati , Softwires-wg list , 
"int-a...@ietf.org" 
Cc: "ramesh.r.chan...@ril.com" 
Subject: RE: ISP CGN logging inc. Destination ??

Hi Rajiv,

Please check RFC6888 which says the following:

   REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
  required to do so for administrative reasons.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Rajiv Asati 
(rajiva)
Envoyé : jeudi 3 mai 2018 23:50
À : Softwires-wg list; int-a...@ietf.org
Cc : ramesh.r.chan...@ril.com
Objet : [Softwires] ISP CGN logging inc. Destination ??

Is there an RFC (besides 6269) that encourages / discourages CGN logging of 
destination IP+Port if source IP+port is already logged?

RFC6269 does mention the below, as compared to the server side logging of 
source IP+port -

// logging the destination address on the NAT is inferior
   to logging the source port at the server.
https://tools.ietf.org/html/rfc6269
//

(BTW, having both source+destination in the NAT log implicitly means no bulk 
allocation of source ports possible)

Separately, this prohibits using stateless NAT based solutions such as MAP or 
using deterministic NAT, since there is no logging in such solutions. If such a 
guideline was also mandated for native IPv6, then it would pose an interesting 
deployment issue.

--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

PS: Few may be aware of Govt. of India’s mandate* to log both source and 
destination IP+port pair.
Click on “Parameter to be stored in SYS Log of Network Address Translation 
(NAT) for Internet Access” on this page - 
https://www.corestack.io/blog/the-log-mandate-enabling-indian-isps-to-adhere-to-dot-compliance-rules/

PS:
https://tools.ietf.org/html/rfc6302
https://tools.ietf.org/html/rfc7422


Session and service continuity
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[mohamed.boucadair]

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-boun...@ietf.org] De la part de Lee, Yiu
> Envoyé : lundi 7 mai 2018 13:16
> À : ramesh.r.chan...@ril.com
> Cc : softwires@ietf.org; int-a...@ietf.org; ianfar...@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.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]
> > Sent: 04 May 2018 17:28
> > To: Rajiv Asati (rajiva)
> > Cc: Softwires-wg list; 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)  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-a...@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[mohamed.boucadair]

Dear Ramesh,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Softwires [mailto:softwires-boun...@ietf.org] De la part de
> ramesh.r.chan...@ril.com
> Envoyé : vendredi 4 mai 2018 17:26
> À : ianfar...@gmx.com; raj...@cisco.com
> Cc : softwires@ietf.org; int-a...@ietf.org
> Objet : Re: [Softwires] ISP CGN logging inc. Destination ??
> 
> 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)

[Med] Please note that this one may be overlapping among multiple subscribers 
if DS-Lite is used. 

> 2.Destination IP + Port (public)

[Med] Does the regulator require to preserve "Destination IP + Port" even if a 
public IP address is assigned to a subscriber?

> 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]
> Sent: 04 May 2018 17:28
> To: Rajiv Asati (rajiva)
> Cc: Softwires-wg list; 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)  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
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[Ramesh.R.Chandra]

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] 
Sent: 04 May 2018 17:28
To: Rajiv Asati (rajiva)
Cc: Softwires-wg list; 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)  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

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

[mohamed.boucadair]

Hi Rajiv,

Please check RFC6888 which says the following:

   REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
  required to do so for administrative reasons.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Rajiv Asati 
(rajiva)
Envoyé : jeudi 3 mai 2018 23:50
À : Softwires-wg list; int-a...@ietf.org
Cc : ramesh.r.chan...@ril.com
Objet : [Softwires] ISP CGN logging inc. Destination ??

Is there an RFC (besides 6269) that encourages / discourages CGN logging of 
destination IP+Port if source IP+port is already logged?

RFC6269 does mention the below, as compared to the server side logging of 
source IP+port -

// logging the destination address on the NAT is inferior
   to logging the source port at the server.
https://tools.ietf.org/html/rfc6269
//

(BTW, having both source+destination in the NAT log implicitly means no bulk 
allocation of source ports possible)

Separately, this prohibits using stateless NAT based solutions such as MAP or 
using deterministic NAT, since there is no logging in such solutions. If such a 
guideline was also mandated for native IPv6, then it would pose an interesting 
deployment issue.

--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

PS: Few may be aware of Govt. of India’s mandate* to log both source and 
destination IP+port pair.
Click on “Parameter to be stored in SYS Log of Network Address Translation 
(NAT) for Internet Access” on this page - 
https://www.corestack.io/blog/the-log-mandate-enabling-indian-isps-to-adhere-to-dot-compliance-rules/

PS:
https://tools.ietf.org/html/rfc6302
https://tools.ietf.org/html/rfc7422


Session and service continuity
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[ianfarrer]

Hi Rajiv,

Please see inline.

Cheers,
Ian

> On 4. May 2018, at 12:01, Rajiv Asati (rajiva)  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?)]

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[Rajiv Asati (rajiva)]

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 an ISP were to use “binding” mode on the BR, then without using net 
flow/IPFIX, How could the compliance be achieved ?

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services


On May 4, 2018, at 4:16 AM, "ianfar...@gmx.com" 
mailto:ianfar...@gmx.com>> wrote:

Hi,

As another data point on this topic, the storing of A+P data is also mandated 
in Hungary. From the Hungary paragraph of the 2016 EU report into 
implementation of the Data Retention Directive 
(http://fra.europa.eu/en/theme/information-society-privacy-and-data-protection/data-retention):

"The new law obliges electronic and IT service providers that allow encrypted 
communication through their services to store all metadata related to such 
communications for one year. It thus widens the scope of data retention."

Translated: A+P retention.

Cheers,
Ian




PS: Few may be aware of Govt. of India’s mandate* to log both source and 
destination IP+port pair.
Click on “Parameter to be stored in SYS Log of Network Address Translation 
(NAT) for Internet Access” on this page - 
https://www.corestack.io/blog/the-log-mandate-enabling-indian-isps-to-adhere-to-dot-compliance-rules/

PS:
https://tools.ietf.org/html/rfc6302
https://tools.ietf.org/html/rfc7422


Session and service continuity
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[ianfarrer]

Hi,

As another data point on this topic, the storing of A+P data is also mandated 
in Hungary. From the Hungary paragraph of the 2016 EU report into 
implementation of the Data Retention Directive 
(http://fra.europa.eu/en/theme/information-society-privacy-and-data-protection/data-retention):

"The new law obliges electronic and IT service providers that allow encrypted 
communication through their services to store all metadata related to such 
communications for one year. It thus widens the scope of data retention."

Translated: A+P retention.

Cheers,
Ian


> 

> PS: Few may be aware of Govt. of India’s mandate* to log both source and 
> destination IP+port pair.
> Click on “Parameter to be stored in SYS Log of Network Address Translation 
> (NAT) for Internet Access” on this page - 
> https://www.corestack.io/blog/the-log-mandate-enabling-indian-isps-to-adhere-to-dot-compliance-rules/
>  
> 
>  
> PS: 
> https://tools.ietf.org/html/rfc6302 
> https://tools.ietf.org/html/rfc7422 
>  
>  
> Session and service continuity
> ___
> Softwires mailing list
> Softwires@ietf.org 
> https://www.ietf.org/mailman/listinfo/softwires 
> 
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires