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

Hi Velery, 

Works for me. Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : IPsec [mailto:ipsec-bounces@ietf.org] De la part de Valery Smyslov
> Envoyé : mercredi 17 avril 2019 09:48
> À : 'Tero Kivinen'; ipsec@ietf.org
> Objet : Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
> 
> 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/
> > --
> > kivinen@iki.fi
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec