Subject: [tsvwg] Proposed errata for RFC 6458 sctp_bindx

From: "Jonathan T. Leighton" <[email-masked]>
Date: Wed, 4 Jan 2017 13:12:02 -0500

I've been discussing a possible errata for the sctp_bindx() description 
in RFC 6458 <https://tools.ietf.org/html/rfc6458#page-88> with Michael 
Tuexen, and he suggested posting the issue here for further comment. The 
current language is vague regarding passing IPv4 addresses versus 
IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. 
I've been advised that there is some disagreement about whether or not 
the term "IPv4 address" includes IPv4-mapped IPv6 address, so the 
proposed text attempts to avoid that issue.

OLD TEXT:

    If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
    If the sd is an IPv6 socket, the addresses passed can either be IPv4
    or IPv6 addresses.

NEW TEXT:

    If sd is an IPv4 socket, the passed addresses must be stored in
    sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
    typically must be stored in sockaddr_in6 structures, however some
    implementations may also allow addresses to be stored in sockaddr_in
    structures. For implementations that require addresses to be stored
    in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
    the socket to the corresponding IPv4 addresses.

Best regards
Jon

---

From: "Jonathan T. Leighton" <[email-masked]>
Date: Thu, 12 Jan 2017 12:36:39 -0500

Hi Michael -

I posted this to [email-masked] on 1/4/17, but it's been over a week now 
and I haven't had any response. I can try posting it again, or I can 
submit an errata and see how the authors respond. Do you have a 
suggestion about how best to proceed?

Best regards,
Jon

On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
> I've been discussing a possible errata for the sctp_bindx() 
> description in RFC 6458 <https://tools.ietf.org/html/rfc6458#page-88> 
> with Michael Tuexen, and he suggested posting the issue here for 
> further comment. The current language is vague regarding passing IPv4 
> addresses versus IPv4-mapped IPv6 addresses, as well as required 
> versus allowed behavior. I've been advised that there is some 
> disagreement about whether or not the term "IPv4 address" includes 
> IPv4-mapped IPv6 address, so the proposed text attempts to avoid that 
> issue.
>
> OLD TEXT:
>

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 12 Jan 2017 21:00:01 +0100

> On 12 Jan 2017, at 18:36, Jonathan T. Leighton <[email-masked]> wrote:
> 
> Hi Michael -
> 
> I posted this to [email-masked] on 1/4/17, but it's been over a week now and I haven't had any response. I can try posting it again, or I can submit an errata and see how the authors respond. Do you have a suggestion about how best to proceed?
I CC'ed some individuals... Given them a couple of days.
Then file an errata if you want.

I'm find with the text suggested by you.

Best regards
Michael
>> I've been discussing a possible errata for the sctp_bindx() description in RFC 6458 with Michael Tuexen, and he suggested posting the issue here for       further comment. The current language is vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. I've been advised that there is some disagreement about whether or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the proposed text attempts to avoid that issue.
>> 
>> OLD TEXT:

---

From: "Gorry (erg)" <[email-masked]>
Date: Fri, 13 Jan 2017 18:05:34 +0000

Is this somehow different to how you handle this in TCP? Maybe I missed something?

The RFC is informational, so I am not sure how important it is to make this change ... but I would be interested in other opinions... do speak up on the list if you think this is important.

Gorry

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 13 Jan 2017 19:49:11 +0100

> On 13 Jan 2017, at 19:05, Gorry (erg) <[email-masked]> wrote:
> 
TCP only allows to bind to a single address. MP-TCP allows to bind multiple addresses,
but I'm not sure about the API they are using.

The point is that sctp_bindx(), at least on FreeBSD, supports a mixture of
sockaddr_in and sockaddr_in6 structures. Other platforms might only support
sockaddr_in6 structures.

Best regards
Michael

---

From: "Jonathan T. Leighton" <[email-masked]>
Date: Fri, 13 Jan 2017 15:52:49 -0500

> Is this somehow different to how you handle this in TCP? Maybe I missed something?

It is not different, though at least one SCTP implementation allows a 
variation that is not normally available, and to the best of my 
knowledge is not available in any TCP implementation.

I think I should back up a bit and say that my original motivation for 
proposing an errata was this sentence in the description of sctp_bindx():

With the exception of one SCTP implementation, I know of no TCP or SCTP 
implementation that allows binding an IPv4 address to an IPv6 socket. 
Instead, IPv4-mapped IPv6 addresses are used. Given that I have 
encountered a good bit of confusion in some quarters about the different 
ways to translate IPv4 addresses to IPv6 (embedded, compatible, mapped, 
...), it seems to me that the RFC should explicitly mention that 
IPv4-mapped IPv6 addresses are the appropriate translation to use:

    If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses.
    Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.

