Re: Revised agenda for: MIP4 - Mobility for IPv4 BOF

DHCPv4 over wireless links with MIPv4:

1. Mandate reverse tunnel.
2. Send DHCP server discovery in the home network by sending a broadcast message.
3. Transmit the replies from all DHCP servers that received the discovery message.
4. Then the mobile sends a unicast request to a chosen DHCP server.
5. subsequent request/response for config options.

Pros:
1. This makes the DHCP camp happy :o)

Cons:
1. Step 2 is a waste of radio resource but it will be necessary if hard coding 
of DHCP server address in the mobile is not desired.
2. Step 3 is a total waste of radio resource which may be significant when 
several DHCP servers respond to the discovery message.
3. Step 1 is a rather unnecessary constraint on some of the networks.
4. All the steps add to the call setup time especially for conversational 
applications.

Note that all of the above steps could be avoided if the info that the MS is 
seeking is attached in the MIPv4 RRP.

-Kuntal

[email protected] wrote:
> Kent,
> 
> How much of customization of the Mobile IPv4 specs should be
> continued to be made simply because reality is non-conformant
> to the specs? So will adding this additional extension to the
> MIPv4 specs be the end of the line for such needs... I tend to
> think that this encourages more such extensions to be made in
> the future simply because there unwillingness to implement well
> understood and standardized mechanisms...
> I think we are doing things in the wrong order here. We see 
> implementations that are taking the wrong approach or a shortcut
> to accomplishing something.... And then we come to the IETF and 
> say this is reality and hence needs to be standardized... I
> just dont buy this argument...
> 
> If you really think that there is no possibility of using well
> understood mechanisms for configuration, then I would propose that
> vendor specific extensions (MIPv4 RFC) be used for this purpose
> rather than standardizing some new extensions to the Reg_REQ and
> Reg_RESP messages.
> 
> -Basavaraj
> 
> 
> 
>>-----Original Message-----
>>From: ext Kent Leung [mailto:[email protected]]
>>Sent: 16 July, 2003 11:48 PM
>>To: Alper Yegin
>>Cc: Kuntal Chowdhury; Erik Nordmark; Patil Basavaraj (NET/Dallas);
>>[email protected]; [email protected]; [email protected]; [email protected];
>>[email protected]; Lila Madour (LMC); Avi Lior;
>>[email protected]; Mike Borella
>>Subject: Re: [mobile-ip] Revised agenda for: MIP4 - Mobility for IPv4
>>BOF
>>
>>
>>Hi Alper.
>>
>>At 08:52 AM 7/16/2003 -0700, Alper Yegin wrote:
>>
>>
>>>>       - MN doesn't have DHCP capability (PPP/IPCP only)
>>>>       - Home domain may not use DHCP for address allocation
>>>>(alternatives such as AAA
>>>>         or local pool)
>>>
>>>These constraints must be a particular architecture's 
>>
>>constraints, not
>>
>>>general IETF protocol suite constraint. I think this is the 
>>
>>core source of
>>
>>>difference in opinions.
>>
>>
>>I would agree with you from the purist perspective.  Though 
>>I'm not sure
>>if the world is that ideal.  Else we would probably be running ATM, or
>>IPv6, or OSI.  :)  And using meters instead of yards.  I'm 
>>getting off the
>>issue..  but I think we still have to handle what we have 
>>been dealt.  See
>>possible alternative to solving the problem below.
>>
>>
>>
>>
>>>>#1 - MNs that support PPP/IPCP only, use RFC 1877.  But 
>>>
>>this does not
>>
>>>>achieve the
>>>>objective of getting the DNS server info from the home 
>>>
>>domain since
>>
>>>>PPP/IPCP terminates
>>>>on the NAS/FA.
>>>
>>>I don't fully know which architecture we are solving this 
>>
>>for, but if there
>>
>>>is authentication and AAA involved:
>>>- PPP authentication (or MIPv4 auth), in conjunction with 
>>
>>Radius/DIAMETER,
>>
>>>could bring in the DNS parameter to NAS. If NAS implements 
>>
>>DHCP Relay or
>>
>>>Agent, it  can deliver this parameter to the host.
>>
>>
>>As you probably already know, there is no PPP authentication 
>>for Mobile IP
>>service in 3GPP2.  And the reality is that not all operators 
>>want to use DHCP.
>>
>>
>>
>>>>#2 - Not a technical issue, but changing how operators 
>>>
>>deploy their
>>
>>>>networks may be
>>>>futile.
>>>>
>>>>So, back to attempting to resolve the requirement.  Is 
>>>
>>there an alternative
>>
>>>>solution to
>>>>getting the DNS server info to the MNs that can satisfy 
>>>
>>the hurdles?  I
>>
>>>>don't see any
>>>>in the opposition.  Though I believe we need a solution here.
>>>>
>>>>Kent
>>>
>>
>>If you are saying that this is not a generic Mobile IP issue but 
>>3GPP2-centric.  And
>>that it's better to update IS-835 to add 3GPP2 VSA for these 
>>functions, I'm 
>>not sure
>>if I would completely disagree.  However, GPRS would have the 
>>same problem when
>>PPP is not used.  3GPP may also encounter this issue, 
>>depending on how that
>>L2 authentication is specified.
>>
>>Kent
>>
>>
> 
> 
>