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

Afer reading this debate for a while, I've come to two
conclusions:

- There doesn't seem to be a standard way enabling
this functionality that is both clean and minimal
impact.  Just putting DHCP in the mobiles has its
drawbacks, as do other solutions, such as DHCP proxy
on the FA.

- It wouldn't hurt anyone to define VSAs to do this. A
solution is needed and if architectural purity is
going to trump engineering, then 3GPP2 should just do
it their own way.  It wouldn't hurt to have 3GPP2
eventually publish an Informational RFC with all of
the RADIUS attrbiutes and related VSAs that it has
defined, as many of them are quite useful.

Mike




--- Kuntal Chowdhury <[email protected]> wrote:
> 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
> >>
> >>
> > 
> > 
> > 
> 
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com