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

[<[e-mail]>]

Hi,

Thank you Dave for comments, my replies inline:

>-----Original Message-----
>From: ext Dave Thaler [mailto:[e-mail]] 
>Sent: 06 November, 2008 21:30
>
>Like other port range approaches, this breaks applications 
>when a host (as opposed to a NAT) is directly connected to the 
>provider.

I don't see reasons why existing applications would be worse off than in
ordinary NAT44 case (when host implements internal NAT), but modified
apps could be better off by having at least restricted access on public
IPv4 address instead of just RFC1918 address.

Our approach suggests that network would not allocate port restricted
addresses for hosts (or CPEs) not indicating required support.

>> 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).

How this breaks applications more than IPv4 NAPT? The host internal NAT
is intended to be the way to accommodate these legacy applications,
which anyhow would have to manage with private IPv4 addresses in such
networks that are short of public IPv4 addresses (and which don't
necessarily have all ALGs in CGN).

>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).

There certainly are different implementation restrictions and options on
different OSes.

IMHO majority of current and future Internet users should not never
see/hear about concept of network interfaces. Anyhow, one implementation
option in that case would not to show the port-restricted IP address on
UI as a network interface at all, but instead just show the internally
NATted interface that is showing private IPv4 address. That should look
exactly as it looks today for users, but instead of NATting being done
in CGN (or CPE) it would be done in host's own stack.

To enable application developers ways to improve their software, the the
hosts' APIs should allow the modified apps to directly utilize the
public but port-restricted addresses for NAT-less communication. Perhaps
some network interfaces could be seen by apps but not end users?

>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.

I don't understand this comment, I think. Our approach is especially to
made directly attached (new) hosts better off by getting rid of all NATs
between a host and Internet. 

In our proposal hosts capable of supporting port-restricted addresses
specifically indicate it so that the network can continue giving public
or RFC1918 addresses for those hosts that do not support port-restricted
addresses.

Ensuring correct behaviour of hosts can be done in fully managed
networks, via network operator vendor requirement procedures, via
specifications of SDOs like 3GPP/WiMAX forum, or as last resort
forcefully by the network (that would give port-restricted address with
which hosts either manage or don't).

>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.

True, there are issues that need to be studied further. For these kinds
of reasons we recommend this solution to be used only in selected
network setups such as with point-to-point links (physical or tunneled)
where ARP is not used and e.g. PING can be done within underlying IPv6
layer or by link layer specific means.

>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.

I agree that more work on comparison should be done.

>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.

With our approach also public IPv4 address is allocated to a host (with
restrictions), while in NAT-PMP and UPnP IGD cases private IPv4
addresses are used afaik? Another aspect is that if CGN is used, it most
probably does not support NAT-PMP or UPNP IGD usage at all, and even
local NAT is probably having keep-alive timers running that need to be
refreshed with battery-consuming keep-alive messages.

>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?

By not sending OPTION-IPv4-RPR host would get just RFC1918 address at
best, and thus NATted Internet access, while with OPTION-IPv4-PRP it
could get public - but partial - address.

For managed clients another SDO or network operator could require
OPTION-IPv4-RPR/OPR support. Thus the incentive for vendor is to
implement that in order to get sales.

For managed legacy or new unmanaged clients the network operator can
continue allocating public or RFC1918 addresses as long as network
operator just has some available in pool. 

Say an operator has limited pool of public IPv4 addresses available -
the more there are new hosts on the network capable of asking/living
with port restricted IPv4 addresses, the longer the public IPv4 address
pool will last from where other hosts can be served (or at least higher
number of hosts can be provided with non-NATted IPv4 connectivity).

With all the restrictions and assumptions I think it is clear that our
solution is far from perfection, but we believe that IPv4-communication
needs of large number of simpler hosts (say basic cellular devices)
could be accommodated with this kind of approach, while doing so
conserving IPv4 address pool, decreasing need for NAT traversal
technologies, and illustrating benefits of moving to IPv6.

Best regards,

	Teemu
_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave