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

[<[e-mail]>]

Hi Paul, 

The responder does not know if the initiator is dual-stack or not. For example, an initiator can be instructed by policy to make use of separate requests. 

The returned notification code(s) will drive the subsequent of the initiator: ask for an additional AF, for example.  

Blindly returning the notification simplifies the behavior at the responder and optimizes the load on the server in some cases (e.g., IPv6-only responder receiving a subsequent request for IPv4). 

Cheers,
Med

> -----Message d'origine-----
> De : IPsec [mailto:[e-mail]] De la part de Paul Wouters
> Envoyé : lundi 29 avril 2019 18:11
> À : Valery Smyslov
> Cc : [e-mail]; Tero Kivinen
> Objet : Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
> 
> 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
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec