[BEHAVE] Comments on draft-bajko-v6ops-port-restricted-ipaddr-assign-02.txt

Like other port range approaches, this breaks applications
when a host (as opposed to a NAT) is directly connected to the provider.

> This enables incremental deployment of modified
> hosts that are supporting public IPv4 address conservation by using
> DHCP port restricted IPv4 address assignment

It's not just host modifications, it can also break applications,
so you also have to modify all the legacy apps that break
(see draft-iab-ip-model-evolution-01.txt sections 3.2.3 and 3.3
for additional discussion/references).

Section 2.3 talks about creating a NAT in the host, but this means
that you have to hide the physical interface from the applications
and instead show them some virtual interface.  This causes
user confusion (as an aside, this is why virtual interfaces
like Teredo and 6to4 don't show up in the UI in Windows,
because feedback indicated it confuses users too much).

You'd be better off saying that this proposal is only applicable
to networks that don't allow hosts to directly attach to the network.

Furthermore, the use of port-restricted IP addresses prevents the
use of ping (e.g. the provider cannot ping a CPE) and other
protocols that don't use port numbers, including ARP.  I see
section 7 does say this.

It's not clear whether the pain is greater with this approach or
with double NAT'ed CGNs.  It would be useful for someone to
enumerate the pain with each in a single place and do a
comparison.

Section 3:

The concept of asking for one or more ports to be allocated, and an
externally visible address, seems to overlap to a large extent
with NAT-PMP in draft-cheshire-nat-pmp-03 (and work on UnP IGD v2
for that matter).  The main difference seems to be that this draft
asks for a range of ports, whereas NAT-PNP asks for one.

Section 4:

If the client can get a non-port-restricted IP by not changing,
what's the incentive for a client to change, since it only gets
worse behavior by sending an OPTION-IPv4-RPR?

-Dave Thaler
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave