[IPv6] These problems aren't new, they've been in IPv4 for 40+ years / IPv6 layer probing (Re: Best Source / Destination address pair [WAS: Best Address type (assuming God's view)])

[Mark Smith <[e-mail]>]

Hi Brian,

On Fri, 8 Sept 2023 at 09:22, Brian E Carpenter
<[e-mail]> wrote:
>
> Mark,
> On 08-Sep-23 09:29, Mark Smith wrote:
> > On Fri, 8 Sept 2023 at 06:51, Brian E Carpenter
> > <[e-mail]> wrote:

<snip>

> > Unreachable DAs are a just case of packet loss, either temporary or
> > semi-permanent (until the bad DNS entry is fixed).
> >
> > Unless we're going to revise the Internet protocol model, per RFC 1122,
> >
> > "Internet Layer"
> >
> > " Thus, IP datagrams may arrive at the destination host damaged,
> >                duplicated, out of order, or not at all.  The layers above
> >                IP are responsible for reliable delivery service when it
> >                is required."
>
> I don't believe that statement was intended to cover the case where
> there is no path between the chosen source address and the chosen
> destination address. Multi-addressing was not a thing in 1989.
>

Not by that name. Multi-addressing is another name for multi-homing,
so as long as that has been supported in Pv4, it has been possible
that there isn't a path between an SA/DA pair between a pair of
multihomed hosts, or a single homed and multi-homed host.

This text from RFC 791, September 1981 (and in earlier versions at
least back to IEN111), could be used exactly and literally to describe
IPv6 multi-addressing:

    That is, provision must be made for a host to have several physical
    interfaces to the network with each having several logical internet
    addresses.

DNS (Sep 1983) and earlier host files can and could have provided
unreachable DAs for a multi-homed host.

RFC1597 IPv4 private addressing created the possibility of
specifically unreachable IPv4 DAs in global DNS, e.g DNS providing a
globally reachable IPv4 DA as well as a globally unreachable RFC1918
DA.

IPv6 has only made these issues more likely to happen since
multi-addressing (or multi-homing) is the default (which I'm guessing
originated from RFC 1681 by Steve Bellovin). They're not new issues in
IPv4 at all.

> > it's not the IPv6 layer's problem, it's either the transport layer's
> > problem or the application layer's problem.
>
> They are certainly the victims.

<snip>

> > A getaddrpairs() call wouldn't hide it. It needs to be hidden in the
> > transport layer.
>

To add to this, I said this because I think that is really where the
problem is - in the transport layer protocols.

TCP and similar timeouts that are not human user friendly. Per an
article I've referenced below, human user friendly timeouts need to be
in the order of milliseconds, up to a total response time of no more
than 1 second, not multiple seconds.

> It isn't intended to hide the existence of multiple paths. It's
> intended to avoid the upper layers being handed *non-existent*
> paths. The current situation, with getaddrinfo() being disjoint
> from source address selection, *guarantees* that the upper layer
> will start with a non-existent path in some circumstances. How
> can that be good systems design?
>

I think the probing mechanism you're describing would effectively be a
partial duplication of the upper layer connection establishment
mechanisms that already exist e.g. TCP's 3 Way Handshake, and I'd say
that's not good system design.

For this probing mechanism, what packets are you going to use?
Unreliable and/or blocked ICMPv6? Spoofed application TCP
SYN/SYN-ACKs*?

What timeout values are you going to use for this IPv6 reachability
probing mechanism? TCP's?

An application blocking behind a multiple second "getaddrprobe()" call
is well above the threshold of what is considered a good human user
experience of 1 second, which is why Happy Eyeballs and my test
program below use time outs in the 100s of milliseconds:

"Response Times: The 3 Important Limits"
https://www.nngroup.com/articles/response-times-3-important-limits/

TCP and similar's (i.e. MPTCP, QUIC, SCTP) connection establishment
mechanisms actually do two things concurrently - both test
reachability of a DA, and negotiate connection establishment if the DA
is reachable.

Regards,
Mark.






> I think that is completely disjoint from the need to handle
> multipath in the upper layer, which I completely agree with.
>
>      Brian
>
> > Multipath, and therefore multi addressing aware
> > transport layer protocols can hide it. MPTCP and MPQUIC need to adopt
> > Happy Eyeball style techniques for their connection setup, attempting
> > to connect to the multiple IPv6 and IPv4 DAs with an amount of
> > concurrency.
> >
> > For the time being of putting it in applications; current HEv2 is hard
> > because it requires concurrent programming. It's possible to achieve a
> > similar outcome using traditional sequential programming (contrived
> > unreachable and unavailable DNS As and AAAAs, plus example.com's IPv4
> > and IPv6 addresses)
> >
> > [mark@opex src]$ ./seqhe seqhe.nosense.org 80 "GET /"
> > getaddrinfo(seqhe.nosense.org)
> >          Duration 0 secs, 12 ms
> > conntout(::1, 112 ms)
> >          conntout() connection error
> >          conntout() duration 0 secs, 0 ms
> > conntout(fe80::4a12:c679:54de:64f0, 112 ms)
> >          conntout() timeout
> > conntout(fd68:1e02:dc1a:ffff::3, 112 ms)
> >          conntout() connection error
> >          conntout() duration 0 secs, 1 ms
> > conntout(2606:2800:220:1:248:1893:25c8:1946, 112 ms)
> >          conntout() timeout
> > conntout(127.0.0.1, 100 ms)
> >          conntout() connection error
> >          conntout() duration 0 secs, 0 ms
> > conntout(10.255.255.3, 100 ms)
> >          conntout() timeout
> > conntout(93.184.216.34, 100 ms)
> >          conntout() timeout
> > conntout(::1, 281 ms)
> >          conntout() connection error
> >          conntout() duration 0 secs, 0 ms
> > conntout(fe80::4a12:c679:54de:64f0, 281 ms)
> >          conntout() timeout
> > conntout(fd68:1e02:dc1a:ffff::3, 281 ms)
> >          conntout() connection error
> >          conntout() duration 0 secs, 1 ms
> > conntout(2606:2800:220:1:248:1893:25c8:1946, 281 ms)
> >          conntout() connection established.
> >          Approx. SYN/SYN-ACK RTT 0 secs, 154 ms
> > Received 500 bytes:
> > ---
> > HTTP/1.0 400 Bad Request
> > Content-Type: text/html
> > Content-Length: 349
> > Connection: close
> > Date: Thu, 07 Sep 2023 21:25:58 GMT
> > Server: ECSF (laa/7AA1)
> >
> > <?xml version="1.0" encoding="iso-8859-1"?>
> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> >           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> > <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
> >          <head>
> >                  <title>400 - Bad Request</title>
> >          </head>
> >          <body>
> >                  <h1>400 - Bad Request</h1>
> >          </body>
> > </ht
> > ---
> >
> > Regards,
> > Mark.
> >
> >>      Brian
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------