IETF Logo Mail Archive

Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

"Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> Mon, 03 March 2014 19:16 UTC

Return-Path: <ssenthil@cisco.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4721A0097 for <softwires@ietfa.amsl.com>; Mon, 3 Mar 2014 11:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.047
X-Spam-Level:
X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TswNHwqtDCwg for <softwires@ietfa.amsl.com>; Mon, 3 Mar 2014 11:16:23 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 56CD41A007A for <softwires@ietf.org>; Mon, 3 Mar 2014 11:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10099; q=dns/txt; s=iport; t=1393874180; x=1395083780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hWisla18VnJ9xDoqx1546BJLxWjUP4zwoQLmgGAZm4g=; b=R2SZ8JJ6JKfv2MytEB3N03CezNkWXQes356R0KFVYhQY6z3wtEjxAA+B FViagFzRPx+w0Ox0eeOz9v/mK67osXshoGEnDokEL1dNNv6hj3aRxqj/D 8D8lXvq5bn0XMazZT+QfLJIxKy9q1ivD+F6J3t8tSFGvD6FeNd3K9Pshr U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoEFAPzTFFOtJV2a/2dsb2JhbABagkJEO1e3eYhdgSUWdIIlAQEBBHkQAgEIEQMBAigHIREUCQgCBAENBYdlAxENxUsNhlwXjEOCBREHBoQyBJZPgW2BMosxhUiDLYIq
X-IronPort-AV: E=Sophos; i="4.97,579,1389744000"; d="scan'208,217"; a="307744939"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 03 Mar 2014 19:16:20 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s23JGKu9008400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 19:16:20 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.9]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 13:16:19 -0600
From: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
To: Ian Farrer <ianfarrer@gmx.com>, Wojciech Dec <wdec.ietf@gmail.com>
Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
Thread-Index: AQHPJv6lirE49n9X7Euc7Nkonuc64ZqwPo0AgASjYoCAAFP6gIAAVYgAgAL0cgCAAY3LgIACo5gAgAsQfoCAABoyAIAIXsOA//+yJ4A=
Date: Mon, 03 Mar 2014 19:16:19 +0000
Message-ID: <CF3A3BBE.EC844%ssenthil@cisco.com>
References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <FD878467-904B-4441-95B4-11D4461A612E@employees.org> <CF237FDE.AACEB%ian.farrer@telekom.de> <CAFFjW4jOBfvnqCV4UH8qt0HA5zZ-35f+q5ZepzjnwGX5_Oj9Gg@mail.gmail.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <CAFFjW4iP2KqNJFtJPr5rp0tzRwM5TPjaqiSP5r13JqbX46ao7w@mail.gmail.com> <CD1D4FF6-9509-43B4-AFC4-4F1AF99D0C4D@gmx.com> <CAFFjW4ibkj_xpTuXrbYjxkdxD=+qNzapCGPHJwXsZ-k0ZvGg-g@mail.gmail.com> <CF335888.AE89D%ian.farrer@telekom.de> <CAFFjW4hv5WBiqyw9jM+ZoLMGR5k49pjKXG0epnhrsOGoBBKMYA@mail.gmail.com> <00EEEB51-BA0E-480B-9DAA-F9F3BE3DD16E@gmx.com>
In-Reply-To: <00EEEB51-BA0E-480B-9DAA-F9F3BE3DD16E@gmx.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.82.234.70]
Content-Type: multipart/alternative; boundary="_000_CF3A3BBEEC844ssenthilciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/NohIX1EtBCpEddBGaw4Xc7oxF9Q
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 19:16:27 -0000

Hi Ian,

The NAPT44 in the lwB4 MUST implement ICMP message handling behaviour conforming to the best current practice documented in [RFC5508]
If the lwB4 receives an ICMP message without the ICMP identifier field for errors detected inside the IPv6 tunnel, the node should relay
the ICMP error message to the original source (the lwAFTR).

Does the highlighted part mean "If the lwB4 receives an ICMP error message", if so can you replace it as suggested?
I am not really sure why icmp identifier field is mentioned in there. Other than that I am ok with the text.

Thanks
Senthil

From: Ian Farrer <ianfarrer@gmx.com<mailto:ianfarrer@gmx.com>>
Date: Monday, March 3, 2014 1:54 PM
To: Wojciech Dec <wdec.ietf@gmail.com<mailto:wdec.ietf@gmail.com>>, Senthil Sivakumar <ssenthil@cisco.com<mailto:ssenthil@cisco.com>>
Cc: "ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>" <ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>>, Softwires-wg <softwires@ietf.org<mailto:softwires@ietf.org>>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

Hi Woj / Senthil,

Putting the other discussions to the side for a moment, can we tackle the fragmentation text you proposed as this should be easily resolvable?



Suggested text:

The NAT44 in the lwB4 MUST implement the behavior for ICMP message conforming to the
   best current practice documented in [RFC5508<http://tools.ietf.org/html/rfc5508>].
If a LwB4 receives an ICMP error message without the ICMP
   identifier field for errors that is detected inside a IPv6 tunnel, the
   node should relay the ICMP error message to the original source.
   This behavior SHOULD be implemented conforming to the section 8 of
   [RFC2473]<http://tools.ietf.org/html/rfc2473#section-8>.
 FOr TCP and UDP traffic the NAT44 implemented in the LwB4 SHOULD conform with the behavior
   and best current practice documented in [RFC4787<http://tools.ietf.org/html/rfc4787>], [RFC5508<http://tools.ietf.org/html/rfc5508>], and
   [RFC5382<http://tools.ietf.org/html/rfc5382>].


What about the following wording, tweaked after reading RFC6888 (Common Reqs for CGNs), replacing Section 5.2:
---
For TCP and UDP traffic the NAPT44 implemented in the lwB4 SHOULD conform with the behaviour and best current practices documented in
[RFC4787], [RFC508], and [RFC5382]. If the lwB4 supports DCCP, then the requirements in [RFC5597] SHOULD be implemented.

The NAPT44 in the lwB4 MUST implement ICMP message handling behaviour conforming to the best current practice documented in [RFC5508]
If the lwB4 receives an ICMP message without the ICMP identifier field for errors detected inside the IPv6 tunnel, the node should relay
the ICMP error message to the original source (the lwAFTR).

This behaviour SHOULD be implemented conforming to the section 8 of [RFC2473].
----

@Senthil, as this is a change to the wording previously agreed, could you let me know if you’re OK with the proposed new text?

Cheers,
Ian

v2.23.0 | Report a Bug | By Email