RE: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02

[<teemu.savolainen@nokia.com>]

Hi Rajeev,

> is saying. This draft is not introducing a host change in the form of
> DHCP.
> 3GPP has already included DHCP as a mechanism. Please see below.

It has, as optional. This draft in my opinion talks like DHCP would be commonplace. See below.

> If PGW includes a Deferred Address Allocation PCO in Create Session
> Response
> (and hence no IPv4 address in it), the host has to do DHCP.

Incorrect. Standard does not allow network to behave that way.

23.401 says:
--
- the UE may indicate that it prefers to obtain an IPv4 address as part of the default bearer activation procedure. In such a case, the UE relies on the EPS network to provide IPv4 address to the UE as part of the default bearer activation procedure.
--
Both EPS network elements and UE shall support the following mechanisms:
a. IPv4 address allocation via default bearer activation, if IPv4 is supported.
--
Both EPS network elements and UE may support the following mechanisms:
a.	IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to RFC 2131 [19] and RFC 4039 [25];
--

Please note the *shall* for both EPS network and UE to support IPv4 address allocation in bearer activation, and *may* for both EPS network and UE to support DHCPv4.

Hence as DHCP is optional for UE, network cannot force DHCP usage for UE supporting only the *shall* and that is not indicating support for DHCP, which is *may*.

This is the specification I read. There are many of those, so please point to specification where you read host must do DHCP if network so says.

> > 2) a host has to support deferred DHCP for 3GPP access
> (reserve/release
> > on-demand)
> 
> Yes, some hosts do this based on application trigger. OTOH, you could
> initiate DHCP right away (after attach) but the network could use
> shorter
> lease times.

Right, some hosts may, but not all. Especially those that don't do DHCP for 3GPP.

> > 3) a host has to support negotiation of used address allocation
> mechanism for
> > 3GPP access:
> > 3a) A host will have to ask if DHCP is used for this particular PDN
> connection
> > 3b) If DHCP is not used, host shall get the address from bearer
> signaling
> > instead
> 
> Yes. This is part of 3GPP TS 23.401, TS 29.274/5.

Yes, but this is *may* per 3GPP TS 23.401. Your draft should be more explicit in telling that the percentage of host population that actually implements the *may* part is unknown for time being.

> > Also in LTE the DHCP is optional for both host and network.
> 
> My understanding is that the assignment at attach is default, but PGW
> may choose to instead use DHCP.

Yes if UE indicates optional DHCP support.

> Let us try to separate the issues here.
> 
> 1. When DHCP is initiated. 1a) right after attach, 1b) as a response to
> an
> application trigger. Your concern is with 1b) right?

Of those two, my concern is 1b.

But the bigger concern is talking so much about DHCP that is optional by standard.
 
> 2. Regardless of 1a), 1b), a network could use lease times of its
> choice
> right (subject to pros/cons)?

Right. But the lease time is IMHO mostly irrelevant, if the host is stubborn to just renew even if it hasn't applications running. Thus the host would have to be smart enough not to renew if it doesn't have imminent need for IPv4.

> Hmm..interesting. Going by this, one could argue that DHCP with shorter
> lease times is host based transition, and the network cleaning up
> PDN/PDP sessions due to timers is network-based transition :-)

As said, DHCP with short lease times and network cleaning PDP sessions does help nothing if the host has decided to keep IPv4 connection up "just in case", and instantly renews what network tries to bring down. You must have host support not to open "just in case".

> IMO, a mobile network provider may require DHCP from vendors. Not all
> providers may go for it, but some may find it useful.

This is absolutely true. However, the standard does not mandate DHCP. Hence the standard documents, like this draft, should be clear on what is certainly available by standards compliant devices (that implements musts and shalls), and what may require something extra (i.e. what is possible by standard, but not necessarily supported by default - the mays).

Best regards,

Teemu