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

Ian Farrer <ianfarrer@gmx.com> Mon, 03 March 2014 18:55 UTC

Return-Path: <ianfarrer@gmx.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 7262D1A0369 for <softwires@ietfa.amsl.com>; Mon, 3 Mar 2014 10:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 TNPafofNlc8O for <softwires@ietfa.amsl.com>; Mon, 3 Mar 2014 10:55:04 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id B2C6D1A036C for <softwires@ietf.org>; Mon, 3 Mar 2014 10:55:00 -0800 (PST)
Received: from dhcp-afd3.meeting.ietf.org ([31.133.175.211]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Las1k-1X4ePh0Axs-00kNvi for <softwires@ietf.org>; Mon, 03 Mar 2014 19:54:57 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_2516E61B-7F57-4A47-BDA1-889A22AE366C"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ian Farrer <ianfarrer@gmx.com>
In-Reply-To: <CAFFjW4hv5WBiqyw9jM+ZoLMGR5k49pjKXG0epnhrsOGoBBKMYA@mail.gmail.com>
Date: Mon, 03 Mar 2014 18:54:55 +0000
Message-Id: <00EEEB51-BA0E-480B-9DAA-F9F3BE3DD16E@gmx.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>
To: Wojciech Dec <wdec.ietf@gmail.com>, ssenthil <ssenthil@cisco.com>
X-Mailer: Apple Mail (2.1874)
X-Provags-ID: V03:K0:L8zIHSowKHG4VIWoief94n1xq9Amk8C4HBpbgqXYOo4IDRBruUo W3wVRwvXPs5IL8SnmauUzmSCIS7YieaBBD4c6JijmO3LRkXJWu3Xk6jVNaTm9HC1wxtDciL 5sV5dUzgB+U/fj6negL9pTSqZhbmTYD2U2UWhLxV3WT126+OzPcHj04GFEN0iB/fPluJMIE mZWRYVq2xQbL0rxLa5eyQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/GUpAhIzEYC89hgPyJiMRqMOfUgI
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 18:55:06 -0000

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]. 
> 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].
>  FOr TCP and UDP traffic the NAT44 implemented in the LwB4 SHOULD conform with the behavior
>    and best current practice documented in [RFC4787], [RFC5508], and
>    [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