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

From: GangChen <[email-masked]>
Date: Tue, 9 Jul 2013 14:23:52 +0800

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: [email-masked]
Date: Mon, 08 Jul 2013 08:16:36 -0700
Subject: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt
To: [email-masked]

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
[email-masked]
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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 12 Jul 2013 05:06:09 +0000

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:[email-masked]]
> 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,
>

---

From: GangChen <[email-masked]>
Date: Mon, 15 Jul 2013 10:41:50 +0800

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.
1) radius-based solution would be a in-band solution
2) fewer impacts to NAT64 performance because the process is
independent with NAT64 translation

BRs

Gang

2013/7/12, Tirumaleswar Reddy (tireddy) <[email-masked]>:
> 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.
>
>> Subject: [BEHAVE] Fwd: I-D Action:
>> draft-chen-behave-nat64-radius-extension-
>> 00.txt
>>
>> wg,
>>

---

From: [email-masked]
Date: Mon, 15 Jul 2013 17:43:27 +0800

Hi all,

    I have submitted a new draft. The objective is to solve a problem that 

    prevents an external client from accessing an internal server.

    https://datatracker.ietf.org/doc/draft-meng-behave-napgt/

    I expect your comments. Thanks a lot!

Cheers,
Wei

---

From: Dan Wing <[email-masked]>
Date: Tue, 16 Jul 2013 15:30:49 -0700

>     I expect your comments. Thanks a lot! 

Draft-meng-behave-napgt appears to describe something that is very similar to the long-standing "DMZ host" configuration available on almost all residential-class NAT devices.  I don't think we could standardize that behavior, but perhaps that is possible.

Draft-meng-behave-napgt also describes an update to the port assignment behavior described in http://tools.ietf.org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.org/html/rfc4787#section-4.2.1 (UDP).  If I understand Section 4 of draft-meng-behave-napgt properly, it is saying that NATs should not assign ports below 1024 to dynamic connections.  This might be something worth considering for draft-ietf-behave-requirements-update?

-d

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 17 Jul 2013 01:52:34 +0000

I'm not sure this is a good idea. There are still some protocols around that use ports < 1024 and maintaining the source port after translation in this range is important.

________________________________
From: [email-masked] [[email-masked]] on behalf of Dan Wing (dwing)
Sent: Tuesday, July 16, 2013 3:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!

On Jul 15, 2013, at 2:43 AM, [email-masked]<mailto:[email-masked]> wrote:

-d

---

From: [email-masked]
Date: Wed, 17 Jul 2013 11:08:35 +0800

Hi Chair，
  Thanks for comments. 
  Once I communicated with some operators and colleges about current 
situation of 
NATs deployment. They raised an issue that an internal server can not 
share an public
IP address with other internal subscribers. The scenario is similar to 
"DMZ hosts" indeed.
  So this draft describes a method of port assignment. Because a service 
that use private
port may be provided, so port range should not be constant, not only 
<1-1024>, but also 
<1025-2048>, or <x-y>.  And also, the rest ports should not be wasted and 
they could be 
assigned by others.
  With deploying of NATs, it may offset negative effects that bring to the 
people who 
are erecting servers in his/her home.

Cheers,
Wei

[email-masked]  2013-07-17 06:30:49:

> Draft-meng-behave-napgt appears to describe something that is very 
> similar to the long-standing "DMZ host" configuration available on 
> almost all residential-class NAT devices.  I don't think we could 
> standardize that behavior, but perhaps that is possible.
> 
> Draft-meng-behave-napgt also describes an update to the port 
> assignment behavior described in http://tools.ietf.
> org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.
> org/html/rfc4787#section-4.2.1 (UDP).  If I understand Section 4 of 
> draft-meng-behave-napgt properly, it is saying that NATs should not 
> assign ports below 1024 to dynamic connections.  This might be 
> something worth considering for draft-ietf-behave-requirements-update?
> 
> -d
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: [email-masked]
Date: Wed, 17 Jul 2013 11:22:39 +0800

Hi Reinaldo,
  So I suppose <1-1024> might be used as NAT, <1025-65535> might be used 
as 
dynamic NAPT.
  That is what this view says in the draft.

Cheers,
Wei

[email-masked] 2013-07-17 09:52:34:

> I'm not sure this is a good idea. There are still some protocols 
> around that use ports < 1024 and maintaining the source port after 
> translation in this range is important. 
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 17 Jul 2013 04:36:30 +0000

Hi,

I'm not sure what exactly you man by "might be used as NAT".

0-1024 might be used for NAPT in a FCFS basis where port preservation (this is what we are talking about here, right?) is needed.

