IETF Logo Mail Archive

Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS)

Dan Wing <danwing@gmail.com> Tue, 16 July 2019 16:25 UTC

Return-Path: <danwing@gmail.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E914E1208B4; Tue, 16 Jul 2019 09:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 23iRkvyYCfeB; Tue, 16 Jul 2019 09:25:12 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14171208B2; Tue, 16 Jul 2019 09:25:04 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id c73so9346217pfb.13; Tue, 16 Jul 2019 09:25:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2D929abQO/y2GSuUYwc+tjtJb/eq4RenPL6tkw4KKU8=; b=CPJwlJqipydWwotbdFwOg7pBk0o4vuCZwIpXLgnkxUThB3CgJYRqeby6zG7u2ztT0F 91aTyupydbDc5XxI0vtZ/4jCY/0VyuY8YCMhT3kpPKNn0gPsMGvfo1dm7Jht3pof4nQC VBdI21PVxbbzBSO7pei6+DkDdpjfBMHM6BLD0dp79hj10j9X4qcPFWwpJjA6cEKnh67E oNSygvZZTQgf4JH6SS1+AUgUGPXToeMV2ik5ffcj7h1mUwOoNrQf8Gaz6kY2hoaD1qXO WJAHjqw2C/9SvTZA0J5Xf1RvI7MAJr6wsr3RE0o2coJqgF9oXwDKcq9Iw66BvWC7W11X LZFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2D929abQO/y2GSuUYwc+tjtJb/eq4RenPL6tkw4KKU8=; b=MPJ1oOOjFqBlq9fJXd3T+dpTdXpzmuEN3vvLN+Kf9yX8S5+vDHbXWqic1hsUY8ayh9 sJhKq2urnL435y5NHsooks3ZQ9DW0UdC/DkTiow9xklA7bAHv2Pl593e7ug2dpAShVlO xRtRbhVkGUNDGjr6PIYGmVFdBQjUKCR5bXD1dgY+Ro6X/Wrvg7tWtjNXcTlYQVHLQQn0 8l1loI5tetp42PUorQ3pIeIx2YZSZnBDfMh87kk1YMixXeYY+j7IZSuFBFUVBzZsUKmW Fzmwwt41OD7DuU60xj+enXUZuM1P71NHC8GOKJbU6JsRy6tMBF2EdX/qVawBboNkWzFk xx5Q==
X-Gm-Message-State: APjAAAVPVt6MOjSA3cnW0ifCLC6TQfumz+gLuCXX5AKjvR6vK8aUQPUI ioYAYoalqyGfj2x2wN6wcnE=
X-Google-Smtp-Source: APXvYqz1PmiHd8GK/2QMNDXRcvVtY1GG9jo19wTKHWymWTTvBaG/MBQkh7wrOpiHdN3taBfjnh5H1Q==
X-Received: by 2002:a17:90a:23ce:: with SMTP id g72mr6606114pje.77.1563294304355; Tue, 16 Jul 2019 09:25:04 -0700 (PDT)
Received: from sjcldanwi.lan ([75.111.84.113]) by smtp.gmail.com with ESMTPSA id 135sm20505839pfb.137.2019.07.16.09.25.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 09:25:03 -0700 (PDT)
From: Dan Wing <danwing@gmail.com>
Message-Id: <C42CCB95-F8D0-4124-8199-2B4A4A5B7613@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_04756B26-C0D0-406E-A2A6-0C7A18F4E31F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 16 Jul 2019 09:25:01 -0700
In-Reply-To: <FBC4199B-0D0A-4969-A2BD-60ACF5272FDE@cisco.com>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "gonzalo.camarillo@ericsson.com" <gonzalo.camarillo@ericsson.com>, "tasveren@rbbn.com" <tasveren@rbbn.com>, "tram@ietf.org" <tram@ietf.org>
To: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>, "draft-ietf-tram-stun-pmtud@ietf.org" <draft-ietf-tram-stun-pmtud@ietf.org>
References: <153793486460.13063.13186763367840598004.idtracker@ietfa.amsl.com> <BA3369C6-2D91-4681-BC70-7EE96BA3267C@cisco.com> <SN6PR11MB28009674FCC5D41F1FA0E1DBC8F60@SN6PR11MB2800.namprd11.prod.outlook.com> <FBC4199B-0D0A-4969-A2BD-60ACF5272FDE@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/0bvYI0KZCOHHY5aPcWvAQq-nDw0>
Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 16:25:15 -0000

On Jul 15, 2019, at 7:09 AM, Felipe Garrido (fegarrid) <fegarrid@cisco.com> wrote:
> 
> Hi Suresh, 
>  
> Does the following language satisfy your Discuss? Similar references to IPv6 packets would be added to the other sections.
>  
> Thanks,
> -Felipe
>  
> 4.1.  Simple Probing Mechanism
>  
>    The Simple Probing mechanism is implemented by sending a Probe
>    Request with a PADDING [RFC5780] attribute over UDP with the DF bit
>    set in the IP header for IPv4 packets and IPv6 packets without
>    the Fragment Header included.  A router on the path to the server can
>   reject this request with an ICMP message or drop it.

The router could also forward the 'request' (actually, it's just an IP packet as far as the router is concerned, it isn't a "request"), so three things can happen to that packet.


Separately, we all know some routers are configured to strip DF bits (that is, set to zro), and some routers are configured to fragment even if DF=1.  Is there implementation guidance we can give to assist detecting such behavior and learning the real underlying MTU, or should we ignore that routers do this and would interfere with the MTU learned by STUN-PMTUD?

-d


>  
> 4.2.2.  Receiving an ICMP Packet
>  
>    If an ICMP packet "Fragmentation needed" or "Packet Too Big" is received then this is
>    interpreted as a Probe Failure, as defined in [RFC4821] Section 7.5.
>  
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-tram-stun-pmtud-10: Discuss
> 
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ <https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/>
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 4.1.x and 4.2.x
> 
> Please specify how this simple probing mechanism will work with IPv6. It
> shouldn't be too difficult to do (cleanup references to the DF bit, use Type 2
> "Packet Too Big" to identify failures etc.). Similar treatment will be required
> for the complete probing mechanism as well.
> 
> 
> 
> 
>  
> _______________________________________________
> tram mailing list
> tram@ietf.org <mailto:tram@ietf.org>
> https://www.ietf.org/mailman/listinfo/tram <https://www.ietf.org/mailman/listinfo/tram>

v2.23.0 | Report a Bug | By Email