Hi Paco,

To have such complicated DPI functionality in the network is totally out of
scope of IETF.
I don't think IETF should discuss this type of complicated DPI here.

Best regards,

-Hui

2011/7/28 Paco Cortes <[email protected]>

> Hi Wojciech,
>
> two comments on the 3gpp sections of draft-dec-stateless-4v6-02.
>
> First, the definition of "Rx" is missing in section 4.2.1.
>
> Second, the table in section 4.2.2 claims "No discernible impact" for
> "AF Application Function" for the 4V6 translation mode. This is not
> fully correct.
> The PCC architecture support a plurality of AFs communication over Rx
> with the PCRF, and most of them "interact" in some way with the end
> user payload.
> An AF might terminate, proxy or transparently inspect a subset of the
> UE traffic (for instance control signalling, like SIP).
> An AF might also terminate, proxy or transparently inspect all UE
> traffic (application server acting as AF, deep packet inspection
> device, ...).
> And the most important point: An AF might located in different
> locations inside the operators networks, or even outside the operators
> network.
> Referring to your own "Figure 2" in the draft, this means that for
> IPv4 traffic an AF might "intercept" traffic between the "PDN-Gw" and
> the "S46 Gateway", i.e. with an IPv6 header, BUT it might also
> intercept traffic behind the "S46 Gateway", i.e., with an IPv4 header.
>
> I propose to change the impact to "No impact for IPv6. Feature to map
> IPv4-IPv6 addresses may be needed only in case of  IPv4-only
> applications".
>
> I'm aware that it would be theoretically possible to "hide" this
> impact from an AF by using a more complex PCRF implementation that
> "translates" IPv4 addresses in Rx message (including TFTs) into the
> mapped IPv6, but this would imply limitations, and would just be one
> implementation possibility. I believe that this draft should not
> assume a specific implementation, unless clearly documented.
>
> br,
>  Paco
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to