Subject: [AVT] New text for the Token approach

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 3 Aug 2010 12:03:48 -0700

In the meeting last week, we were asked to come up with a design that would combine the cookie approach and token approach since some folks raised some concerns about the validity of the token approach in any given network. Concerns were mostly specific to carrier-grade NATs.

Here is a draft text that we are planning to put in the revision for the token approach. As the authors, we still think that the token approach can reliably work in the networks we are interested. Essentially, CGNs, by design, will not assign different IPv4 addresses for a given host as long as that host maintains at least one binding alive.

Let us know what you think.

-acbegen

    <new text>

    Address Pooling NATs:

    Large-scale NAT (LSN) devices have a pool of public IPv4
    addresses and map internal hosts to one of those public
    IPv4 addresses.  As long as an internal host maintains an
    active mapping in the NAT, the same IPv4 address is
    assigned to new connections.  However, once all of the
    host's mappings have been deleted (e.g., because of
    timeout), it is possible that a new connection from that
    same host will be assigned a different IPv4 address from
    the pool.  When that occurs, the Token will be considered
    invalid by the server, causing an additional round trip for
    the client to acquire a fresh token.

    Any traffic from the host which traverses the NAT will
    prevent this problem.  As the host is sending RTCP receiver
    reports at least every 5 seconds (RFC 3550 Section 6.2) for
    the multicast session it is receiving, those RTCP messages will 
    be sufficient to prevent this problem. 

    </new text>