Subject: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 09 Aug 2018 10:03:16 -0500

Hi Richard, Barbara,

Thanks and sorry, I'm late reacting to this, working in a new version during the weekend, following Ron advise, in order to go for a last-call.

Let me try to summarize what you are saying with a proposed text (basic idea, remove superfluous text and only state what may be not obvious for an implementor, that already must know about UPnP and has read the rest of the document ...). Let me know if I missed anything:

Actual text:

5.  UPnP Support

   UPnP SHOULD be disabled by DEFAULT on the IPv6 Transition CE Router

   when using an IPv4aaS transition mechanism.

   UPnP MAY be enabled when an IPv6 Transition CE Router is configured

   to use a stateless mechanism that allows unsolicited inbound packets

   through to the CE, such as MAP or lw4o6, or when configured with a

   port set containing all 65535 ports, e.g., with an IPv4 address

   sharing ratio of 1.

   If UPnP is enabled on an IPv6 Transition CE Router, the UPnP agent

   MUST reject any port mapping requests for port numbers outside of the

   port set allocated to the IPv6 Transition CE Router.

   UPnP SHOULD also be enabled on an IPv6 Transition CE Router

   configured for IPv4aaS mechanisms that support PCP [RFC6887], if

   implemented in conjunction with a method to control the external port

   mapping, such as IGD-PCP IWF [RFC6970].

   An IPv6 Transition CE Router that implements a UPnP agent, SHOULD

   support the Open Connectivity Foundation's IGD:2 specification,

   including the AddAnyPortMapping() function.

New text:

5.  UPnP Support

If the [UPnP WANIPConnection:2] service is enabled on a CE router, 

but cannot be associated with an IPv4 interface established by an 

IPv4aas mechanism or cannot interwork with PCP or a configured 

port set, an AddPortMapping() or AddAnyPortMapping() action 

MUST be rejected with error code 729 "ConflictWithOtherMechanisms". 

Note that IGD:1 and its WANIPConnection:1 service have been 

deprecated by OCF.

Then, new informative reference for

[UPnP WANIPConnection:2] http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf

Is that right?

Regads,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de Richard Patterson <[email-masked]>

Fecha: martes, 24 de julio de 2018, 5:08

Para: <[email-masked]>

CC: "[email-masked] list" <[email-masked]>

Asunto: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05

    Hi Barbara,

    On Mon, 23 Jul 2018 at 18:09, STARK, BARBARA H <[email-masked]> wrote:

    > I think the proposed text is confusing and self-contradictory, needs to be more precise in language used around UPnP capabilities, and isn't the correct recommendation. Inline indication of where I see these problems, and proposed text at the bottom.

    Fair enough, I won't then try to justify any of my proposed text, but

    rather focus on your recommended text instead.

    I will say that the conflict/confusion was probably because it was

    intended to be read linearly as: "By default reject, unless......."

    > Here is what I would recommend:

    > If the [UPnP WANIPConnection:2] service is enabled on a CE router, but cannot be associated with an IPv4 interface established by an IPv4aas mechanism or cannot interwork with PCP or a configured port set, an AddPortMapping() or AddAnyPortMapping() action MUST be rejected with error code 729 "ConflictWithOtherMechanisms". Note that IGD:1 and its WANIPConnection:1 service have been deprecated by OCF.

    > I think that's all that needs to be said. Any properly interworked WANIPConnection:2 service can be expected to behave properly according to UPnP specs.

    > Then add informative reference to [UPnP WANIPConnection:2] that points to http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf.

    "interwork with [...]  a configured port set" is too vague for my

    liking.  It's not clear that this means it should reject

    AddPortMapping() requests for a port outside of the port set, or

    provide an alternative port when requested with AddAnyPortMapping().

    I'd like to see this elaborated a bit more on.

    Whilst IGD:1 is deprecated, it is what's out there so we need to make

    sure to capture the AddPortMapping() behaviour correctly.  Even when

    newer CPEs start supporting IGD:2 (most are still dragging their heals

    IME), it requires applications to also alter their behaviour to make

    use of the new AddAnyPortMapping() function.

    I do agree that the more concise wording is better, and that sections

    of the previously suggested wording were superfluous when read in

    context with the rest of the document.  Apologies for that.

    -Richard

    _______________________________________________

    v6ops mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 9 Aug 2018 20:07:04 +0000

