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

[Simon Perreault <[e-mail]>]

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

On 07/06/12 09:50, George, Wes wrote:
> 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

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