Subject: [BEHAVE] AD review of LSN requirements draft

From: Wesley Eddy <[email-masked]>
Date: Thu, 31 May 2012 00:19:29 -0400

Hi, I've completed an AD review of the LSN requirements draft.

I think it's generally in pretty good shape, but do have some
comments that we should at least talk about before going forward.
This could require a small update.  I also understand from the
mailing list that Simon has a proposed reversal of one of the
previous changes, and I think he's totally correct.  So, we
should get a revision anyways before moving on.

Here are my comments:

(1) it strongly seems like RFC 6264 should be mentioned here;
it would probably work in the 2nd paragraph of the Introduction
about providing IPv6 services alongside IPv4 CGN

(2) it seems like it should be really clear in section 1 that
this document isn't considering multi-subscriber IPv6 NPT or
dual layers of IPv6 NPT as being a CGN, only multi-subscriber
IPv4 NAT and dual layers of IPv4 NAT

(3) Note that the sub-requirements for individual NAT
behavior RFCs are labelled "REQ-1", "REQ-2", etc.
duplicatively with the higher-level REQ-1, REQ-2, etc.

(4) Several of the requirements have "SHOULD" in them,
which makes them more of a recommendation than an
actual requirement (those are MUSTs!); if we want to
retain "SHOULD"s, then we probably need to suggest
why they aren't MUSTs by giving some cogent example
of a case where it would be acceptable not to implement
the feature.  (this applies to the SHOULD NOTs as well)

(5) Should there be a requirement to support use of
the prefix allocated via RFC 6598?

(6) I think it would be good to have an advisory
reference to the issues in:
http://tools.ietf.org/html/draft-donley-nat444-impacts-03
and whether or not following the recommendations in this
document helps to avoid such issues.  The RFC 6269
reference already in the introduction is okay, but it
probably glosses over this topic too quickly.

(7) I suspect that we should be more clear in the abstract
and introduction that this is not an IETF endorsement of
CGN or a real specification for CGN, but rather just a
minimal set of requirements that we believe need to be
followed for implementing CGNs on the Internet; CGNs are
still not something we have consensus on being desirable
for the Internet.

-- 
Wes Eddy
MTI Systems

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 May 2012 08:01:53 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Wesley Eddy
> Sent: Wednesday, May 30, 2012 9:19 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] AD review of LSN requirements draft
> 

The test results of draft-donley-nat444-impacts received comments
by myself and Reinaldo Penno in 2010,
  http://www.ietf.org/mail-archive/web/behave/current/msg09027.html
  http://www.ietf.org/mail-archive/web/behave/current/msg09030.html
and the authors have been unable to provide sufficient detail for
others to duplicate the test results.  

> still not something we have consensus on being desirable

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 31 May 2012 13:39:48 -0400

> about providing IPv6 services alongside IPv4 CGN

Added:
One approach to CGN deployment is described in <xref target="RFC6264"/>.

> IPv4 NAT and dual layers of IPv4 NAT

Added:
Note that the CGN mechanism described in this document only applies to 
IPv4. Any IPv6 address translation is out of scope.

Also tweaked the definition of CGN in the terminology section.

> duplicatively with the higher-level REQ-1, REQ-2, etc.

Already mentioned to me privately and fixed in my copy.

> the feature.  (this applies to the SHOULD NOTs as well)

My intent as editor has always been to include justification for any SHOULD.

e.g.
       Sending an ICMP error may be rate-limited for security reasons,
       which is why requirement B is a SHOULD, not a MUST.

Proposal: I'll make a list of justification-less SHOULDs and submit it 
to the WG so that we can either turn them into MUSTs or add justification.

> the prefix allocated via RFC 6598?

I can't see how any networking equipment could not support it.

> probably glosses over this topic too quickly.

In addition to Dan's response, the draft-donley does not evaluate CGNs 
that have a PCP server, which our draft requires. I think the inclusion 
of PCP would affect the results significantly.

> still not something we have consensus on being desirable

I added this:
"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."

But I believe it would be more appropriate to put such text in an IESG Note.

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