Subject: [quicwg/base-drafts] Allow servers to send a preferred address of each address family (#2296)

From: David Schinazi <[email-masked]>
Date: Fri, 04 Jan 2019 14:54:04 -0800

This change allows servers to send a preferred address of each address family. The previous definition of preferred_address only allowed sending one address family, and this had the disadvantage of picking the non-deterministic address family used by the Initial if the client is performing Happy Eyeballs. Clients may now use the best address family based on their network attachment.

Fixes #2122.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2296

-- Commit Summary --

  * Allow servers to send a preferred address of each address family

-- File Changes --

    M draft-ietf-quic-transport.md (9)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2296.patch
https://github.com/quicwg/base-drafts/pull/2296.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296

---

From: janaiyengar <[email-masked]>
Date: Fri, 04 Jan 2019 15:37:12 -0800

janaiyengar commented on this pull request.

I'm ok with this change, but @MikeBishop may have opinions and should take a look, since he proposed the PreferredAddress TP. I think I prefer calling this "alternate address".

Also, there should probably be some guidance about when these alternate addresses may be used by a client. The current text suggests that a client SHOULD validate them immediately after handshake, but that may be unnecessarily restrictive. I don't see any reason why a client could not validate and/or use these addresses later in the connection.

> @@ -2116,6 +2116,9 @@ packets.
 A server conveys a preferred address by including the preferred_address
 transport parameter in the TLS handshake.
 
+Servers MAY communicate a preferred address of each address family (IPv4 and

I think I would prefer to call this an "alternate" address.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-189564971

---

From: ianswett <[email-masked]>
Date: Sun, 06 Jan 2019 13:15:29 -0800

ianswett commented on this pull request.

I like this idea, one suggestion.

If you're speaking of "preferred" address, this is consistent with the rest of the text.  If you want to change the name, I'd suggest opening a separate issue.

I'm happy with preferred, since if it's just alternate, why would the client change?  Alternate implies no preference, when in fact the server does prefer the other address.

 ~~~
    struct {
-     enum { IPv4(4), IPv6(6), (15) } ipVersion;
-     opaque ipAddress<4..2^8-1>;
+     opaque ipv4Address<0..2^8-1>;

Aren't these two fields now fixed sizes?  If so, any reason not to specify those?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-189644456

---

From: Martin Thomson <[email-masked]>
Date: Sun, 06 Jan 2019 16:07:22 -0800

martinthomson commented on this pull request.

 ~~~
    struct {

Yep.  I think that the invalid address (0.0.0.0 or ::) is probably OK here.

"preferred" seems right.  Yes, it is an alternative, but the fact that it's a preferred alternative is what is important.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245528920

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 06 Jan 2019 16:15:55 -0800

kazuho commented on this pull request.

 ~~~
    struct {

IIUC the text says that the value should be a zero-length byte array if the address type is not used, rather than using an invalid address.

Therefore I think the correct notation is:
```
opaque ipv4Address<0..4>;
opaque ipv6Address<0..16>;
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245529304

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 06 Jan 2019 16:26:34 -0800

@DavidSchinazi Thank you for working on this.

 ~~~
    struct {
-     enum { IPv4(4), IPv6(6), (15) } ipVersion;
-     opaque ipAddress<4..2^8-1>;
+     opaque ipv4Address<0..2^8-1>;
+     opaque ipv6Address<0..2^8-1>;
      uint16 port;

The PR seems to assume that:
* IPv4 and IPv6 are the only two types of underlying protocols that we care, while the current draft provides extensibility (i.e. we can add new types to the ipVersion enumeration).
* All the addresses share the same port number.

Are we fine with that?

If the intent here is to add support for IPv6 address:port without having any impact on other aspects, I believe that the struct should look like:

```
struct {
    enum { IPv4(4), IPv6(6), (15) } ipVersion;
    struct {
        select (ipVersion) {
        case IPv4:
            struct {
                opaque address[4];
                uint16 port;
            };
        case IPv6:
            struct {
                opaque address[16];
                uint16 port;
            };
        }
    } <0..2^8-1>;
} AddressPort;

struct {
    AddressPort address<0..2^8-1>;
    uint16 port;
    opaque connectionId<0..18>;
    opaque statelessResetToken[16];
} PreferredAddress;

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-189652498

---

From: David Schinazi <[email-masked]>
Date: Sun, 06 Jan 2019 16:52:10 -0800

@kazuho I went with this approach to minimize changes from the current design. Having a list that allows different ports and future versions of IP are fine by me, but there seemed to be more pushback when that was proposed in #2122. As long as we have a way of communicating one IPv4 address *and* one IPv6 address I'm happy.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#issuecomment-451791953

---

From: ianswett <[email-masked]>
Date: Sun, 06 Jan 2019 19:54:31 -0800

~~~
    struct {

@kazuho suggestion SGTM.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245544613

---

From: ianswett <[email-masked]>
Date: Sun, 06 Jan 2019 19:56:34 -0800

~~~
    struct {

I'm fine with only supporting v4 and v6.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245544761

---

From: Rui Paulo <[email-masked]>
Date: Mon, 07 Jan 2019 12:13:15 -0800

We could allow multiple PreferredAddress TPs and avoid the zero-length address problem.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#issuecomment-452066277

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 07 Jan 2019 12:19:12 -0800

@DavidSchinazi Thank you for the clarification. I think I'm fine with that.

@rpaulo The PreferredAddress structure includes Connection ID and Stateless Reset Token. I think we should avoid requiring the server to send them twice when it is constrained by the 3-packet rule.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#issuecomment-452068052

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 23:35:08 +0000 (UTC)

~~~
    struct {

And I'm ok with having the same port across versions.  Which all suggests a smaller change:
```
ipv4Address[4];
ipv6Address[16];
uint16 port;
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245834596

---

From: Marten Seemann <[email-masked]>
Date: Mon, 07 Jan 2019 17:44:14 -0800

marten-seemann commented on this pull request.

 ~~~
    struct {

Why would the ipv4 and ipv6 port numbers be the same? That seems like a special case derived from the HTTP use case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245855684

---

From: ianswett <[email-masked]>
Date: Mon, 07 Jan 2019 18:45:06 -0800

~~~
    struct {

If there's a real use case for separate port numbers, I can see adding that flexibility, but otherwise I prefer @martinthomson 's suggestion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245863285

---

From: Marten Seemann <[email-masked]>
Date: Tue, 08 Jan 2019 02:48:12 +0000 (UTC)

~~~
    struct {

p2p applications might not assign any meaning to ports, but just use a random port number. There's no reason why those values would be the same for IPv4 and IPv6.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245863722

---

From: MikkelFJ <[email-masked]>
Date: Tue, 08 Jan 2019 10:16:19 +0000 (UTC)

mikkelfj commented on this pull request.

 ~~~
    struct {

Yes, this seems like an unnecessary constraint. Especially since the mechanism can be used to advertise non-standard ports. Random ports could also be a first  line of defence against DoS attacks and they could be used to move endpoints dynamically over time. Forcing two different interfaces to be in sync isn't ideal for that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245941617

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 08 Jan 2019 10:38:25 +0000 (UTC)

~~~
    struct {

This might be a dumb question, but would P2P applications use the feature, considering that the intent is to remap clients connecting to an anycast address to a unicast address?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245948889

---

From: MikkelFJ <[email-masked]>
Date: Tue, 08 Jan 2019 03:17:59 -0800

~~~
    struct {

I think the intent is to deal with anycast, but I could see it being used defensively against attacks.

As for P2P there is a strong case for both ends to use a known fixed port. However, I could also see this as a way to load balance multiple connections to multiple threads or processes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r245959985

---

From: David Schinazi <[email-masked]>
Date: Tue, 08 Jan 2019 09:38:49 -0800

DavidSchinazi commented on this pull request.

 ~~~
    struct {

@marten-seemann most implementations (on the operating systems I'm familiar with) will use a single dual-stack listening socket for all address families so unless you go out of your way you will end up with the same port. That's true of HTTP servers and P2P apps.

That said, if there is consensus that separate ports are useful, I'm OK adding separate ports to this PR.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r246088034

---

From: David Schinazi <[email-masked]>
Date: Tue, 08 Jan 2019 09:49:19 -0800

@DavidSchinazi pushed 1 commit.

cf29b304eecda537ba1d9c56dcfb1ced423b00c2  Simplify wire-format

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296/files/7aecc40ead748d26988ef81a8799faeda0262f29..cf29b304eecda537ba1d9c56dcfb1ced423b00c2

---

From: David Schinazi <[email-masked]>
Date: Tue, 08 Jan 2019 17:50:37 +0000 (UTC)

I've simplified the wire-format using @martinthomson's suggestion with separate port numbers

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#issuecomment-452390392

---

From: ianswett <[email-masked]>
Date: Tue, 08 Jan 2019 21:21:46 +0000 (UTC)

ianswett approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-190447908

---

From: Mike Bishop <[email-masked]>
Date: Tue, 08 Jan 2019 16:22:14 -0800

MikeBishop approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-190517595

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 08 Jan 2019 16:57:56 -0800

kazuho approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-190525267

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 09 Jan 2019 17:19:14 +0000 (UTC)

dtikhonov commented on this pull request.

 ~~~
    struct {

I'd err on the side of making it as generic as possible: that is, separate ports.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r246461779

---

From: David Schinazi <[email-masked]>
Date: Wed, 09 Jan 2019 20:57:38 +0000 (UTC)

~~~
    struct {

The latest version has separate ports, see the diff.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r246515143

---

From: ianswett <[email-masked]>
Date: Sat, 12 Jan 2019 18:56:45 -0800

ianswett requested changes on this pull request.

I realize, looking back on the issue, why Jana mentioned alternate.  There are two separate cases: Connection migration and Server's Preferred Address.

In one case, you want to make sure connection migration doesn't fail when moving from v6 to v4 only, but you don't want them to do anything after the handshake.  In the other case, you want them to migrate to a more stable IP after the handshake.

If the server omits the address family you connected on, but supplies a preferred address on the other address family, do you try to migrate?

I suspect we need to change the structure from what's in this PR, and if not, we need to nail down the critical use cases and make sure they all work.  

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-191958658

---

From: ianswett <[email-masked]>
Date: Mon, 14 Jan 2019 10:53:29 -0800

Part of me wants to be more specific about what the preferred client behavior, but I realize you're being flexible intentionally, and I think that's ok in the end.

Re-reading this PR, I think its workable as is, but this might read better if this paragraph was merged into the next paragraph and the next paragraph was updated to something like: "one of the servers preferred addresses using..."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-192306688

---

From: David Schinazi <[email-masked]>
Date: Mon, 14 Jan 2019 12:11:50 -0800

68a4d3a0da6ff40c707187b2e0a6062bc2d664e5  Clarify client response to preferred_address

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296/files/cf29b304eecda537ba1d9c56dcfb1ced423b00c2..68a4d3a0da6ff40c707187b2e0a6062bc2d664e5

---

From: David Schinazi <[email-masked]>
Date: Mon, 14 Jan 2019 12:14:06 -0800

@ianswett I think migration and preferred address are separate parts of the protocol. The goal of this PR is to improve preferred address. It allows the client to pick the address family it transfers to right after the handshake. If the server only provides you with a preferred address family you don't have access to, you can simply ignore it - and that's not new from this PR. I've slightly tweaked the text to clarify how clients respond to preferred_address. Does this address your concerns?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#issuecomment-454145541

---

From: ianswett <[email-masked]>
Date: Mon, 14 Jan 2019 20:16:27 +0000 (UTC)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-192342943

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jan 2019 16:31:12 -0800

> @@ -2116,9 +2116,13 @@ packets.
 
-Once the handshake is finished, the client SHOULD initiate path validation (see
-{{migrate-validate}}) of the server's preferred address using the connection ID
-provided in the preferred_address transport parameter.
+Servers MAY communicate a preferred address of each address family (IPv4 and
+IPv6) to allow clients to pick the one most suited to their network attachment.

After all our discussion, the question I have here is whether this preferred address might be used for a migating client.  Say I use v6 now, but then migrate to a network that doesn't have v6.  Is it acceptable for me to use the v6 preferred address during that migration?  The text here is silent on that point.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-192929031

---

From: David Schinazi <[email-masked]>
Date: Wed, 16 Jan 2019 10:42:03 -0800

@martinthomson I'm thinking we may want more deployment experience before we decide if we want to recommend or prohibit that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r248404268

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jan 2019 13:37:48 -0800

I'm only asking if it is *allowed*.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r248460095

---

From: David Schinazi <[email-masked]>
Date: Thu, 17 Jan 2019 11:58:13 -0800

It is currently allowed - there is no text prohibiting it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r248819550

---

From: janaiyengar <[email-masked]>
Date: Thu, 17 Jan 2019 12:23:31 -0800

Yes, this ambiguity comes from the fact that this PR solves a problem that is slightly different than the one solved by the PreferredAddress TP.  I think you're all right that "preferred" is better than "alternate", but there's a gap.

I think this can be addressed by just a bit of text stating that it is up to the client to decide which among the preferred addresses it uses.  If the client has access to both address families, it's up to the client to decide whether it wants to migrate or not. The addresses are preferred by the server, but it's up to the client to decide if and when it moves to those.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r248827317

---

From: janaiyengar <[email-masked]>
Date: Thu, 17 Jan 2019 12:24:31 -0800

We may want to explicitly state this. See my comment above.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r248827633

---

From: David Schinazi <[email-masked]>
Date: Thu, 17 Jan 2019 22:04:36 +0000 (UTC)

5d1d27668056e76ba005e0d141fea70fe46b5c12  Add text to clarify how the second preferred address interacts with migration

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296/files/68a4d3a0da6ff40c707187b2e0a6062bc2d664e5..5d1d27668056e76ba005e0d141fea70fe46b5c12

---

From: David Schinazi <[email-masked]>
Date: Thu, 17 Jan 2019 14:06:16 -0800

Good point, I've added some text to the _Interaction of Client Migration and Preferred Address_ section.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r248859413

---

From: janaiyengar <[email-masked]>
Date: Thu, 17 Jan 2019 17:44:23 -0800

I'm good with this PR. @martinthomson -- can you see if your concern is addressed?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#issuecomment-455397206

---

From: janaiyengar <[email-masked]>
Date: Thu, 17 Jan 2019 17:44:34 -0800

janaiyengar approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-193920168

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jan 2019 18:00:41 -0800

Almost right...

> @@ -2169,6 +2173,9 @@ receiving a probe packet from a different address.  Servers MUST NOT send more
 than a minimum congestion window's worth of non-probing packets to the new
 address before path validation is complete.
 
+When a client wishes to migrate to a new local address that is of a different
+address family from the currently used server address, the client can attempt

This can be simpler.  A client that migrates to a new address SHOULD use a preferred address from the same address family for the server. 

I wonder if we should forbid doing a new address lookup for the name or if we should stay silent on that point...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-193923001

---

From: Jana Iyemgar <[email-masked]>
Date: Thu, 17 Jan 2019 18:10:54 -0800

+1 to the SHOULD.  

Let's not forbid lookups.  It's an interesting question whether other mechanisms of learning the server's addresses are useful or not; I think more deployment experience would be useful here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r248907574

---

From: David Schinazi <[email-masked]>
Date: Thu, 17 Jan 2019 21:40:07 -0800

38f53804e318e73aed64a181decb2b9d6039442c  Simplify interaction with migration using text from MT

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296/files/5d1d27668056e76ba005e0d141fea70fe46b5c12..38f53804e318e73aed64a181decb2b9d6039442c

---

From: David Schinazi <[email-masked]>
Date: Thu, 17 Jan 2019 21:41:12 -0800

Agreed. I've incorporated @martinthomson's text. I agree with Jana that we shouldn't forbid lookups yet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r248932688

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jan 2019 23:30:32 -0800

martinthomson approved this pull request.

After reading my text, I am not entirely happy with it, but I lack a better suggestion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-193974509

---

From: ianswett <[email-masked]>
Date: Fri, 18 Jan 2019 08:04:48 -0800

Still LG

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-194166371

---

From: ianswett <[email-masked]>
Date: Fri, 18 Jan 2019 16:05:48 +0000 (UTC)

Still LG

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#pullrequestreview-194166858

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Jan 2019 09:10:06 -0800

MikeBishop commented on this pull request.

I'm okay with the SHOULD.  The caveats on our network are:
- A lookup by address from a different network will lead you to a different machine.  Unless we then have it route back to the machine you were previously talking to, it will ignore / Reset you.  Of course, if it can't route, it shouldn't have the same Reset Token key, so you'll probably then drop the Reset....
- Using the SPA from a different network will lead you back to the same host, which might not be a good choice for you to keep using.  You'll likely get a prompt GOAWAY in HTTP/3.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r249118894

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 18 Jan 2019 10:36:46 -0800

RyanAtGoogle commented on this pull request.

On our networks as well, lookups are unlikely to route to the same machine. Given that there is no reason to expect a lookup to successfully route to the same machine (even on the SAME network), forbidding it seems like the right choice.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r249144376

---

From: David Schinazi <[email-masked]>
Date: Fri, 18 Jan 2019 11:31:55 -0800

I think the DNS lookup issue is orthogonal to this PR. @martinthomson can you file a new issue to discuss it there?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#discussion_r249160827

---

From: David Schinazi <[email-masked]>
Date: Fri, 18 Jan 2019 11:32:26 -0800

@martinthomson is there anything left for me to do so this can get merged in?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#issuecomment-455661877

---

From: Martin Thomson <[email-masked]>
Date: Sun, 20 Jan 2019 20:34:42 -0800

Merged #2296 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#event-2085429267

---

From: Martin Thomson <[email-masked]>
Date: Sun, 20 Jan 2019 20:34:58 -0800

You could wait until I had time to check it, that's all.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2296#issuecomment-455945739