Subject: [quicwg/base-drafts] Why is ipAddress variable length (#2158)

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 13:02:00 -0800

```
     enum { IPv4(4), IPv6(6), (15) } ipVersion;
     opaque ipAddress<4..2^8-1>;
```

Elsewhere in this spec we've tried to make it impossible to say bogus things, but this is a lot of room for screwing up. You know the exact length from ipVersion, so why not have a select here? 

```
select (ipVersion) {
   case IPv4:  opaque ip4[4];
   case IPv6: opaque ip6[16];
}
```

Note that because the extension itself is length delimited, parsing unknown versions will still 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/issues/2158

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Dec 2018 22:22:07 +0000 (UTC)

This is an issue which #1533 was filed to fix, but no consensus to take the change.  If you'd like to champion it, feel free.  I don't feel strongly either way.

-- 
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/issues/2158#issuecomment-447141805

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Dec 2018 14:39:34 -0800

FWIW, in #2122 we are discussing about using the structure to send multiple entries of PreferredAddress (e.g., one that contains IPv4 address and the other containing a IPv6 address).

I'd assume that we would be doing either
```
PreferredAddress addresses<x..y>;
```
or
```
struct Address {
    enum { IPv4(4), IPv6(6), (15) } ipVersion;
    opaque ipAddress<4..2^8-1>;
    uint16 port;
}
struct PreferredAddress {
    AddressPort addresses<x..y>;
    ...
}
```

Either ways, the length of the IP address would be required to keep the structure extensible (i.e. allowing a new IP version to be defined).

-- 
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/issues/2158#issuecomment-447147008

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 16:39:25 -0800

On Thu, Dec 13, 2018 at 2:39 PM Kazuho Oku <[email-masked]> wrote:

> FWIW, in #2122 <https://github.com/quicwg/base-drafts/issues/2122> we are
> discussing about using the structure to send multiple entries of
> PreferredAddress (e.g., one that contains IPv4 address and the other
> containing a IPv6 address).
>
> Either ways, the length of the IP address would be required to keep the
> structure extensible (i.e. allowing a new IP version to be defined).
>

Yes, I agree if you do that, then you will need some kind of length
structure. Though you could do:

```
struct Address {
    enum {...} ipVersion;
    uint8 length;
    switch (ipVersion) {

    }
    uint16 port;
}
```

This would have the advantage that it would detect malformatted addresses
directly in the parser.

-- 
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/issues/2158#issuecomment-447172636

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Dec 2018 16:50:38 -0800

Doesn't that have the same encoding as the following? Assuming that they are identical, I do not mind either ways.
```
struct Address {
    enum { ... } ipVersion;
    opaque ipAddress<0..2^8-1>;
    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/issues/2158#issuecomment-447174591

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 16:52:57 -0800

On Thu, Dec 13, 2018 at 4:50 PM Kazuho Oku <[email-masked]> wrote:

> Doesn't that have the same encoding as the following? Assuming that they
> are identical, I do not mind either ways.
>
> struct Address {
>     enum { ... } ipVersion;
Unfortunately, it does not, because the version I proposed would include
the size of the port in the length.

-- 
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/issues/2158#issuecomment-447175001

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Dec 2018 17:12:47 -0800

@ekr 
> Unfortunately, it does not, because the version I proposed would include the size of the port in the length.

I see. So your version is equivalent to:
```
struct IPv4Address {
    byte ipaddr[4];
    uint16 port;
};

struct IPv6Address {
    byte ipaddr[16];
    uint16 port;
};

struct Address {
    enum { ... } ipVersion;
    struct {
        switch (ipVersion) {
        case v4: IPv4Address;
        case v6: IPv6Address;
       }
    } <0..2^8-1>;
};
```

That works for me, and I think it makes sense to define `port` as a property of each address type.

-- 
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/issues/2158#issuecomment-447178623

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 18:02:43 -0800

I'm not sure that any of this shuffling is going to improve things materially.  This is TLS-y and TLS is comfortable with redundant lengths.  Given that this is exactly a duplicate of #1533, I'm inclined to do nothing.

-- 
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/issues/2158#issuecomment-447187332

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 14 Dec 2018 06:06:48 -0800

I like that this discussion has been revived. If the consensus is reached to follow @ekr's suggestion to use a select, I will reopen PR #1533.

-- 
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/issues/2158#issuecomment-447335366