Re: [apps-discuss] Apps Area Review of draft-ietf-behave-lsn-requirements-05

Simon Perreault <simon.perreault@viagenie.ca> Thu, 15 December 2011 17:57 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0CC11E80A2; Thu, 15 Dec 2011 09:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gz1qJdB6ksM; Thu, 15 Dec 2011 09:57:48 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id AB61111E80AA; Thu, 15 Dec 2011 09:57:48 -0800 (PST)
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9678121F60; Thu, 15 Dec 2011 12:57:16 -0500 (EST)
Message-ID: <4EEA34FC.30008@viagenie.ca>
Date: Thu, 15 Dec 2011 12:57:16 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
References: <4EE79606.30704@cisco.com> <4EE8BF1F.9080901@viagenie.ca> <4EE99C03.6050401@cisco.com>
In-Reply-To: <4EE99C03.6050401@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-behave-lsn-requirements.all@tools.ietf.org, 'IESG' <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Apps Area Review of draft-ietf-behave-lsn-requirements-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2011 17:57:49 -0000

On 2011-12-15 02:04, Eliot Lear wrote:
>> I'm sorry, I don't know how to translate that into text. RFC6269 appears clear
>> to me. Do you have an example of text you would like to see?
>
> Don't end with this, but you can start with this.  Because subscribers do not
> receive unique IP addresses, Carrier Grade NATs introduce substantial limitations
> in communications between subscriber that were not previously there .  In
> particular, it is considerably more involved to establish proxy functionality at
> the subscriber border.  Some applications may require substantial enhancements,
> while some may not function at all in such an environment.  Please see RFC 6269
> for details.

Tweaked a bit, gives this:

      <t>Because subscribers do not receive unique IP addresses, Carrier Grade
        NATs introduce substantial limitations in communications between
        subscribers and with the rest of the Internet. In particular, it is
        considerably more involved to establish proxy functionality at the border
        between internal and external realms.  Some applications may require
        substantial enhancements, while some others may not function at all in
        such an environment.  Please see <xref target="RFC6269"/> for
        details.</t>

>>>   * Req1: Whither SCTP?  At the very least someone should say something about why
>>>     SCTP is NOT on the list.
>>
>> There are BEHAVE RFCs we can cite regarding NAT behaviour for TCP, UDP, and
>> ICMP. There is none for SCTP. If there was one we could debate this. But right
>> now it's just impossible to say "support SCTP" without saying how this is done.
>
> Dave addressed this.  What about DCCP and RFC 5596?  My main point is that you
> explain your logic as you did above.  And...

You're right, there is an RFC specifying NAT behaviour for DCCP: RFC5597.

On the one hand, as a probable future CGN captive, I'm tempted to say "all CGNs 
MUST support RFC5597!"

On the other, I know it would probably be a frivolous requirement that won't get 
implemented.

*sigh*

Then there is also this: draft-ietf-dccp-udpencap-09

Here's a proposal: add a sub-requirement saying something like "If a CGN forwards 
DCCP packets, then it MUST support [RFC5597]."

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