IETF Logo Mail Archive

Re: [v6ops] State of play

"Fred Baker (fred)" <fred@cisco.com> Tue, 02 February 2016 15:33 UTC

Return-Path: <fred@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7103C1B2C63; Tue, 2 Feb 2016 07:33:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.502
X-Spam-Level:
X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 JyFjnXj_9ZBk; Tue, 2 Feb 2016 07:33:40 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F311D1B2C62; Tue, 2 Feb 2016 07:33:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2746; q=dns/txt; s=iport; t=1454427220; x=1455636820; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ojPjOxx85GbR8NdHGqoEfB9pv4Fp9f3rf1E2xG9AMuY=; b=KG2dr3NUFHxcqlpmb5BFqUzL0NjZYEjpwCcVHo+KCKdrLTziTUFa6e6M LauJHoBgSsz/TBrnSY4HVBQXgRKmbVG6vr5Sv++EL1xlwV+4MpTaSDEqZ 2T28kWn2ZEAktiZOqSvdcuWs1546Zho7oiIvNH7PGGro3ojkxs6yPpYdW g=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DDAgBzy7BW/4oNJK1egzqBPwaIU7FsDoFkhg0CgUU4FAEBAQEBAQGBCoRCAQEEeRACAQgYLjIlAgQOBQ6IDb5oAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiHfIJKh12BDwWWcQGCeYFjiG6BW4dohS6OPgEeAUODZGqIb3wBAQE
X-IronPort-AV: E=Sophos;i="5.22,385,1449532800"; d="asc'?scan'208";a="72204171"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2016 15:33:39 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u12FXdao025625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 15:33:39 GMT
Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 09:33:38 -0600
Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Tue, 2 Feb 2016 09:33:38 -0600
From: "Fred Baker (fred)" <fred@cisco.com>
To: Mark Andrews <marka@isc.org>
Thread-Topic: [v6ops] State of play
Thread-Index: AQHRXc8WWKRnV1axq0Cue0ZfkN2Y9w==
Date: Tue, 02 Feb 2016 15:33:38 +0000
Message-ID: <F0944BE4-7A56-4E1E-A27D-680339DC4F02@cisco.com>
References: <201602011400.u11E0Hsd009385@irp-lnx1.cisco.com> <20160201231151.25706414D77A@rock.dv.isc.org>
In-Reply-To: <20160201231151.25706414D77A@rock.dv.isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3112)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.51.158]
Content-Type: multipart/signed; boundary="Apple-Mail=_7EC40467-66AA-40E0-82A3-F4EBF66B4D46"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/Xz4qodQ1zwBxKGR69PD73WQrUiE>
Cc: v6ops list <v6ops@ietf.org>, IPv6 IPv6 List <ipv6@ietf.org>
Subject: Re: [v6ops] State of play
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2016 15:33:41 -0000

On Feb 1, 2016, at 3:11 PM, Mark Andrews <marka@isc.org> wrote:
> draft-andrews-tcp-and-ipv6-use-minmtu-04 has an open question directed
> at the v6man and v6ops chairs - should this be a v6man or v6ops?  It
> needs to be fixed and I don't care in which forum it gets done but it
> needs to be done.

OK, I have now actually read the draft, rather than looking through it for what you described as an open question to the chairs embedded in it.

I suspect you might actually be looking at intarea.

In any event, I disagree with the proposal in the draft, which is that TCP should look at whether "use min MTU" is set. Yes, if it is set, that should be observed; I'm not sure why an implementation would offer the flag without considering it. However, if I understand the question, the key point is that the Maximum Segment Size offered in the TCP MSS should be a size that can be sent on the interface in question using the IP variant selected, and any options or extension headers that need to be present, not whether a given flag is set in a not-actually-standard API. If folks are offering an MSS value that can't be supported, they have an implementation bug, regardless of whether they are checking for the flag.

Can you describe the implementation? Is this Apple, Microsoft, Linux, FreeBSD, Android, something else? Give us a test for reproducing the fault?

v2.23.0 | Report a Bug | By Email