ietf
[Top] [All Lists]

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

2012-07-07 16:22:42
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