As a concrete example, many IPsec Servers still expect to see the source port within 0-1024 and preferably a specific source port. If that source port is used by the NAT, and more than one IPsec client is behind it, there are a some choices available.

- Some funky IPSec ALG (implemented in many products)
- Give a port above 1024 and hope for the best
- Deny the connection
- others..

Other ports for the same public IP can be used by any other internal IP address. This is very common in implementations.

thanks,

________________________________
From: [email-masked] [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Tuesday, July 16, 2013 8:22 PM
To: Reinaldo Penno (repenno)
Cc: [email-masked]; [email-masked]; Dan Wing (dwing)
Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!

Hi Reinaldo,
  So I suppose <1-1024> might be used as NAT, <1025-65535> might be used as
dynamic NAPT.
  That is what this view says in the draft.

Cheers,
Wei

---

From: [email-masked]
Date: Wed, 17 Jul 2013 16:08:02 +0800

Hi,
  I got what the example means. 

  1-1024 is just an example, the range could be any valid value.

  "<1-1024> might be used as NAT, <1025-65535> might be used as 
dynamic NAPT", example is as below.

   +----------+     +-----+    +--------+
   + Internet + ----+ NAT +----+ Server +
   +----------+     +-----+    +--------+

   (1) "<1-1024> might be used as NAT" means,
       A server behind a NAT.
   A message, sent by server, its source port is in 1-1024 (or 4500-4501 
or ...).
   The source address will be converted by NAT, the source port remains
   the same.

   (2)<1025-65535> might be used as dynamic NAPT
       Meanwhile, many hosts are behind NAT. They attempt to access to 
    internet. 
       A message, sent by a host, both its source address and port will
    be converted by NAT, and the new port will be in 1025-65535.

It will make IP address assignment more effective.

Cheers,
Wei

[email-masked]  2013-07-17 12:36:30:

> 0-1024 might be used for NAPT in a FCFS basis where port 
> preservation (this is what we are talking about here, right?) is needed. 

> 
> As a concrete example, many IPsec Servers still expect to see the 
> source port within 0-1024 and preferably a specific source port. If 
> that source port is used by the NAT, and more than one IPsec client 
> is behind it, there are a some choices available.
> 
> Other ports for the same public IP can be used by any other internal
> IP address. This is very common in implementations.
> 
> thanks,
> 
> From: [email-masked] [[email-masked]] on behalf of
> [email-masked] [[email-masked]]

as

---

From: Simon Perreault <[email-masked]>
Date: Wed, 17 Jul 2013 10:41:16 +0200

It seems you guys are forgetting about RFC 4787 REQ-3 a):

      a) If the host's source port was in the range 0-1023, it is
         RECOMMENDED the NAT's source port be in the same range.  If the
         host's source port was in the range 1024-65535, it is
         RECOMMENDED that the NAT's source port be in that range.

Does anything more need to be said about this?

Simon

Le 2013-07-17 10:08, [email-masked] a écrit :
>> > Dan Wing (dwing)

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 17 Jul 2013 13:30:24 +0000

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 17, 2013 4:08 AM
To: "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Dan Wing (dwing)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!

Hi,

   (1) "<1-1024> might be used as NAT" means,
       A server behind a NAT.
   A message, sent by server, its source port is in 1-1024 (or 4500-4501 or ...).
   The source address will be converted by NAT, the source port remains
   the same.

[Senthil] Sorry, I didn’t read the draft, but the above logic wont work if there are multiple servers using the same source port.
Also, in some applications (I think rcmd, rshell etc), the source port doesn’t have to be preserved but must be below 1024.

Senthil

Cheers,
Wei

[email-masked]<mailto:[email-masked]>  2013-07-17 12:36:30:

> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of
> [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Dan Wing (dwing)

> [email-masked]<mailto:[email-masked]> 2013-07-17 09:52:34:
>
> > From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of
> > Dan Wing (dwing)
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Thu, 18 Jul 2013 09:19:46 +0800

Hi,
  Please see inline.

Thanks,
Wei

"Senthil Sivakumar (ssenthil)" <[email-masked]>  2013-07-17 21:30:24:

> From: "[email-masked]" <[email-masked]>
> To: "Reinaldo Penno (repenno)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, 
"[email-masked]" <
> [email-masked]>, "Dan Wing (dwing)" <[email-masked]>
> [Senthil] Sorry, I didn’t read the draft, but the above logic wont 
> work if there are multiple servers using the same source port.
> Also, in some applications (I think rcmd, rshell etc), the source 
> port doesn’t have to be preserved but must be below 1024.
> 
> Senthil

[Wei] I'm presenting the proposal so as to solve this problem : assign 
port 
x-y(i.e. 1-1024) to a server(for port preserving function, like NAT), 
assign 
the rest of ports to others(for common NAPT).
  Of course, if there are many servers bebind NAT and whether or not using 

the same source port, NAT has to need more than one public address.
  But in this case ,a server will never occupys all ports of a public 
address, 
just "x-y". 

Wei

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Thu, 18 Jul 2013 14:31:00 +0000

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 17, 2013 9:19 PM
To: Senthil Sivakumar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Dan Wing (dwing)" <[email-masked]<mailto:[email-masked]>>, "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Re: [BEHAVE] NAPGT request for comments, THANKS!

Hi,
  Please see inline.

Thanks,
Wei

"Senthil Sivakumar (ssenthil)" <[email-masked]<mailto:[email-masked]>>  2013-07-17 21:30:24:

> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>, "Dan Wing (dwing)" <[email-masked]<mailto:[email-masked]>>

[Wei] I'm presenting the proposal so as to solve this problem : assign port
x-y(i.e. 1-1024) to a server(for port preserving function, like NAT), assign
the rest of ports to others(for common NAPT).
  Of course, if there are many servers bebind NAT and whether or not using
the same source port, NAT has to need more than one public address.
  But in this case ,a server will never occupys all ports of a public address,
just "x-y".

[Senthil] I don’t really understand what is the use case for this? Can you provide a real life use case that would benefit by this?
What if the server listens on a port > 1024? Why would the server multiple ports? Why cant a simple port forwarding work?

Senthil

Wei

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Jul 2013 17:38:12 +0000

Hi Gang,

Please see inline

> Sent: Monday, July 15, 2013 8:12 AM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Behave WG; [email-masked]
> Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-
> extension-00.txt
> 
> Hi Tiru,
> 

Why is this problem specific to NAT64 ? (it looks like a problem with any other flavor of NAT)

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

> 1) radius-based solution would be a in-band solution

Can you please clarify why you call radius-based solution in-band ?
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.

> independent with NAT64 translation

Even draft-boucadair-pcp-nat-reveal-01 should not impact the NAT64 performance.

===

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.

Cheers,

--Tiru.

---

From: GangChen <[email-masked]>
Date: Fri, 19 Jul 2013 17:50:51 +0800

Hi Tiru,

Thanks for the comments.

> Why is this problem specific to NAT64 ? (it looks like a problem with any

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.

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

> Even draft-boucadair-pcp-nat-reveal-01 should not impact the NAT64

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 19 Jul 2013 13:00:00 +0000

Hi Gang,

Please see inline

> Sent: Friday, July 19, 2013 3:21 PM

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

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

> The document just intends to describe the unique needs.

Ok.

> be get along with same radius systems. Therefore, that is an in-band

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

> This context is limited to radius vs application aware functions.

Ok.

Cheers,

--Tiru.

---

From: [email-masked]
Date: Mon, 29 Jul 2013 21:51:40 +0800

Hi all,
  It's a pitty I got no comment after my presentation due to lack of 
meeting time.
  It is an important issue which small firms/family DIYers/... must face 
to
when NAT has been deployed. They attempt to achieve accessing internal 
server 
from external network environment without an extra public IP address.

  Are you interested in this topic?

  Please see the scenario in slides. 
http://tools.ietf.org/agenda/87/slides/slides-87-behave-4.pdf

Thanks for comments.

Cheers,
Wei

[email-masked]  2013/07/18 22:31:00:

> To: Senthil Sivakumar <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "Dan Wing (dwing)" <[email-masked]>, 
> "Reinaldo Penno (repenno)" <[email-masked]>
"[email-masked]" <
port 
assign 
> [Senthil] I don’t really understand what is the use case for this? 
> Can you provide a real life use case that would benefit by this?
> What if the server listens on a port > 1024? Why would the server 
> multiple ports? Why cant a simple port forwarding work?
> 
> Senthil
> 
> Wei 
> 
> > 
> > 
> >

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 30 Jul 2013 14:36:28 +0000

What kind of a server is this? That requires to listen on contiguous ports? Or is it a series of servers?
Is this a real world use case?

Thanks
Senthil

Date: Monday, July 29, 2013 9:51 AM

Hi all,
  It's a pitty I got no comment after my presentation due to lack of
meeting time.
  It is an important issue which small firms/family DIYers/... must face to
when NAT has been deployed. They attempt to achieve accessing internal server
from external network environment without an extra public IP address.

  Please see the scenario in slides.   http://tools.ietf.org/agenda/87/slides/slides-87-behave-4.pdf

Thanks for comments.

Cheers,
Wei

[email-masked]<mailto:[email-masked]>  2013/07/18 22:31:00:

> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>, "Dan Wing (dwing)" <[email-masked]<mailto:[email-masked]>>,
> "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>