It was pointed out to me that at least one SCTP implementation allows 
IPv4 addresses to be passed directly to sctp_bindx(), so the following 
change also seems appropriate:

    If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses.
    Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
    Note that some implementations optionally allow IPv4 addresses to be
    passed in directly.

I can explain why I originally suggested a wordier version that mentions 
the various structures involved if anyone is interested, but the above 
text is what I'd most like to see.

Best regards,
Jon

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 14 Jan 2017 11:08:56 +0100

> On 13 Jan 2017, at 21:52, Jonathan T. Leighton <[email-masked]> wrote:
> 
> It is not different, though at least one SCTP implementation allows a variation that is not normally available, and to the best of my knowledge is not available in any TCP implementation.
What system call used by TCP has *multiple* IP addresses as a parameter?

Best regards
Michael
> 
> I think I should back up a bit and say that my original motivation for proposing an errata was this sentence in the description of sctp_bindx():
> With the exception of one SCTP implementation, I know of no TCP or SCTP implementation that allows binding an IPv4 address to an IPv6 socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I have encountered a good bit of confusion in some quarters about the different ways to translate IPv4 addresses to IPv6 (embedded, compatible, mapped, ...), it seems to me that the RFC should explicitly mention that IPv4-mapped IPv6 addresses are the appropriate translation to use:
> It was pointed out to me that at least one SCTP implementation allows IPv4 addresses to be passed directly to sctp_bindx(), so the following change also seems appropriate:
> I can explain why I originally suggested a wordier version that mentions the various structures involved if anyone is interested, but the above text is what I'd most like to see.
> 
> Best regards,
> Jon
> 
>> On 12 Jan 2017, at 20:00, Michael Tuexen 
>> <[email-masked]>
>>  wrote:
>> 
>> 
>>>> I posted this to 
>>>> [email-masked]
>>>>  on 1/4/17, but it's been over a week now and I haven't had any response. I can try posting it again, or I can submit an errata and see how the authors respond. Do you have a suggestion about how best to proceed?
>>>>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 14 Jan 2017 10:45:11 +0000

Is this then about recognising that the address format is IPv6...?  and 
if so, is the correction along the lines of (with appropriate wording of 
course):

OLD:
If the sd is an IPv6 socket, the addresses passed can either be IPv4 or 
IPv6 addresses.

NEW:

If the sd is an IPv6 socket, the addresses passed can be either IPv6 addresses
or IPv4-Compatible IPv6 addresses (RFC 4291).

Gorry

On 14/01/2017 10:08, Michael Tuexen wrote:
>> On 13 Jan 2017, at 21:52, Jonathan T. Leighton<[email-masked]>  wrote:
>>
>>>>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton<[email-masked]>
>>>>>   wrote:
>>>>>
>>>>> Hi Michael -
>>>>>
>>>>> I posted this to
>>>>> [email-masked]

---

From: "Jonathan T. Leighton" <[email-masked]>
Date: Sat, 14 Jan 2017 14:31:54 -0500

> What system call used by TCP has *multiple* IP addresses as a parameter?

I think we interpreted Gorry's question differently. I was not referring 
to the ability to bind to multiple addresses. I was referring to how 
IPv4 and Ipv6 addresses are bound to IPv6 sockets. For both TCP and 
SCTP, IPv4 address must be translated to IPv4-mapped IPv6 addresses. 
FreeBSD's sctp_bindx() implementation is an exception to that.

Best regards,
Jon

---

From: "Jonathan T. Leighton" <[email-masked]>
Date: Sat, 14 Jan 2017 15:01:45 -0500

On 1/14/17 5:45 AM, Gorry Fairhurst wrote:
> if so, is the correction along the lines of (with appropriate wording 
> of course):
>
> OLD:

Yes - for me this is about recognizing that the address format is IPv6, 
but I think it should also mention that some implementations may allow 
the IPv4 format.

I would not use the term IPv4-Compatible IPv6 address since it's not the 
right format for binding, and because per RFC 4291 that type of address 
has been deprecated (sec. 2.5.5.1). RFC 4291 defines the IPv4-mapped 
IPv6 address and refers to RFC 4038 for a description of its use with 
IPv6 applications.

Best regards,
Jon

