[shara] draft-thaler-port-restricted-ip-issues-00 - A+P tunneling

[Rémi Després <[e-mail]>]

Dave,

1.
Thanks first for the fairness of the conclusion:
"It is possible that the same state benefits motivating the concept of port-restricted IP addresses may be possible in other approaches that do not involve assigning a port-restricted IP address to an interface, but this investigation is left to other documents."
(This is IMHO much better than the impression left in Hiroshima, after the Shara bof, that any A+P would necessarily be evil.)

2.
This sentence is important because, in several proposals, e2e A+P packets traverse domains where their exits depend on A+P via tunnels, with IP over IP encapsulations. 
Destinations of encapsulating packets are then in local address spaces (not in A+P spaces).
Thus, shared IPv4 addresses need not be assigned to any interface where ARP is applicable. 

3.
At the bottom of page 5, where you discuss the relationship between socket binds and roaming, you note that, if an application that accepts incoming connections doesn't care about its IP address but cares about its port, it may have problems in roaming scenarios.
In my understanding, this roaming application would have similar problems where service-provider-NATs have to be traversed. 
This issue being inherent to address sharing, it should be considered IMHO out of the scope of this draft.

4.
In page 6, you note that non-port-based protocols, ICMP in particular, can still be used with private addresses between two hosts behind the same NAT, and suggest that this is not possible where A+P is used. 
If A+P packets are locally encapsulated over private-address IPv4 (see point 2 above), this remains possible. 

5.
At the bottom of page 6, you suggest that complex evolutions of provisioning and management tools would be unavoidable.
If assigned port sets are algorithmically derived from addresses that are otherwise assigned (or some prefixes), this can be avoided. 
In my understanding, provisioning is in this case as simple as that of adding IPv6 to IPv4 with 6to4, ISATAP or 6rd.)  


To conclude, I look forward to a fair checking, with you if you are interested, of which problems would remain with the A+P part of the updated SAM proposal (in draft-despres-softwire-sam-00). 

Regards,
RD