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

From: <[email-masked]>
Date: Thu, 17 Jul 2003 04:27:02 -0500

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-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]; Lila Madour (LMC); Avi Lior;
> [email-masked]; 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: Kuntal Chowdhury <[email-masked]>
Date: Mon, 21 Jul 2003 09:25:10 -0500

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

---

From: Mike Borella <[email-masked]>
Date: Mon, 21 Jul 2003 09:34:42 -0700 (PDT)

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

> >>L2 authentication is specified.

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