Subject: Re: [sunset4] Last Call: <draft-ietf-behave-lsn-requirements-07.txt> (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice

From: "George, Wes" <[email-masked]>
Date: Fri, 6 Jul 2012 12:50:36 -0400

I have a comment about this document related to some discussions that I've had with a number of ADs and WG chairs around the formation and charter of Sunset4 to determine what is and is not in scope for that WG.

For a while both BEHAVE and Sunset4 had this document in their milestones, which clearly won't work. Therefore the distinction made between work to be done in BEHAVE and SUNSET4 was that BEHAVE was to focus more generically on the concept of NAT and the things necessary to make all flavors of it work, such that BEHAVE outputs would equally apply to NAT444, NAT64, DSLite, etc. By contrast, Sunset4 was supposed to focus more narrowly on IPv4-only items. The BEHAVE chairs were represented in these discussions, and they believed that this document was in keeping with this distinction.
In the document's introduction, for example, that generic nature is implied:
  "It is not an IETF endorsement
   of CGN or a real specification for CGN, but rather just a minimal set
   of requirements that will increase the likelihood of applications
   working across CGNs."

However, this document states in section 2:
  "Note also that the CGN described in this document is IPv4-only.
   IPv6 address translation is not considered."
I see that this is a new change to the -07 version, so I hate to rehash the discussion, but I think that this statement should be clearer.
In reading the document, I don't believe that the intent was to limit it to being a discussion of NAT44[4], but that could be the way that this statement is interpreted. The distinction I might make to clarify is that since the document is talking about behaviors that are necessary to make IPv4 address-sharing work, it's specific to the IPv4 side of what could well be a dual-stack NAT, but it's not limited to simply NAT44[4].

I'm not advocating pulling this document back so that it can go to the "right" working group, because I don't think that'll actually add any value to the document and I'm not a fan of process for process's sake. My concern is really more about content and naming- if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc rather than a more generic CGN requirements doc, it should be named to reflect that. If it's meant to be a generic LSN requirements doc, the authors should make the appropriate changes to keep it generic.

Thanks,

Wes George, at least partially wearing my Sunset4 chair hat

> -----Original Message-----
> From: [email-masked] [mailto:ietf-announce-
> [email-masked]] On Behalf Of The IESG
> Sent: Tuesday, June 26, 2012 12:59 PM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: Last Call: <draft-ietf-behave-lsn-requirements-07.txt> (Common
> requirements for Carrier Grade NATs (CGNs)) to Best Current Practice
>
>
> The IESG has received a request from the Behavior Engineering for
> Hindrance Avoidance WG (behave) to consider the following document:
> - 'Common requirements for Carrier Grade NATs (CGNs)'
>   <draft-ietf-behave-lsn-requirements-07.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2012-07-10. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document defines common requirements for Carrier-Grade NAT
>    (CGN).  It updates RFC 4787.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-
> requirements/ballot/
>
>
> The following IPR Declarations may be related to this I-D:
>
>    http://datatracker.ietf.org/ipr/1648/
>
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Simon Perreault <[email-masked]>
Date: Sat, 07 Jul 2012 14:20:54 -0700

Wes,

Here's my take on this...

CGN as defined in this document does not only include NAT444. It is more 
generic than that: it really means "multi-user NAT". Dave Thaler came up 
with the example use case of the NAT in a wifi hotspot. It's just NAT44, 
but it still fits with the draft's definition of CGN because you have 
multiple users potentially fighting for the same NAT resources. Remember 
that the main raison d'être of this draft is for the operator to be able 
to ensure fairness between NAT users. So in this view I think it is 
clearly behave material since the sunsetting of IPv4 really is 
orthogonal to multi-user NATs.

On the question of IPv6: I don't think we should talk about IPv6 simply 
because IPv6 NAT so far has not seen significant deployment in the 
context of multi-user NAT. And NPTv6 is stateless so there are no 
resources to fight for.

Back to your email, where you wrote:

> if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc rather than a more generic CGN requirements doc, it should be named to reflect that.

How about "Common Requirements for IPv4 Carrier Grade NATs (CGNs)"?

Thanks,
Simon

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "George, Wes" <[email-masked]>
Date: Mon, 9 Jul 2012 11:03:32 -0400

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Saturday, July 07, 2012 5:21 PM
>
> Wes,
>

[WEG] I agree with all of what you've said, but I think I need to make the point that I'm concerned with clearer, because the above doesn't exactly address it. I wasn't saying anything about IPv6 NAT, or even IPv4 sunset. I was saying that the current wording is unclear as to what you mean by "IPv4-only". While the NAT specified by this document itself may only act on IPv4 traffic, as you note above it's not limited to just NAT444 or even an IPv4-only *network*. The recommendations in this doc will work for an IPv4 NAT associated with DSLite just as easily as a more traditional IPv4 transport. This is an important distinction, IMO.

> > if it is truly a IPv4-only NAT (NAT44 or NAT444) requirements doc
> rather than a more generic CGN requirements doc, it should be named to
> reflect that.
>
[WEG] This helps, but only in conjunction with additional clarification about the application - that is, just because the NAT is IPv4-only doesn't mean that the network must also be IPv4-only.

Thanks
Wes George

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Jul 2012 11:08:48 -0400

On 2012-07-09 11:03, George, Wes wrote:
>  While the NAT specified by this
> document itself may only act on IPv4 traffic, as you note above it's
> not limited to just NAT444 or even an IPv4-only *network*. The
> recommendations in this doc will work for an IPv4 NAT associated with
> DSLite just as easily as a more traditional IPv4 transport. This is
> an important distinction, IMO.

Right, I understand now. It's the logical NAT function that is 
IPv4-only, not the global use case. I'll add some text to make this 
clear, and I'll specifically point out the DS-Lite example.

> [WEG] This helps, but only in conjunction with additional
> clarification about the application - that is, just because the NAT
> is IPv4-only doesn't mean that the network must also be IPv4-only.

Understood.

Simon

---

From: Tina TSOU <[email-masked]>
Date: Wed, 11 Jul 2012 02:43:30 +0000

There are few things that in my opinion should be added.

First, the port numbers to be allocated to CPE. Excluding Well known port numbers should be mentioned. Moreover if port numbers are allocated to each CPE, what is the criteria for allocation. As mentioned in the document : “ There should be no limit on the size of the address pool”, does this address pool imply the one that would be allocated to the CPE? According to the requirement of the CPE, the pool should be allocated or a fixed number of addresses in the address pool should be allocated to each CPE? Some amount of clarity in this respect would be helpful.

Moreover, the document advocates the use of Endpoint independent filtering. If AID is used, there would be a delay of 120 seconds for each port reallocation. So should EIF be used only with those applications that can’t function without it, instead of applying it for all.

The need to maintain a record or database of the allocated ports and their lifetime would be helpful. If this is maintained, the ports that are near to expiring their lifetime would be considered first and allocated before and in a order. In such cases there will be less chances of the traffic being dropped due to ports not being available. There should be a definite lifetime defined, before connection is refused due to unavailability of ports. If there is a threshold of say,180 seconds, during which allocated ports database can be scanned and if any ports is recently available, can be allocated. This would lead to efficient use of ports.

Tina

On Jul 9, 2012, at 8:08 AM, "Simon Perreault" <[email-masked]<mailto:[email-masked]>> wrote:

Right, I understand now. It's the logical NAT function that is IPv4-only, not the global use case. I'll add some text to make this clear, and I'll specifically point out the DS-Lite example.

How about "Common Requirements for IPv4 Carrier Grade NATs
(CGNs)"?
[WEG] This helps, but only in conjunction with additional
clarification about the application - that is, just because the NAT
is IPv4-only doesn't mean that the network must also be IPv4-only.

Understood.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
sunset4 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sunset4

---

From: Shin Miyakawa <[email-masked]>
Date: Wed, 11 Jul 2012 16:34:44 +0900 (JST)

Tina,

Thanks for the comment. 

> First, the port numbers to be allocated to CPE. Excluding Well known port numbers should be mentioned. 

I think that even if well know port is allocated as src address, 
there would be no problem. 
The document is aiming at "minimal" set of requirements to make CGN transparent, 
I agree with that this could be helpful 
but I don't think this is a critical condition to make this I-D an RFC, isn't it ?

> Moreover if port numbers are allocated to each CPE, what is the criteria for allocation. 

I think that it's operators' choice :-)

