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

[Alain Durand <alain_durand@cable.comcast.com>]

But, of course, all this has to be balanced with the security (or lack
thereof) of UPnP...

  - Alain.


On 7/16/08 4:50 PM, "Alain Durand" <alain_durand@cable.comcast.com> wrote:

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