>>> It is not different, though at least one SCTP implementation allows 
>>> a variation that is not normally available, and to the best of my 
>>> I think I should back up a bit and say that my original motivation 
>>> for proposing an errata was this sentence in the description of 
>>> sctp_bindx():
>>> With the exception of one SCTP implementation, I know of no TCP or 
>>> SCTP implementation that allows binding an IPv4 address to an IPv6 
>>> socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I 
>>> have encountered a good bit of confusion in some quarters about the 
>>> different ways to translate IPv4 addresses to IPv6 (embedded, 
>>> compatible, mapped, ...), it seems to me that the RFC should 
>>> explicitly mention that IPv4-mapped IPv6 addresses are the 
>>> appropriate translation to use:
>>> It was pointed out to me that at least one SCTP implementation 
>>> allows IPv4 addresses to be passed directly to sctp_bindx(), so the 
>>> following change also seems appropriate:
>>> I can explain why I originally suggested a wordier version that 
>>> mentions the various structures involved if anyone is interested, 
>>> but the above text is what I'd most like to see.
>>>
>>> Best regards,
>>> Jon
>>>
>>>> The RFC is informational, so I am not sure how important it is to 
>>>> make this change ... but I would be interested in other opinions... 
>>>> do speak up on the list if you think this is important.
>>>>
>>>> Gorry
>>>>
>>>>>>   on 1/4/17, but it's been over a week now and I haven't had any 
>>>>>> response. I can try posting it again, or I can submit an errata 
>>>>>> and see how the authors respond. Do you have a suggestion about 
>>>>>> how best to proceed?
>>>>>>
>>>>>>> description in RFC 6458 with Michael Tuexen, and he suggested 
>>>>>>> posting the issue here for       further comment. The current 
>>>>>>> language is vague regarding passing IPv4 addresses versus 
>>>>>>> IPv4-mapped IPv6 addresses, as well as required versus allowed 
>>>>>>> behavior. I've been advised that there is some disagreement 
>>>>>>> about whether or not the term "IPv4 address" includes 
>>>>>>> IPv4-mapped IPv6 address, so the proposed text attempts to avoid 
>>>>>>> that issue.
>>>>>>>
>>>>>>> OLD TEXT:

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 15 Jan 2017 10:10:31 +0100

> On 14 Jan 2017, at 20:31, Jonathan T. Leighton <[email-masked]> wrote:
> 
> I think we interpreted Gorry's question differently. I was not referring to the ability to bind to multiple addresses. I was referring to how IPv4 and Ipv6 addresses are bound to IPv6 sockets. For both TCP and SCTP, IPv4 address must be translated to IPv4-mapped IPv6 addresses. FreeBSD's sctp_bindx() implementation is an exception to that.
I agree to that. But this doesn't affect TCP.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 15 Jan 2017 10:12:41 +0100

> On 14 Jan 2017, at 11:45, Gorry Fairhurst <[email-masked]> wrote:
> 
> Is this then about recognising that the address format is IPv6...?  and if so, is the correction along the lines of (with appropriate wording of course):
> 
> OLD:
> If the sd is an IPv6 socket, the addresses passed can either be IPv4 or IPv6 addresses.
> 
> NEW:
> 
The point I wanted to allow that for sctp_bindx() you can also provide a mixture
of struct sockaddr_in and struct sockaddr_in6 structures. This is allowed in FreeBSD.
Your suggested test would not allow this.

Best regards
Michael

---

From: Ka-Cheong Poon <[email-masked]>
Date: Mon, 16 Jan 2017 16:55:24 +0800

> I'm find with the text suggested by you.

The changes look fine to me too.  Thanks.

-- 
K. Poon
[email-masked]

---

From: "Jonathan T. Leighton" <[email-masked]>
Date: Tue, 17 Jan 2017 14:29:19 -0500

On 1/16/17 3:55 AM, Ka-Cheong Poon wrote:
>>> I posted this to [email-masked] on 1/4/17, but it's been over a week 
>>> now and I haven't had any response. I can try posting it again, or I 
>>> can submit an errata and see how the authors respond. Do you have a 

Can you clarify whether you're referring to this version of the proposed 
change:

    NEW TEXT:

or this version:

    NEW TEXT:
    If sd is an IPv4 socket, the passed addresses must be IPv4 addresses.
    If sd is an IPv6 socket, the passed addresses must be IPv6 addresses.
    Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
    Note that some implementations optionally allow IPv4 addresses to be
    passed in directly.

Thanks very much,
Jon

>>>> posting the issue here for further comment. The current language is 
>>>> vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 
>>>> addresses, as well as required versus allowed behavior. I've been 
>>>> advised that there is some disagreement about whether or not the 
>>>> term "IPv4 address" includes IPv4-mapped IPv6 address, so the

---

From: "Jonathan T. Leighton" <[email-masked]>
Date: Fri, 27 Jan 2017 16:18:36 -0500

> The changes look fine to me too.  Thanks.

If there are no more comments, I will submit at errata.

- Jon