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

From: Rémi Després <[email-masked]>
Date: Wed, 3 Mar 2010 18:46:27 +0100

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

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Mar 2010 04:40:45 +0900

Remi wrote:

> If A+P packets are locally encapsulated over private-address
> IPv4 (see point 2 above), this remains possible.

ICMP with PR-IP just works not because of your point 2, but because
of identifier and sequence number fields copied from request to reply
just as source and destination port numbers copied (in reverse order)
from request to reply.
							Masataka Ohta

---

From: Rémi Després <[email-masked]>
Date: Wed, 3 Mar 2010 22:32:16 +0100

> just as source and destination port numbers copied (in reverse order)

I don't understand what you believe to be wrong wrong in the full statement, which was:

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

Indeed, if two hosts in a common domain in which they have have private IPv4 addresses in addition to their port-restricted public addresses, nothing prevents them from using any protocol between them with these private addresses (and ICMP in particular).

Explanation welcome.

RD

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Mar 2010 07:06:55 +0900

Remi wrote:

> Indeed, if two hosts in a common domain in which they have have
> private IPv4 addresses in addition to their port-restricted
> public addresses, nothing prevents them from using any protocol
> between them with these private addresses (and ICMP in particular).

That's fine.

My point is that plain ICMP just works to/from a host with port
restricted public IPv4 addresses so that you don't have to say
anything about private addresses.

You (and A+P routers) can direct an ICMP echo request/reply packet
to an appropriate tunnel using identifier of echo request and
sequence number of echo reply as destination port number.

It is assumed that sequence number of echo request is restricted
as if it is a restricted source port number. Then, the sequence
number is copied by a destination end host to echo reply and
should act as a restricted destination port number of the reply.

For the restriction, ping command must be modified, but no ICMP
protocol change necessary.

						Masataka Ohta