<snip>

> Some amount of clarity in this respect would be helpful.

I also think this kind of information is usuful, but 
this could be discussed in other draft isn't it ?

> Moreover, the document advocates the use of Endpoint independent filtering. If AID is used, there would be a delay of 120 seconds for each port reallocation. So should EIF be used only with those a…

I see... Especially, Simon, how do you think ?

> 
> The need to maintain a record or database of the allocated ports and their lifetime would be helpful. 

For example, if port is statically assigned, there is no need to have 
such record. So, again, I agree with that this is of course a clue to 
operate CGN better in certain environment, but still is not a critical, I think.

So, how about we could create a document with such a hint for CGN operation 
seprately then let this I-D move forward now ? > Tina

Best wishes,

Shin Miyakawa

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Jul 2012 10:01:11 -0400

> port numbers should be mentioned.

As draft editor, I would ask for a justification. I can't add a 
requirement without a justification.

> Moreover if port numbers are allocated
> to each CPE, what is the criteria for allocation.

I don't know, I'm just an editor. What specific text in the draft do you 
think needs to be changed?

> As mentioned in the
> document : “ There should be no limit on the size of the address pool”,
> does this address pool imply the one that would be allocated to the CPE?

No. It refers to the external address pool used by the CGN.

> According to the requirement of the CPE, the pool should be allocated or
> a fixed number of addresses in the address pool should be allocated to
> each CPE?

