Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback
waldemar <waldemar@wdmsys.com> Wed, 21 June 2023 05:02 UTC
Return-Path: <waldemar@wdmsys.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CCFC14CE53 for <ipv6@ietfa.amsl.com>; Tue, 20 Jun 2023 22:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wdmsys.com header.b="jPxFCZL2"; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b="LRXkWtff"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x8f8BJCLgx9 for <ipv6@ietfa.amsl.com>; Tue, 20 Jun 2023 22:02:52 -0700 (PDT)
Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C183DC14CEFA for <ipv6@ietf.org>; Tue, 20 Jun 2023 22:02:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1687323772; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=DCuOBgjqhPGF0ObxvksmLCUAGDsPfkxYcEeOXqitLefPbCJ2N4IXMY6MgaTVDWYUkvrTImkVB7OXL lnBY9iDVqhudTCuJBJUqB91QShaxk7Zwwdf2Jz6B8XULRexxXFeEf/XfLBEk5hna/0xfS2SVLj3m8N CjrroLa1LsVwW2whruQvFZbb+aZi9avQU15WNJUXVLiFtmG2xhk1RkNB1dJQai7/flqhJmkJb0WOyy XhUxmy96VCobFwaMmNO2sgLkbOmfHJ88aZVbCKn3pcclAiN6bG1d8VwZXSD4kNkbd5xbyTb731iul/ HfTpc8ajMcd+GCyjKSnjPIVk23PCG0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:dkim-signature:dkim-signature:from; bh=7PAkY1wogs+ki7pMW+ecvfgOJYP8mSJGyaWANK9+EzI=; b=ny5h6lE/T2AFXIjfQ7yD+8FqK/qokgWn4G45EO9n293DAPrXMqD46l0A0gCx4IA58GaERM3Xqur1x AZ2XDGXNgU3Fm8jcSZFBCAOS6a5/gSKeyOj6OUxWzuIf0JuuqGbQ0rp+xqI4+5Ox9uw0F6cQ7CqaAJ Q9d9zNmkSYlAqMZBdfIz34Yleld8elOF+4JDaELYllkX8xkMcnMtCxNXD++HyIF6ERSBIwoAaCWLqC 8bsoLxykbg7dj8kUBeby/idTb7uNIhL03vsrSp6k8MPNwEhYGUk20jGsqoxbeLoSRO8ncSbdJJlCoV /yuGeg2peNIeoAonm6f0mjDmaC0kVLA==
ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=wdmsys.com smtp.remote-ip=168.235.72.19; dmarc=none header.from=wdmsys.com; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wdmsys.com; s=duo-1675405977089-29a98ead; h=content-transfer-encoding:content-type:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:from; bh=7PAkY1wogs+ki7pMW+ecvfgOJYP8mSJGyaWANK9+EzI=; b=jPxFCZL2gx035fY+sCCmnNrvS+bggCSr7JKrErwG0xim8GesPPabCLcgdjgS6oFhr0RVoWns5hT1U dmLJFI0FKzKbpm/t6jQ7oK/FIxjOxGHFu2Gu8Q5TF/IuQQdCVSK5VjjErO9F1rQiVJpw56C/erQBIL 2kcMVDeGnmYAKFEg=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:from; bh=7PAkY1wogs+ki7pMW+ecvfgOJYP8mSJGyaWANK9+EzI=; b=LRXkWtffJ3vxS+DqrNbZmrUbKLsw1aDsuD2W3wtfON2NJYsxzQ5dbZeTMJX0BN3J4icWzSo6wGLIx lhNAXBWW93J0KRvPg8dOGhMzuGilCqeMdJVd+yPZtgx28vV5FuloplN3EFfBu4JSEuT3tNwVOBiyR3 hzDgDhW2RZ8j7/YMNsBEwYxc4etLX0RSAOoCOklKKj3+l/uRojVbVdWNLL1D+8GOOoq1nlGXazajtK FrWDIcQdZpQD64QCA8KYFJmJcd2bkNXnDDz6FMlsc8Y2FrT1AaG3Q2fiJc8EBLpyokE2E+L283N6fT Hm/OGJq8yJ02GXzJFmhhOMpfdsI3aTg==
X-Originating-IP: 168.235.72.19
X-MHO-RoutePath: d2FsZGVtYXI=
X-MHO-User: de2e062f-0ff0-11ee-8626-d1581f149e9f
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from cmail.wdmsys.com (168-235-72-19.cloud.ramnode.com [168.235.72.19]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id de2e062f-0ff0-11ee-8626-d1581f149e9f; Wed, 21 Jun 2023 05:02:49 +0000 (UTC)
Received: from static-47-180-147-191.lsan.ca.frontiernet.net ([47.180.147.191] helo=[192.168.84.111]) by cmail.wdmsys.com with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <waldemar@wdmsys.com>) id 1qBpzU-000qI7-QM; Wed, 21 Jun 2023 05:02:48 +0000
Message-ID: <c57d9a4c-67af-488b-a2d5-e5d3cc5bd434@wdmsys.com>
Date: Tue, 20 Jun 2023 22:02:48 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>, Valentin Heinrich <v.heinrich99@gmail.com>
Cc: int-area@ietf.org, ipv6@ietf.org
References: <CABUE3Xm5nT4R8wUu6FfXW0u66YoyDS45cRTuiGjRJ0CRGsevnQ@mail.gmail.com> <908A768F-F9CF-468A-A7C1-27736FE10BFE@gmail.com> <5B0C59DC-BD03-4BEE-A719-6E892F61F916@cisco.com> <CABUE3Xk--WodVbGFQtJvPTdtH154bNE6nufxoFDJuh6nVbpFRg@mail.gmail.com> <95cdc678-a7c8-078f-08aa-6aac9c053b15@gmail.com> <CABUE3Xnt+r3nWPFeui3dqQTXpTUUOudyTfkGJm=bL57ySevjLw@mail.gmail.com>
From: waldemar <waldemar@wdmsys.com>
In-Reply-To: <CABUE3Xnt+r3nWPFeui3dqQTXpTUUOudyTfkGJm=bL57ySevjLw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/21qewcZ2v8OhGGb7cLnw_RdFJeY>
Subject: Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jun 2023 05:02:57 -0000
It would be nice if you consider IPv4/IPv6 traversal. What is IPv6 end going to expect when dealing with IPv4 on the other end. There is a draft https://datatracker.ietf.org/doc/draft-augustyn-intarea-ipref/ which makes such traversals possible and highly scalable. On 6/20/23 21:53, Tal Mizrahi wrote: > Hi Valentin, > > Thanks for this valuable data. > Based on your findings, the good news is that new codes will most > likely traverse NATs, and the bad news is that most hosts will respond > according to the "old" behavior without checking the code value. In > light of the latter observation, I would say that new behavior *from > the responder* requires a new ICMP type. However, more feedback about > this assessment is welcome. > > Cheers, > Tal. > > On Tue, Jun 20, 2023 at 8:45 PM Valentin Heinrich > <v.heinrich99@gmail.com> wrote: >> we had similar questions when working on reverse traceroute >> (https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute). >> Should we use new ICMP types or extend existing ones with a new code? >> >> We actually conducted measurements to test deployability of those two >> choices. >> One of the big question marks was whether new ICMP messages using a new >> type are able to traverse common NAT middleboxes. >> Unfortunately, as one would probably expect, new ICMP types are most >> commonly filtered (or they just bypass the NAT, which is just as bad as >> they are forwarded untranslated into the public internet). >> We then sent ICMP Echo requests with the new codes 1 and 2 through those >> same NAT boxes. >> Only a single NAT box (out of 12) dropped the corresponding Echo >> response message and in all other cases both requests and replies >> correctly traversed the NAT. >> In this regard, our measurements showed that extending existing ICMP >> Echo messages with new codes is the way to go if immediate deployability >> is the goal. >> >> We then also performed a measurement to assess the deployment of ICMP >> Echo messages with new codes on the public Internet. >> We probed over a million hosts that correctly responded to regular ICMP >> Echo requests (code 0) with ICMP Echo responses. >> To each of those hosts we sent ICMP Echo requests with code 1. Over 92% >> of the probed hosts responded with an ICMP Echo response and reflected >> the new code back in their response. >> The fact that we received that many "reflective" responses shows us, >> that ICMP Echo messages (both request and response) with a new code make >> it through the Internet unfiltered and unaltered in the vast majority of >> cases. About 3% of the probes were answered with a regular ICMP Echo >> response (code 0), thus not reflecting the request's code back. >> >> For more details of the measurement study, you can have a look at this >> talk: https://youtu.be/Y7NtqLEtfgjU?t=63 >> >> Or listen to this episode of the Ping Podcast: >> https://blubrry.com/ping_podcast/94883480/reverse-traceroute-its-just-traceroute-but-the-other-direction/ >> >> >> One caveat is however that we conducted these measurements only on IPv4. >> Results might or might not differ for IPv6. >> For reverse traceroute, which itself implements both ICMP and ICMPv6, we >> have however successfully tested our implementation across the public >> internet. >> >> I hope this data point helps in this discussion. >> >> On 07.06.23 06:30, Tal Mizrahi wrote: >>> Bob, Eric, >>> >>> Thanks for the feedback. >>> Defining a new code for ICMPv6 Echo rather than defining a new type >>> may be the right way to go. >>> Our main concern with this is that RFC 4443 defines what to do with an >>> unknown type, but does not define what to do with an unknown code. It >>> is not clear what existing implementations do when receiving an Echo >>> Request with an unknown code. That is why the current draft calls for >>> a new type. However, we are open to more feedback about this, and it >>> may end up being just a new code. >>> >>> Cheers, >>> Tal. >>> >>> On Tue, Jun 6, 2023 at 8:33 PM Eric Vyncke (evyncke) <evyncke@cisco.com> wrote: >>>> Without any hat, I agree with Bob. >>>> >>>> This I-D should eventually go to 6MAN WG though (with my AD hat) >>>> >>>> -éric >>>> >>>> On 06/06/2023, 08:34, "Int-area on behalf of Bob Hinden" <int-area-bounces@ietf.org <mailto:int-area-bounces@ietf.org> on behalf of bob.hinden@gmail.com <mailto:bob.hinden@gmail.com>> wrote: >>>> >>>> >>>> Tal, >>>> >>>> >>>> I did a quick read of your draft. >>>> >>>> >>>> As noted in the draft this seems to be very similar to ICMPv6 Echo/Echo Reply. The change is to include the request packet in the response, not just the payload. >>>> >>>> >>>> While I don’t have any real opinion on the need for this, I do think it would be a lot simpler if the draft just defined a new Code field value for Echo Request/Reply that specified this behavior. Currently the Code field is set to zero, another value could specify this behavior. >>>> >>>> >>>> Deployment might be easier as I suspect ICMPv6 types other than the current definitions will be filtered in many places. >>>> >>>> >>>> Bob >>>> >>>> >>>> >>>> >>>> >>>> >>>>> On Jun 6, 2023, at 4:54 AM, Tal Mizrahi <tal.mizrahi.phd@gmail.com <mailto:tal.mizrahi.phd@gmail.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> New draft: https://datatracker.ietf.org/doc/draft-mcb-intarea-icmpv6-loopback/ <https://datatracker.ietf.org/doc/draft-mcb-intarea-icmpv6-loopback/> >>>>> >>>>> We have posted a new draft that proposes two new ICMPv6 message types: >>>>> Loopback Request and Reply. >>>>> ICMPv6 Loopback is very similar to Echo, except that after a Loopback >>>>> Request is sent, its corresponding Reply includes as much of the IPv6 >>>>> Loopback Request packet as possible, including the IPv6 header and >>>>> IPv6 extension headers and options if they are present. >>>>> >>>>> We believe that ICMPv6 Loopback can be very useful for returning IPv6 >>>>> options that were included in Request packet back to the sender, >>>>> including for example sending IOAM [RFC 9197] data from the Request >>>>> back to the sender, sending the SRH [RFC 8754] of the Request back to >>>>> the sender, as well as for in-progress / future protocols such as >>>>> draft-filsfils-spring-path-tracing and draft-kumar-ippm-ifa. >>>>> >>>>> We would be happy for feedback, as well as suggestions about whether >>>>> the INT-AREA WG is the right place to discuss this draft. >>>>> >>>>> Cheers, >>>>> Tal. >>>>> >>>>> _______________________________________________ >>>>> Int-area mailing list >>>>> Int-area@ietf.org <mailto:Int-area@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area> >>>> >>>> >>>> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Tal Mizrahi
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Erik Kline
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Justin Iurman
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Luigi IANNONE
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Florian Obser
- Re: [IPv6] [EXTERNAL] Re: [Int-area] New Draft - … Robinson, Herbie
- Re: [IPv6] [EXTERNAL] Re: [Int-area] New Draft - … Tal Mizrahi
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Michael Richardson
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Tianran Zhou
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Tal Mizrahi
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Michael Richardson
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback Tal Mizrahi
- Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback waldemar