[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes
From: Daniel Migault <daniel.migault () ericsson ! com>
Date: 2018-10-19 10:28:23
Message-ID: CADZyTkmdn8XJH4HDefbFQsoMy573=ByApWggZsZeEv4U5g5ntA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
+1, there seems a problem to solve, so I support the adoption.
The question I would raise are:
* Do we want to add code and update IKEv2 or do we want to define an
extension with IP46_SUPPORTED. For interoperability, the latest may be
preferred.
* Looking at the code points, I have the impression that with the current
signaling, only the case where a single af is supported could be ambiguous.
A host sending a request for IP4 and IP6 addresses, can easily deduce is
which are the supported AF, except when the a single AF is supported. In
that case maybe the IP6 should be provided with the notification ,in case
the host really wants a IP4 address.
* While 3gpp use case is sufficient, I am wondering if we have use cases
outside 3gpp where such extension is needed ?
Of course these could be discussed after adoption.
Yours,
Daniel
On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly <tpauly@apple.com> wrote:
> Agreed with Valery that this is a fine starting point to define the
> problem, but we will need to iterate on the details.
>
> I do support adoption.
>
> Thanks,
> Tommy
>
> > On Oct 16, 2018, at 11:59 PM, Valery Smyslov <smyslov.ietf@gmail.com>
> wrote:
> >
> > Hi,
> >
> > after reading the draft's introduction, I think the problem described
> > is real. So I support adoption of this draft.
> >
> > That said, it seems that the current draft solves the problem in
> > suboptimal way (too many new notifications defined), but that
> > can be definitely discussed in the WG. And yes, I'm ready to
> > review the draft.
> >
> > Regards,
> > Valery.
> >
> >> 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/
> >> --
> >> 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
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>+1, there seems a problem to solve, so I support the \
adoption.<br></div><div><br></div><div>The question I would raise are:</div><div>* Do \
we want to add code and update IKEv2 or do we want to define an extension with \
IP46_SUPPORTED. For interoperability, the latest may be preferred. <br></div><div>* \
Looking at the code points, I have the impression that with the current signaling, \
only the case where a single af is supported could be ambiguous. A host sending a \
request for IP4 and IP6 addresses, can easily deduce is which are the supported AF, \
except when the a single AF is supported. In that case maybe the IP6 should be \
provided with the notification ,in case the host really wants a IP4 address. \
<br></div><div>* While 3gpp use case is sufficient, I am wondering if we have use \
cases outside 3gpp where such extension is needed ?</div><div><br></div><div>Of \
course these could be discussed after adoption.</div><div> <br></div><div>Yours, \
<br></div><div>Daniel<br></div></div><br><div class="gmail_quote"><div dir="ltr">On \
Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly <<a \
href="mailto:tpauly@apple.com">tpauly@apple.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Agreed with Valery that this is a fine starting point to \
define the problem, but we will need to iterate on the details. <br> <br>
I do support adoption. <br>
<br>
Thanks,<br>
Tommy <br>
<br>
> On Oct 16, 2018, at 11:59 PM, Valery Smyslov <<a \
href="mailto:smyslov.ietf@gmail.com" target="_blank">smyslov.ietf@gmail.com</a>> \
wrote:<br> > <br>
> Hi,<br>
> <br>
> after reading the draft's introduction, I think the problem described<br>
> is real. So I support adoption of this draft.<br>
> <br>
> That said, it seems that the current draft solves the problem in <br>
> suboptimal way (too many new notifications defined), but that<br>
> can be definitely discussed in the WG. And yes, I'm ready to <br>
> review the draft.<br>
> <br>
> Regards,<br>
> Valery.<br>
> <br>
>> Our new charter has been approved and that includes item:<br>
>> <br>
>> RFC7296 defines a generic notification code that is related to a<br>
>> failure to handle an internal address failure. That code does not<br>
>> explicitly allow an initiator to determine why a given address<br>
>> family is not assigned, nor whether it should try using another<br>
>> address family. The Working Group will specify a set of more<br>
>> specific notification codes that will provide sufficient<br>
>> information to the IKEv2 initiator about the encountered failure.<br>
>> A possible starting pointing is<br>
>> draft-boucadair-ipsecme-ipv6-ipv4-codes.<br>
>> <br>
>> So this email will start one week long WG adoptation call for that<br>
>> document [1] for WG adoptation.<br>
>> <br>
>> Send your comments to this list before the 2018-10-21.<br>
>> <br>
>> [1] <a href="https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/" \
rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/</a><br>
>> --<br>
>> <a href="mailto:kivinen@iki.fi" target="_blank">kivinen@iki.fi</a><br>
>> <br>
>> _______________________________________________<br>
>> IPsec mailing list<br>
>> <a href="mailto:IPsec@ietf.org" target="_blank">IPsec@ietf.org</a><br>
>> <a href="https://www.ietf.org/mailman/listinfo/ipsec" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipsec</a><br> > <br>
> _______________________________________________<br>
> IPsec mailing list<br>
> <a href="mailto:IPsec@ietf.org" target="_blank">IPsec@ietf.org</a><br>
> <a href="https://www.ietf.org/mailman/listinfo/ipsec" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipsec</a><br> <br>
_______________________________________________<br>
IPsec mailing list<br>
<a href="mailto:IPsec@ietf.org" target="_blank">IPsec@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/ipsec" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipsec</a><br> \
</blockquote></div>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic