Subject: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes (too many codes)

From: Daniel Migault <[email-masked]>
Date: Wed, 7 Nov 2018 04:51:01 -0500

Hi,

One of the comment was the number of AF failure error. I think Med already
answered this comment [1], see the question/answer below. If that does not
address the question raised today, please describe how the number could be
reduced.

Please also state whether we should use one status code for all AF failure
error versus one status code per AF failure error. I think the WG preferred
the latest alternative.

Yours
Daniel

[1] https://mailarchive.ietf.org/arch/msg/ipsec/3DM_MzLmG-JYKGbA15siCkJbqV8
"""

* Looking at the code points, I have the impression that with the current
signaling, only the case where a single af is supported could be ambiguous.
A host sending a request for IP4 and IP6 addresses, can easily deduce is
which are the supported AF, except when the a single AF is supported.

[Med] There are cases where both AFs are supported, but only an
address/prefix can be returned. Which address is returned is policy-based.
An initiator which does not get an address family type does not know
whether it didn’t get the requested AF because (1) it is not supported or
(2) because of a policy. The behavior of the initiator may change as
function of this.

For example, if it really needs an IPv4, but gets an IPv6 prefix, it
will need to issue a request in which only INTERNAL_IP4_ADDRESS will
be included and so on.

"""

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 7 Nov 2018 23:24:21 +0700

Hi Daniel,

it was me who made this comment. The current number of notifications seems to be excessive for

the task. Not that I'm all that greedy (also Occam razor has been sitting sitting in my mind), 

but the current design makes implementation more complex then it could be.

You have a separate notification for each possible situation. That makes the responder

think before returning back a "proper" answer. But actually, most of these different

notifications return exactly the same two bit of information - which address families are supported 

by the server (or allowed by its policy). Moreover, this two bits of information are mostly static! 

So, what design I would have preferred? Two notifications are enough - SUPPORTED_AF (containing

some data indicating which AFs are supported) and SINGLE_AF_SUPPORTED. If you don't like

notification data, then three notifications are enough - IP4_AF_SUPPORTED, IP6_AF_SUPPORTED

and SINGLE_AF_SUPPORTED. Note that I changed meaning from negative to positive, that is 

more appropriate for status type notification and also makes it possible to easy extend 

protocol in case a new fictional AF appears in future.

In this case the server can make an assignment of the IP addresses decoupled from

the returned notifications, which in this case become almost static: you can _always_

return corresponding IP*_AF_SUPPORTED (either one of them or both) regardless of whether

you assigned IPs or not and which AF you assigned. That makes server implementation simpler. 

The only case when server need to return more is the 4th case, when it would in addition send 

SINGLE_AF_SUPPORTED (actually it is not all that needed and the client can easily deduce it, 

but let's make his life simpler).

This is mostly ad hoc design, it can definitely be discussed.

Regards,

Valery.

Hi, 

One of the comment was the number of AF failure error. I think Med already answered this comment [1], see the question/answer below. If that does not address the question raised today, please describe how the number could be reduced.

Please also state whether we should use one status code for all AF failure error versus one status code per AF failure error. I think the WG preferred the latest alternative.

Yours 

Daniel

"""

* Looking at the code points, I have the impression that with the current signaling, only the case where a single af is supported could be ambiguous. A host sending a request for IP4 and IP6 addresses, can easily deduce is which are the supported AF, except when the a single AF is supported. 

[Med] There are cases where both AFs are supported, but only an address/prefix can be returned. Which address is returned is policy-based. An initiator which does not get an address family type does not know whether it didn’t get the requested AF because (1) it is not supported or (2) because of a policy. The behavior of the initiator may change as function of this. 

For example, if it really needs an IPv4, but gets an IPv6 prefix, it will need to issue a request in which only INTERNAL_IP4_ADDRESS will be included and so on.   

"""

---

From: <[email-masked]>
Date: Wed, 7 Nov 2018 17:56:50 +0000

Hi Valery,

Thank you for elaborating.

Please see inline.

Cheers,
Med

De : IPsec [mailto:[email-masked]] De la part de Valery Smyslov
Envoyé : mercredi 7 novembre 2018 17:24
À : 'Daniel Migault'; 'IPsecME WG'
Objet : Re: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes (too many codes)

Hi Daniel,

and SINGLE_AF_SUPPORTED.

[Med] I’d prefer to avoid notification data, so I will consider the three notifications approach.

Note that I changed meaning from negative to positive, that is
more appropriate for status type notification and also makes it possible to easy extend
protocol in case a new fictional AF appears in future.

[Med] I do prefer to make it explicit, hence the maintain of SINGLE_AF_SUPPORTED.

Regards,
Valery.

Hi,

Yours
Daniel