Re: How to include APBP scenarios in the Coexistence RequirementI-D

["Durand, Alain" <Alain_Durand@cable.comcast.com>]

Dan,

Because there is only one level of NAT in dual-stack lite, couldn't this be
simplified by asking the dual-stack lite home gateway to forward the UPnP
message to the dual-stack lite carrier-grade NAT?

  - Alain.


On 7/16/08 2:03 PM, "Dan Wing" <dwing@cisco.com> wrote:

>> Following some privatly received comments of Dan Wing, the
>> standby phase hasn't be long, and the idea to possibly give up
>> APBP stands no longer !
>> 
>> I just posted draft-01,  with  I believe  substantial simplifications
>> and improved applicability.
>> 
>> Sorry for the one more change.
> 
> Allow me to elaborate a bit on our offline discussion over the weekend.
> 
> I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI,
> dual-stack-lite, etc.) are quiet on a significant aspect of a requirement that
> is important:  keeping existing games and existing applications working.  I am
> thinking of game boxes like Microsoft's Xbox that need UPnP IGD in order to
> function properly over the Internet, and applications such as Microsoft
> Netmeeting (needs an H.323 ALG in the NAT), Quicktime and RealAudio streaming
> (RTSP), and so on.  http://tools.ietf.org/html/rfc3027 does a good job of
> explaining the specifics.
> 
> A protocol which meets the requirements of APBP would allow UPnP IGD, NAT-PMP,
> and appropriate ALGs to be in the subscriber-side CPE box, and allow using
> APBP to the carrier-owned NAT64/NAT44 box to obtain a real, publicly-routable
> v4 transport address.  That publicly-routable v45 transport address would then
> be used by the subscriber-side CPE in exactly the same way that today's
> subscriber-side CPE uses its own WAN transport address for the same functions.
> For UPnP IGD, the availability of APBP means a host that performs the UPnP
> getPublicIPAddress() API call would get a publicly-routable v4 transport
> address.  Without APBP, a host performing that same function call would not
> get a v4 address at all.
> 
> 
> Here is some beautiful ASCII art diagrams of the difference between today's
> UPnP IGD (and NAT-PMP) and what I am suggesting is useful (and necessary) for
> tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP:
> 
> 
> Today's UPnP IGD and NAT-PMP function at a high level:
> 
> +-----------------+
> |incoming UPnP IGD|
> |or NAT-PMP packet|
> +----+------------+
>      |
>      V
> +-------------+          +-----------------------+
> |  need new   |-----YES->| create NAT binding    |
> |NAT binding? |          |using NAT's WAN address|
> +----+--------+          +---------+-------------+
>      |                             |
>      NO                            |
>      |                             |
>      V                             |
> +----+---------------+             |
> |respond to UPnP IGD |<------------+
> |or NAT-PMP request  |
> +----+---------------+
> 
> 
> Change to UPnP IGD or NAT-PMP function inside of the subscriber NAT
> (difference highlighted with "=" and capital letters):
> 
> 
> +-----------------+
> |incoming UPnP IGD|
> |or NAT-PMP packet|
> +----+------------+
>      |
>      V
> +-------------+          +=========================+
> |  need new   |-----YES->| SEND "APBP" MESSAGE     |
> |NAT binding? |          | TOWARDS SP'S CARRIER NAT|
> +----+--------+          +=========+===============+
>      |                             |
>      NO                            |
>      |                             |
>      V                             |
> +----+---------------+             |
> |respond to UPnP IGD |<------------+
> |or NAT-PMP request  |
> +----+---------------+
> 
> -d
> 
>