> Hi Richard, Barbara,
> 
> Thanks and sorry, I'm late reacting to this, working in a new version during
> the weekend, following Ron advise, in order to go for a last-call.
> 
> Let me try to summarize what you are saying with a proposed text (basic
> idea, remove superfluous text and only state what may be not obvious for an
> implementor, that already must know about UPnP and has read the rest of
> the document ...). Let me know if I missed anything:
---------- snip ---------
> Note that IGD:1 and its WANIPConnection:1 service have been

I think Richard had some concerns with this language (which is the language I proposed). I went and found what Richard said:

<RP> "interwork with [...]  a configured port set" is too vague for my liking.  It's not clear that this means it should reject
AddPortMapping() requests for a port outside of the port set, or provide an alternative port when requested with AddAnyPortMapping().
I'd like to see this elaborated a bit more on.
Whilst IGD:1 is deprecated, it is what's out there so we need to make sure to capture the AddPortMapping() behaviour correctly.  Even when newer CPEs start supporting IGD:2 (most are still dragging their heals IME), it requires applications to also alter their behaviour to make use of the new AddAnyPortMapping() function.</RP>

To address Richard's first concern, perhaps replace "or cannot interwork with PCP or a configured port set" with "or cannot determine which ports are available (through PCP or access to a configured port set, if the IPvaas mechanism limits the available ports)".

To address AddPortMapping() failures, I suggest adding a sentence (before the last sentence) that says "An AddPortMapping() request for a port that is not available MUST result in "ConflictInMappingEntry."

Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 09 Aug 2018 15:23:13 -0500

Let's see if I got it right:

5.  UPnP Support

   If the UPnP WANIPConnection:2 service [UPnP-WANIPC] is enabled on a

   CE router, but cannot be associated with an IPv4 interface

   established by an IPv4aaS mechanism or cannot determine which ports

   are available (through PCP or access to a configured port set, if the

   IPv4aaS mechanism limits the available ports), an AddPortMapping() or

   AddAnyPortMapping() action MUST be rejected with error code 729

   "ConflictWithOtherMechanisms".

   An AddPortMapping() request for a port that is not available MUST

   result in "ConflictInMappingEntry".

   deprecated by OCF.

  [UPnP-WANIPC]

              UPnP Forum, "WANIPConnection:2 Service", December 2010,

              <http://upnp.org/specs/gw/

              UPnP-gw-WANIPConnection-v2-Service.pdf>.

Regards,

Jordi

-----Mensaje original-----

De: "STARK, BARBARA H" <[email-masked]>

Fecha: jueves, 9 de agosto de 2018, 15:07

Para: 'JORDI PALET MARTINEZ' <[email-masked]>, Richard Patterson <[email-masked]>

Asunto: RE: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05

    ---------- snip ---------

    Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 9 Aug 2018 20:37:03 +0000

Yes, that's what I propose. I think Richard needs to say whether it's ok for him.
Barbara

> -----Original Message-----
> From: JORDI PALET MARTINEZ <[email-masked]>
> Sent: Thursday, August 09, 2018 4:23 PM
> To: STARK, BARBARA H <[email-masked]>; Richard Patterson
> <[email-masked]>
> Cc: [email-masked] list <[email-masked]>
> Subject: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05
> 
>               <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__upnp.org_specs_gw_&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=CmzmuY2Q0p6D9X_YNCRHpi_vOIfUKT2-
> NOQOpPiiGkA&s=rfUcwYpw7g7vCTwVZw2C--Rd_kpNbG-bC3S7QIPXTSA&e=
> 
>     I think Richard had some concerns with this language (which is the language
> I proposed). I went and found what Richard said:
> 
> 
> 
>     <RP> "interwork with [...]  a configured port set" is too vague for my liking.
> It's not clear that this means it should reject
> 
>     AddPortMapping() requests for a port outside of the port set, or provide
> an alternative port when requested with AddAnyPortMapping().
> 
>     Whilst IGD:1 is deprecated, it is what's out there so we need to make sure
> to capture the AddPortMapping() behaviour correctly.  Even when newer
> CPEs start supporting IGD:2 (most are still dragging their heals IME), it
> requires applications to also alter their behaviour to make use of the new
> AddAnyPortMapping() function.</RP>
> 
> 
> 
>     To address Richard's first concern, perhaps replace "or cannot interwork
> with PCP or a configured port set" with "or cannot determine which ports are
> available (through PCP or access to a configured port set, if the IPvaas
> mechanism limits the available ports)".
> 
> 
> 
>     To address AddPortMapping() failures, I suggest adding a sentence (before
> the last sentence) that says "An AddPortMapping() request for a port that is
> not available MUST result in "ConflictInMappingEntry."
> 
> 
> 
>     Barbara
> 
> 
> 
> 
> 
> 
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.consulintel.es&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=CmzmuY2Q0p6D9X_YNCRHpi_vOIfUKT2-
> NOQOpPiiGkA&s=IDJhPoDrhX4vHSy6ZpJihjomtxX9VR8AHipKtz7sJMw&e=
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of the
> individual(s) named above and further non-explicilty authorized disclosure,
> copying, distribution or use of the contents of this information, even if
> partially, including attached files, is strictly prohibited and will be considered a
> criminal offense. If you are not the intended recipient be aware that any
> disclosure, copying, distribution or use of the contents of this information,
> even if partially, including attached files, is strictly prohibited, will be
> considered a criminal offense, so you must reply to the original sender to
> inform about this communication and delete it.
> 
>

---

From: Richard Patterson <[email-masked]>
Date: Tue, 14 Aug 2018 10:18:39 +0100

Hi Jordi, Barbara,

I think that satisfactorily covers the cases when both port mapping
functions must be rejected. I think, however, I'd still like to see a
small paragraph recommending a successful response to an
AddAnyPortMapping() request for an unavailable port.  Perhaps
something like:

 An AddPortMapping() request for a port that is not available SHOULD
result in a successful mapping with an alternative "NewReservedPort"
value from within the configured port set range, or as assigned by PCP
as per [RFC6970], Section 5.6.1.

-Richard
On Thu, 9 Aug 2018 at 21:23, JORDI PALET MARTINEZ

---

From: Richard Patterson <[email-masked]>
Date: Tue, 14 Aug 2018 14:26:23 +0100

Apologies, my proposed paragraph should say AddAnyPortMapping() not
AddPortMapping()
(I've updated the quote in this email)

On Tue, 14 Aug 2018 at 10:18, Richard Patterson <[email-masked]> wrote:
>  An AddAnyPortMapping() request for a port that is not available SHOULD

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 14 Aug 2018 13:49:01 +0000

> >  An AddAnyPortMapping() request for a port that is not available
> > SHOULD result in a successful mapping with an alternative
> "NewReservedPort"

WFM. 
Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 14 Aug 2018 09:46:34 -0500

Thanks a lot Richard/Barbara.

Then the final text for this section will be:

5.  UPnP Support

   "NewReservedPort" value from within the configured port set range, or

   as assigned by PCP as per [RFC6970], Section 5.6.1.

   deprecated by OCF.

I will wait a few hours before posting it, just in case we find anything else.

Regards,

Jordi

-----Mensaje original-----

Fecha: martes, 14 de agosto de 2018, 8:49

Para: 'Richard Patterson' <[email-masked]>, "[email-masked] list" <[email-masked]>

CC: JORDI PALET MARTINEZ <[email-masked]>

    WFM. 

    Barbara