Subject: [alto] ALTO and NAT

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 25 Aug 2009 11:13:55 +0200

Hi Dave,

On Tue, Jul 28, 2009 at 04:45:51AM -0700, Craig, Dave wrote:
> On what types of NATs MUST/SHOULD should be supported as part of the
> requirements.  There are BCPs specifying NAT behavior from the BEHAVE
> WG that can be referenced, RFCs 4787 and 5382.

thank you for that pointer.  After reading over these documents I am not
sure whether the definitions made there really address the core of our
problem.

The ALTO client protocol is a TCP-based client-/server-protocol (see
reqs.), and I think that it is safe to assume that the ALTO server is
in the public address realm or, in the case of cascaded NATs, at least
closer to it than the client (this has not been documented, should we?).
Therefore, it should be possible to get that protocol through all kinds
of NAT - if that fails I doubt that the actual P2P application protocol
will get through.

The main issue we will have to consider is that ALTO may use IP
addresses as identifiers in the protocol, and that it might get 
confused by different IP address realms:

- For the ALTO server discovery, there are proposals like BEP22 
  at least under consideration, i.e., some kind of DNS-based
  IP_address-to-SRV_record lookup scheme. This has advantages for
  third-party discovery, but if the client wants to find a server
  by itself, it must know its own "public" IP address (maybe via STUN,
  in this case not used for hole punching but just for learning
  the address)

- Furthermore, the ALTO guidance is based on evaluating candidate peers,
  which are characterized by means of host group descriptors, i.e.,
  IP addresses or macros/PIDs/... that resovle to IP addresses.

  On the one hand, it is only natural to give ALTO guidance with respect
  to IP addresses, as the resource consumer will eventually do a
  connect(2) to the "best" IP address. On the other hand we must make
  sure that the ALTO server's guidance and the resource consumer's
  connection target at the same peer.

Should we try to cast these thoughts into requirements?

Thanks,

    Sebastian

-- 
Sebastian Kiesel            mailto:[email-masked]
Network Research Division   tel:+49-6221-4342-232   fax:+49-6221-4342-155
NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 Heidelberg, Germany
--
NEC Europe Limited          Registered in England 2832014
Registered Office           NEC House, 1 Victoria Road, London W3 6BL