[Top] [All Lists]

RE: Review on draft-ietf-v6ops-v6-in-mobile-networks-03

2011-03-04 15:51:08
Hi Rajeev,
See comments in line.

We keep our promises with one another - no matter what!

Best Regards,

-----Original Message-----
From: Rajeev Koodli [mailto:rkoodli(_at_)cisco(_dot_)com] 
Sent: Tuesday, March 01, 2011 1:55 PM
To: Tina TSOU; ops-dir(_at_)ietf(_dot_)org; 'The IESG'; ietf(_at_)ietf(_dot_)org
Cc: draft-ietf-v6ops-v6-in-mobile-networks(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: Review on draft-ietf-v6ops-v6-in-mobile-networks-03

Hi Tina,

Thanks for the review.

On 3/1/11 8:25 AM, "Tina TSOU" <tena(_at_)huawei(_dot_)com> wrote:

Comment #1
In section 3.1, "Delaying the public IPv4 address exhaustion involves
assigning private IPv4 addressing for end-users, as well as extending an
IPv4 address (with the use of extended port ranges).
do you mean using some solution like address + port
     If yes, where do you think Address + Port solution should be
implemented? Maybe one of the node could be GGSN/PDN gateway, how about
other node, is it the mobile node or the ANG?

My personal opinion is that you would have to modify the MN.

It is not the intent of the ID to suggest location of A+P elements, as you
probably realize.

Some clarification of A+P used in mobile network is needed. A+P can be used
on CPE in wireline network. There is no very proper node to support in
wireless network. Implementing A + P in cell phone may need change of
Operating System, even though not as much as PNAT. In addition, there maybe
some ARP issue, for example, cell phones sharing one address can not
communicate with each other, as the peer address is it self's, unless we are
going to change ARP.]

Comment #2
In section 3.1
"An approach to  address this problem is to make the always-on PDN to be
IPv6, and
   enable IPv4 PDN on-demand, e.g., when an application binds to an IPv4
   socket interface. This ensures that an IPv4 address is not assigned
   for every attached MN, but only to those attempting to use the
   traffic.  The IPv4 PDN may be subject to session idle timers upon the
   expiry of which, the PDN (and the assigned IPv4 address) may be
   deleted.  Another option specified in the 3GPP standards is to defer
   the allocation of IPv4 address on a dual-stack IPv4v6 PDN at the time
   of connection establishment.  This has the advantage of a single PDN
   for IPv6 and IPv4, along with deferring IPv4 address allocation until
   an application needs it"
now, and in the near future, most of the content would still be
in IPv4 network, not sure whether this solution could save private IPv4

Sure. However, by deferring the allocation of an IPv4 address until a PDN
and/or an application actually needs it, you also conserve the pool.
it could work, which won't save many private IP address. It will also bring
the complexity of implementation.]

    And this would also require some modification in the mobile devices.

Right. The operators who are interested in this already have the necessary
"bindings" - when a user clicks on an app (that requires IPv4 PDN), it
invokes the necessary PDN signaling if the PDN is not active already.



We keep our promises with one another - no matter what!

Best Regards,

Ietf mailing list

<Prev in Thread] Current Thread [Next in Thread>