Hi,
I was thinking of another alternative design (well, it's a small modification
of a current one). Instead of defining IP4_ONLY_ALLOWED and IP6_ONLY_ALLOWED,
define IP4_ALLOWED and IP6_ALLOWED. The semantics would be a positive
assertion that this particular AF allowed, without any concerns with the other
AF.
In this case, the behavior would be as follows:
Requested @Init Supported @Resp Assigned Returned Notification
IPv4 IPv6 None
IP6_ALLOWED
IPv6 IPv6 IPv6
IP6_ALLOWED
IPv6 IPv4 None
IP4_ALLOWED
IPv4 IPv4 IPv4
IP4_ALLOWED
IPv4 and IPv6 IPv6 IPv6 IP6_ALLOWED
IPv4 and IPv6 IPv4 IPv4 IP4_ALLOWED
IPv4 and IPv6 IPv6 or IPv4 IPv6 or IPv4 IP4_ALLOWED,
(Policy-based) IP6_ALLOWED
IPv4 and IPv6 IPv6 and IPv4 IPv6 and IPv4 IP4_ALLOWED,
IP6_ALLOWED
An (mostly theoretical) advantage of this design is that if some new AF appears
(well, I understand that it's unlikely in the foreseen future, but who knows),
the design will work w/o changes, we only need to define a new <AF>_ALLOWED
notification.
Regards,
Valery.
> In the Prague meeting we had two options how to send information what
> kind of address families are supported [1]:
>
> 1) IP6_ONLY_ALLOWED and IP4_ONLY_ALLOWED status notifications which
> are sent whenever only one address family is supported. I.e., if
> only one address family is supported, then IP*_ONLY_ALLOWED is
> sent. If both address families are supported, then no status code
> is sent. This is what current draft proposes.
>
> 2) ADDITINAL_ADDRESS_FAMILY_POSSIBLE status notification which is used
> when other address family than currently returned could also be
> used. I.e., if no address was assigned, then this status
> notification tells that trying with other address family works, and
> if address was assigned from one address family this tells that
> another request with another address family can also work.
>
> In the meeting we did not have clear concensus [2] on which of them
> are better. The option 2 is closer to what we currently have in
> RFC7296 for ADDITIONAL_TS_POSSIBLE.
>
> Both of the options seems to work, and I think people think the
> differences are so small, that they do not care. So unless people
> object soon, I think we will keep whatever is in the draft, as I
> seemed to be only one who thought the other option would be clearer.
>
> [1] See slides 6 and 7 of
>
> https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-chair-slides-04
> [2] https://datatracker.ietf.org/doc/minutes-104-ipsecme/
> --
> [email protected]
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
