Subject: [IPsec] Yoav's Comments (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes)

From: <[email-masked]>
Date: Thu, 18 Oct 2018 09:49:33 +0000

Hi Yoav, 

Can you please clarify which "stuff" in 5739 you are referring to? 

The draft updates RFC7296 because it updates the behavior specified in Section 3.15.4 of that RFC. 

Cheers,
Med

> -----Message d'origine-----
> De : IPsec [mailto:[email-masked]] De la part de Yoav Nir
> Envoyé : samedi 13 octobre 2018 15:48
> À : Tero Kivinen
> Cc : [email-masked]
> Objet : Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-
> ipv4-codes
> 
> I believe the final document should address the stuff in RFC 5739. Also, I’m
> not sure you need to update 7296 to add some new code points.
> 
> Neither of these is a barrier for adoption.
> 
> I have read the draft and support its adoption.
> 
> Yoav
> 
> > On 13 Oct 2018, at 3:09, Tero Kivinen <[email-masked]> wrote:
> >
> > Our new charter has been approved and that includes item:
> >
> >    RFC7296 defines a generic notification code that is related to a
> >    failure to handle an internal address failure. That code does not
> >    explicitly allow an initiator to determine why a given address
> >    family is not assigned, nor whether it should try using another
> >    address family. The Working Group will specify a set of more
> >    specific notification codes that will provide sufficient
> >    information to the IKEv2 initiator about the encountered failure.
> >    A possible starting pointing is
> >    draft-boucadair-ipsecme-ipv6-ipv4-codes.
> >
> > So this email will start one week long WG adoptation call for that
> > document [1] for WG adoptation.
> >
> > Send your comments to this list before the 2018-10-21.
> >
> > [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-
> codes/
> > --
> > [email-masked]
> >
> > _______________________________________________
> > IPsec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 18 Oct 2018 20:10:30 +0300

Hi.

RFC 7296 has the INTERNAL_ADDRESS_FAILURE notification as optional — gateways are free to just ignore the requests. However, having read 3.15.4 again, I see that the text does say “If the responder encounters an error while attempting to assign an IP address to the initiator during the processing of a Configuration payload, it responds with an INTERNAL_ADDRESS_FAILURE notification.”.  So I’m convinced. It does need to update 7296.

About RFC 5739, at the top of page 3 (and other places) of your draft you mention the initiator requesting IPv6 prefix(es). Requesting IPv6 prefixes is defined in RFC 7539, which concludes that the way this is defined in 3406 (the predecessor of 7296) doesn’t work. I think 5739 should be referenced as informative.

Yoav

> On 18 Oct 2018, at 12:49, [email-masked] wrote:
> 
> Hi Yoav, 
>

---

From: <[email-masked]>
Date: Fri, 19 Oct 2018 05:59:18 +0000

Hi Yoav, 

Thank you. 

Please see inline.

Cheers,
Med

> De : Yoav Nir [mailto:[email-masked]]
> Envoyé : jeudi 18 octobre 2018 19:11
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]
> Objet : Re: Yoav's Comments (was RE: [IPsec] Call for WG Adoptation for
> draft-boucadair-ipsecme-ipv6-ipv4-codes)
> 
> Hi.
> 
> RFC 7296 has the INTERNAL_ADDRESS_FAILURE notification as optional — gateways
> are free to just ignore the requests. However, having read 3.15.4 again, I
> see that the text does say “If the responder encounters an error while
> attempting to assign an IP address to the initiator during the processing of
> a Configuration payload, it responds with an INTERNAL_ADDRESS_FAILURE
> notification.”.  So I’m convinced. It does need to update 7296.

[Med] OK.

> 
> About RFC 5739, at the top of page 3 (and other places) of your draft you
> mention the initiator requesting IPv6 prefix(es). Requesting IPv6 prefixes is
> defined in RFC 7539, which concludes that the way this is defined in 3406
> (the predecessor of 7296) doesn’t work. I think 5739 should be referenced as
> informative.
> 

[Med] Requesting an IPv6 prefix is possible with RFC7296. It is true that an experimental RFC defines another way to proceed, but RFC5739 is already cited in RFC7296. As such, we don’t need IMO to repeat it here because, otherwise, we will need to add a similar note:

==
   Note that there is an additional document that discusses IPv6
   configuration in IKEv2, [IPV6CONFIG].  At the present time, it is an
   experimental document, but there is a hope that with more
   implementation experience, it will gain the same standards treatment
   as this document.
==