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.

> 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.

> 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.

>> 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.

> 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.

> ===
>
> 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

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
>> >
>> >
>