Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt

Hi Gang,

Please see inline

> -----Original Message-----
> From: GangChen [mailto:phdgang@gmail.com]
> Sent: Friday, July 19, 2013 3:21 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Behave WG; mohamed.boucadair@orange.com
> Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-
> extension-00.txt
> 
> Hi Tiru,
> 
> Thanks for the comments.
> 
> 2013/7/19, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>:
> > Hi Gang,
> >
> > Please see inline
> >
> >> -----Original Message-----
> >> From: GangChen [mailto:phdgang@gmail.com]
> >> Sent: Monday, July 15, 2013 8:12 AM
> >> To: Tirumaleswar Reddy (tireddy)
> >> Cc: Behave WG; mohamed.boucadair@orange.com
> >> Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-
> >> extension-00.txt
> >>
> >> Hi Tiru,
> >>
> >> You are right. Please check the sentence in the draft "It's also
> >>    possible to extend Port Control Protocol (PCP) to support those
> >>    network information queries from external servers. ....."
> >>
> >> The radius-based proposal intended to fit into the environment, where
> >> geo-location system is already deployed based on a radius
> >> database[RFC5580]. Some benefits have been described related to this
> >> context.
> >
> > Why is this problem specific to NAT64 ? (it looks like a problem with any
> > other flavor of NAT)
> 
> The problem is general to all the NAT-based deployments.
> But NAT64 has the uniqueness, because the internal source is a IPv6
> address, which has a global meaning.  The system doesn't have to
> correlate other information to identify user.

Thanks, that clarifies. If required updated the draft to make it more clear.

> 
> > From the draft it looks like for every mapping create, Radius server has to
> > be informed which is unconditional PUSH model and could create a lot of
> > network chatter.
> 
> No. If you take a look at Fig.1 Requested-Binding-Info message would
> convey the conditions. Only the matched mappings should report to the
> Radius server. It's a PULL model.

Now I get it. It would be good if you could provide a full example just like in [RFC5580].

> 
> > In PCP draft-boucadair-pcp-nat-reveal-01 it's a PULL model
> > where only for interesting flows PCP-controlled NAT device is requested to
> > provide the internal IP address.
> 
> I don't  want to make much comparisons because it may be "don't have
> to". Every case has their benefits and suitable cases. RFC6967 lists
> multiple solutions to reveal the source. That gives several
> possibilities for the deployment. As you can see, we are also using
> different approaches to discover NAT64 prefix. I don't see the harm.
> The document just intends to describe the unique needs.

Ok.

> 
> 
> >> 1) radius-based solution would be a in-band solution
> >
> > Can you please clarify why you call radius-based solution in-band ?
> 
> Some geo-location systems receive the information through radius
> messages(as described in RFC5580). The proposed radius message could
> be get along with same radius systems. Therefore, that is an in-band
> solution.

Got it. you may want to say the same point in the draft, which is a good advantage of not requiring any interworking function.

> 
> > The example of X-Forwarded-For header provided in the draft is in-band and
> > any other method like Radius, PCP are out-of-band.
> 
> Yes. it's a different definition.
> 
> >> 2) fewer impacts to NAT64 performance because the process is
> >> independent with NAT64 translation
> > Even draft-boucadair-pcp-nat-reveal-01 should not impact the NAT64
> > performance.
> 
> Yes. We don't intent to say your solution impacts NAT64 performance.
> This context is limited to radius vs application aware functions.

Ok.

> 
> > ===
> >
> > If you could provide more details of an example use case with topology of
> > the client, NAT64, Radius Server and third party entity which will query the
> > Radius server for the IPv6 address and how the learnt IPv6 address will be
> > used for some policy decision, it will help understanding of reviewers.
> 
> Good suggestions. I will add the additional descriptions

Cheers,

--Tiru.

> 
> Best Regards
> 
> Gang
> 
> 
> > Cheers,
> >
> > --Tiru.
> >
> >>
> >> BRs
> >>
> >> Gang
> >>
> >> 2013/7/12, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>:
> >> > Hi Gang,
> >> >
> >> > The problems mentioned in the draft can also be solved using PCP QUERY
> >> > opcode introduced in
> >> > http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01
> >> >
> >> > --Tiru.
> >> >
> >> >> -----Original Message-----
> >> >> From: GangChen [mailto:phdgang@gmail.com]
> >> >> Sent: Tuesday, July 09, 2013 11:54 AM
> >> >> To: Behave WG
> >> >> Subject: [BEHAVE] Fwd: I-D Action:
> >> >> draft-chen-behave-nat64-radius-extension-
> >> >> 00.txt
> >> >>
> >> >> wg,
> >> >>
> >> >> We just uploaded the draft-chen-behave-nat64-radius-extension-00
> >> >> The draft proposes new Radius attributes to convey IPv6 source
> >> >> addresses when a NAT64 is deployed.
> >> >>
> >> >> Your comments/reviews are appreciated.
> >> >>
> >> >> Best Regards
> >> >>
> >> >> Gang
> >> >>
> >> >> ---------- Forwarded message ----------
> >> >> From: internet-drafts@ietf.org
> >> >> Date: Mon, 08 Jul 2013 08:16:36 -0700
> >> >> Subject: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt
> >> >> To: i-d-announce@ietf.org
> >> >>
> >> >>
> >> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> >> directories.
> >> >>
> >> >>
> >> >> 	Title           : Radius Attributes for Stateful NAT64
> >> >> 	Author(s)       : Gang Chen
> >> >>                           David Binet
> >> >> 	Filename        : draft-chen-behave-nat64-radius-extension-00.txt
> >> >> 	Pages           : 10
> >> >> 	Date            : 2013-07-08
> >> >>
> >> >> Abstract:
> >> >>    This document proposes new radius attributes for stateful NAT64.
> >> >> The
> >> >>    extensions are used to provide geo-location services with an exact
> >> >>    IPv6 soruce address.  The message flow to deliver the NAT64 binding
> >> >>    information between radius clients and servers is also described.
> >> >>    Therefore, accurate location could be traced out depending on the
> >> >>    radius method.
> >> >>
> >> >>
> >> >> The IETF datatracker status page for this draft is:
> >> >> https://datatracker.ietf.org/doc/draft-chen-behave-nat64-radius-
> extension
> >> >>
> >> >> There's also a htmlized version available at:
> >> >> http://tools.ietf.org/html/draft-chen-behave-nat64-radius-extension-00
> >> >>
> >> >>
> >> >> Internet-Drafts are also available by anonymous FTP at:
> >> >> ftp://ftp.ietf.org/internet-drafts/
> >> >>
> >> >> _______________________________________________
> >> >> I-D-Announce mailing list
> >> >> I-D-Announce@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/i-d-announce
> >> >> Internet-Draft directories: http://www.ietf.org/shadow.html
> >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >> >
> >> >
> >