Subject: Re: [BEHAVE] thoughts on the draft...http://tools.ietf.org/html/draft-zhang-v6ops-cgn-source-trace-00

From: Dong Zhang <[email-masked]>
Date: Fri, 18 Feb 2011 16:10:53 +0800

Hi Joel,

Thanks for your response.
Please see inlines.

发件人： Joel Jaeggli 
发送时间： 2011-02-18  14:48:06 
收件人： [email-masked]; IPv6 Ops WG 
抄送： David Harrington 
主题： thoughts on the draft...http://tools.ietf.org/html/draft-zhang-v6ops-cgn-source-trace-00 
 
The question "whose using this source/dest/sport/dport tupple is right
now" really means, when I originated the question.

the question is always in the past tense (who was using it at time-t,
even in the case of an onging connection)

we answer this question in the context of webservers all the time.

I think this draft could probably be turned into a reasonable statement
of the problem, but I don't think there's really a major difference
between the two cases.

************************
[Dong] If I understand your comment correctly, I think there is a misunderstanding. 

I agress that when any query action happens, the information of the query should 
already have been produced. Thus, the answer is always in past time. 
But what I am trying to say in the draft is that when source tracing behavior happens, 
the session translation binding is still active on the CGN box. This case is called
relatime tracing.
The other case is non-relatime tracing. Because the log server stores the history 
information, when the tracing action happens, the session binding has been deleted on
CGN box.  
************************

if you were looking for a location for this work I would consider
transport and specifically behave as potentially appropriate location
for such.

************************
[Dong] I know several carriers have proposed the source address tracing requirement 
explicitly. They ask the CGN vendors for tracing solution when they consider deploying 
NAT444, DS-Lite and NAT64. Based on this reason, i think a guidance document may be 
needed. 

Actually, the problem has been pointed out in draft-ietf-v6ops-v6-in-mobile-networks-03.

draft-ietf-v6ops-v6-in-mobile-networks-03 says:

   In addition to the developments cited above, NAT placement is
   important for other reasons.  Access networks generally need to
   produce network and service usage records for billing and accounting.
   This is true for mobile networks as well where "subscriber
   management" features (i.e., QoS, Policy, and Billing and Accounting)
   can be fairly detailed.  Since a NAT introduces a binding between two
   addresses, the bindings themselves become necessary information for
   subscriber management.  For instance, the offered QoS on private IPv4
   address and the (shared) public IPv4 address may need to be
   correlated for accounting purposes.  As another example, the
   Application Servers within the provider network may need to treat
   traffic based on policy provided by the PCRF.  If the IP address seen
   by these Application Servers is not unique, the PCRF needs to be able
   to inspect the NAT binding to disambiguate among the individual MNs.
   And, the subscriber session management information and the service
   usage information also need to be correlated in order to produce
   harmonized records.  Furthermore, there may be legal requirements for
   storing the NAT binding records.  Indeed, these problems disappear
   with the transition to IPv6.  For now, it suffices to state that NAT
   introduces state which needs to be correlated and possibly stored
   with other routine subscriber information.

However, the aim of draft-zhang-v6ops-cgn-source-trace is introducing the deployment 
models of source tracing solution. 

Thank you.

************************

I would also encourage the authors to ponder rfc 2804 when considering
how and under what circumstances the ietf would undertake to standardize
the functionality the problem statement requires...

Transport AD copied to close loop.