Sorry, I don't understand this question.

> Moreover, the document advocates the use of Endpoint independent
> filtering. If AID is used, there would be a delay of 120 seconds for
> each port reallocation. So should EIF be used only with those
> applications that can’t function without it, instead of applying it for all.

The draft proposes a more conservative approach: use EIF for everything 
with ADF exceptions. I understand you propose the reverse: ADF for 
everything with EIF exceptions. And I understand that the justification 
would be scalability. However, it seems to me that ADF exceptions can be 
made for heavy use protocols such as HTTP and DNS to address that 
scalability concern. Why isn't that enough?

> their lifetime would be helpful.

How could any NAT work without such a database? I probably misunderstand 
what you're suggesting...

> If this is maintained, the ports that
> are near to expiring their lifetime would be considered first and
> allocated before and in a order. In such cases there will be less
> chances of the traffic being dropped due to ports not being available.

This seems to go against REQ-11 D.

    REQ-11:  When a CGN is unable to create a mapping due to resource
             constraints or administrative restrictions (i.e., quotas):

             D.  and it MUST NOT delete existing mappings in order to
                 "make room" for the new one.  (This only applies to
                 normal CGN behavior, not to manual operator
                 intervention.)

Are you suggesting that this requirement be dropped? If so, it would be 
necessary to demonstrate why the justification for this requirement, 
quoted below, is  invalid.

       Applications generally handle connection establishment failure
       better than established connection failure.  This is why dropping
       the packet initiating the new connection is preferred over
       deleting existing mappings.  See also the rationale in [RFC5508]
       section 6.

> There should be a definite lifetime defined, before connection is
> refused due to unavailability of ports. If there is a threshold of
> say,180 seconds, during which allocated ports database can be scanned
> and if any ports is recently available, can be allocated. This would
> lead to efficient use of ports.

I'm sorry, I don't understand this proposal. Maybe an example would help?

Simon