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

["Valery Smyslov" <[e-mail]>]

Hi Paul,

> 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.

That would make sending these notifies dependent on the content of request.
So, the tradeoff is whether saving eight bytes justifies complication of state machine.

Regards,
Valery.

> 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