[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: [IPv6] [Int-area] New Draft - ICMPv6 Loopback
From: waldemar <waldemar () wdmsys ! com>
Date: 2023-06-21 5:02:48
Message-ID: c57d9a4c-67af-488b-a2d5-e5d3cc5bd434 () wdmsys ! com
[Download RAW message or body]
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic