Subject: RE: [mobile-ip] Revised agenda for: MIP4 - Mobility for IPv4 BOF

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 17 Jul 2003 07:03:54 -0500

Kent,

Just to answer your 3GPP related questions, my understanding is that 3GPP
has defines GPRS based solution which allows exchange of server information
between the mobile node and the core network in addition to DHCP.

Regards,
Jayshree

> -----Original Message-----
> From: Kent Leung [mailto:[email-masked]] 
> Sent: Wednesday, July 16, 2003 4:48 PM
> To: Alper Yegin
> Cc: Kuntal Chowdhury; Erik Nordmark; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; Lila Madour (LMC); Avi Lior; 
> Bharatia, Jayshree [RICH1:2H13:EXCH]; 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
> 
>

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 17 Jul 2003 06:09:47 -0500

Basavaraj,

If reality is always conformant to the expectation, I agree that we won't
have any issues. 

I have personally requested alternatives of the solution(s) of these
problems mentioned earlier on this thread but didn't have any luck. Anyway,
if you are referring to DHCP as well understood mechanism, you might have
seen issues posted earlier by Kent and others on using DHCP.   

Regards,
Jayshree

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, July 17, 2003 4:27 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]; 
> [email-masked]
> Subject: RE: [mobile-ip] Revised agenda for: MIP4 - Mobility 
> for IPv4 BOF
> 
> 
> 
> 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
> 
> 
> > From: ext Kent Leung [mailto:[email-masked]]
> > Sent: 16 July, 2003 11:48 PM
> > To: Alper Yegin
> > Cc: Kuntal Chowdhury; Erik Nordmark; Patil Basavaraj (NET/Dallas); 
> > [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; 
> > [email-masked]; Mike Borella
> > Subject: Re: [mobile-ip] Revised agenda for: MIP4 - 
> Mobility for IPv4 
> > BOF
> > 
> > 
> > Hi Alper.
> > 
> > core source of
> > >difference in opinions.
> > 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
> > > > #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.
> > >
> > for, but if there
> > >is authentication and AAA involved:
> > 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.
> > 
> > 
> > for Mobile IP
> > service in 3GPP2.  And the reality is that not all operators 
> > want to use DHCP.
> > 
> > 
> > > >
> > > > 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
> > same problem when
> > PPP is not used.  3GPP may also encounter this issue, 
> > depending on how that
> > L2 authentication is specified.
> > 
> > Kent
> > 
> > 
>

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 17 Jul 2003 07:03:54 -0500

Kent,

Regards,
Jayshree

---

From: Kent Leung <[email-masked]>
Date: Thu, 17 Jul 2003 16:09:33 -0700

Hi Raj.  I do agree that the proper method for obtaining DNS servers
and other host configurations should be DHCP.

The deployment of IETF based Mobile IP out in the
industries such as IEEE WLAN, GPRS/3GPP, and 3GPP2 is
mutually beneficial.

I wanted to focus on figuring out if this is a 3GPP2 specific issue
or a general problem.

So let's go down the list.

For IEEE WLAN, DHCP is the answer.  For GPRS/3GPP, GGSN can send
DHCP/RADIUS request to the specific enterprise to retrieve the DNS server
address.  So typically, PPP/RADIUS and DHCP is sufficient.

But for 3GPP2, the problem is PPP/IPCP already completed and there may
not be DHCP available when MIP registration happens.  So any host configuration
has to come through MIP extensions.

Sorry, maybe it may have been obvious to others, but I didn't know going in 
that
this issue is specific to 3GPP2 only.  I think that's because there's 
really no DHCP
scheme that can be used today either.  Steve's draft is still work in progress.
Thus I was stuck thinking there's a generic issue for deployment.

I agree with your proposal. :)

Kent

At 04:27 AM 7/17/2003 -0500, [email-masked] wrote:
>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
>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

---

From: <[email-masked]>
Date: Mon, 21 Jul 2003 11:07:16 -0500

Hi Jayshree,
 
I think what we need to have is a problem statement written up for what you are requesting.
Once you have that lets see if this is a generic problem across the Internet w.r.t Mobile IPv4
or if it is isolated to 3GPP2 implementation of Mobile IPv4 only. If the problem is generic
enough, then I agree that it would be a good reason to work on a solution that would allow
MN configuration using Mobile IP messages. If the problem is isolated, then I think we should
consider using Vendor Specific Extensions for solving this problem. 
 
Does that make sense? 
 
-Basavaraj

Basavaraj, 

If reality is always conformant to the expectation, I agree that we won't have any issues. 

I have personally requested alternatives of the solution(s) of these problems mentioned earlier on this thread but didn't have any luck. Anyway, if you are referring to DHCP as well understood mechanism, you might have seen issues posted earlier by Kent and others on using DHCP.   

Regards, 
Jayshree