Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes

[Paul Wouters <[e-mail]>]

I would prefer no notify if the request was fulfilled and to only send a notify if a request could not be fulfilled. Since clients can ask for both that should cover things. If a client isn’t asking for ipvX, I see no need to answer that ipvX is supported too.

Paul

Sent from mobile device

> On Apr 17, 2019, at 03:48, Valery Smyslov <[e-mail]> wrote:
> 
> 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/
>> --
>> [e-mail]
>> 
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec