Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

[Richard Patterson <[e-mail]>]

I'd like to reword the UPnP section to shift the focus a bit.  The content
is largely the same, but it should now highlight that UPnP SHOULD be
disabled when implementing an IPv4aaS mechanism, with exceptions for the
stateless methods, and when configured with an address sharing ratio of 1.

I also received some off-list comments about how the CE landscape hasn't
really changed and embraced the IGD:2 specs yet.  This is unfortunate as it
means they also lack the AddPinhole() function to manipulate the native
IPv6 firewall, although that's off topic for this draft.
So with that in mind, and following on from Med's comments, I'd like to
also add a SHOULD support the IGD:2 specs, if a CE chooses to implement
UPnP.


New proposed wording for §5:

"""
5. UPnP Support   (Removed "IGD-PCP IWF")

UPnP SHOULD be disabled by default on the CE Router when using an IPv4aaS
transition mechanism.

UPnP MAY be enabled when a CE is configured to use a stateless IPv4aaS
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 a CE, the UPnP agent MUST reject any port mapping
requests for ports outside of the port set allocated to the CE Router.

UPnP MAY also be enabled on a CE 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].

A CE that implements a UPnP agent, SHOULD support the Open Connectivity
Foundation's IGD:2 specification, including the AddAnyPortMapping()
function.
"""
On Fri, 27 Apr 2018 at 13:46, Richard Patterson <[e-mail]>
wrote:

> On Fri, 27 Apr 2018 at 13:03, <[e-mail]> wrote:

> > I know some applications are still using IGD:1, but I hope they will
move
> to the IGD:2.

> When I was testing this nearly 4 years ago, I struggled to find CPEs with
> IGD:2 support.  Hopefully the landscape has changed now that IGD:1 has
been
> deprecated.
> But then as you say, we still need the applications to update their
> behaviour and adopt the looser AddAnyPortMapping() instead of the more
> specific AddPortMapping()

> I'd be more confident in RFC6970 as a useful mitigation then.

> -Rich