Re: [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)])

[Brian E Carpenter <[e-mail]>]

in line...

On 08-Sep-23 14:00, Mark Smith wrote:
> 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.

That's all true but since the driving force behind RFC1597/1918 was
address shortage, actual multi-addressing was then and always remained
a rarity and was not a real operational issue.

> 
> 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 was certainly always an expectation for IPv6, although we have
failed to solve the related issues.

> 
>>> 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.

Well, the last serious analysis put the problem exactly at the transport
layer to network layer interface, which is why we designed shim6 to sit
at that interface.
  
> 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.

Sure. That's well known. However, as we discovered in shim6, the
actual RTT for probes can be much longer.

> 
>> 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

I *did not* describe probing or any other mechanism. I said we should
have the network layer provide *address pairs* to the transport
layer rather than solo destination addresses. An implementation
might well include probing as well as static and routing information.

> 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.

Why not? This seems like an area where layer violation may be
exactly what's needed.

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

Whatever works best. The only thing that needs to be standardised
is the API.

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

Same answer.

> An application blocking behind a multiple second "getaddrprobe()" call

I didn't propose that. Indeed the probing mechanism, if there is one,
needs to be asynchronous. It might well be that if you call
getaddrpairs() a hundred miliiseconds later, you'd get a different
answer.

> 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.

And that's fine, and that's how it should be. I am not proposing to
touch that.

     Brian
> 
> 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
>>>> --------------------------------------------------------------------