RE: Revised agenda for: MIP4 - Mobility for IPv4 BOF
Pete McCann <[email protected]> Thu, 17 Jul 2003 14:08:38 -0500
| Newsgroups | gmane.ietf.mobileip |
|---|---|
| Message-ID | <[email protected]> |
IMHO, we should be leaving device configuration to the dhc folks. Mobile IP does the minimum possible configuration to get connectivity to a home network. We really need to think about the modularity of the standards process and the internet protocol suite and keep that in mind when we are considering which nail to hit with our hammer. -Pete Jayshree Bharatia writes: > 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 > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Thursday, July 17, 2003 4:27 AM > > To: [email protected]; [email protected] > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; > > [email protected]; [email protected]; > > Bharatia, Jayshree [RICH1:2H13:EXCH]; [email protected]; > > [email protected] > > 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 > > > > > > > -----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 > > > > > > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> > <HTML> > <HEAD> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2656.31"> > <TITLE>RE: [mobile-ip] Revised agenda for: MIP4 - Mobility for IPv4 BOF</TITLE> > </HEAD> > <BODY> > > <P><FONT SIZE=2>Basavaraj,</FONT> > </P> > > <P><FONT SIZE=2>If reality is always conformant to the expectation, I agree that we won't have any issues. </FONT> > </P> > > <P><FONT SIZE=2>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. </FONT></P> > > <P><FONT SIZE=2>Regards,</FONT> > <BR><FONT SIZE=2>Jayshree</FONT> > </P> > > <P><FONT SIZE=2>> -----Original Message-----</FONT> > <BR><FONT SIZE=2>> From: [email protected] [<A HREF="mailto:[email protected]">mailto:[email protected]</A>] </FONT> > <BR><FONT SIZE=2>> Sent: Thursday, July 17, 2003 4:27 AM</FONT> > <BR><FONT SIZE=2>> To: [email protected]; [email protected]</FONT> > <BR><FONT SIZE=2>> Cc: [email protected]; [email protected]; </FONT> > <BR><FONT SIZE=2>> [email protected]; [email protected]; [email protected]; </FONT> > <BR><FONT SIZE=2>> [email protected]; [email protected]; </FONT> > <BR><FONT SIZE=2>> [email protected]; [email protected]; </FONT> > <BR><FONT SIZE=2>> Bharatia, Jayshree [RICH1:2H13:EXCH]; [email protected]; </FONT> > <BR><FONT SIZE=2>> [email protected]</FONT> > <BR><FONT SIZE=2>> Subject: RE: [mobile-ip] Revised agenda for: MIP4 - Mobility </FONT> > <BR><FONT SIZE=2>> for IPv4 BOF</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> Kent,</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> How much of customization of the Mobile IPv4 specs should be </FONT> > <BR><FONT SIZE=2>> continued to be made simply because reality is non-conformant </FONT> > <BR><FONT SIZE=2>> to the specs? So will adding this additional extension to the </FONT> > <BR><FONT SIZE=2>> MIPv4 specs be the end of the line for such needs... I tend </FONT> > <BR><FONT SIZE=2>> to think that this encourages more such extensions to be made </FONT> > <BR><FONT SIZE=2>> in the future simply because there unwillingness to implement </FONT> > <BR><FONT SIZE=2>> well understood and standardized mechanisms... I think we are </FONT> > <BR><FONT SIZE=2>> doing things in the wrong order here. We see </FONT> > <BR><FONT SIZE=2>> implementations that are taking the wrong approach or a </FONT> > <BR><FONT SIZE=2>> shortcut to accomplishing something.... And then we come to </FONT> > <BR><FONT SIZE=2>> the IETF and </FONT> > <BR><FONT SIZE=2>> say this is reality and hence needs to be standardized... I </FONT> > <BR><FONT SIZE=2>> just dont buy this argument...</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> If you really think that there is no possibility of using </FONT> > <BR><FONT SIZE=2>> well understood mechanisms for configuration, then I would </FONT> > <BR><FONT SIZE=2>> propose that vendor specific extensions (MIPv4 RFC) be used </FONT> > <BR><FONT SIZE=2>> for this purpose rather than standardizing some new </FONT> > <BR><FONT SIZE=2>> extensions to the Reg_REQ and Reg_RESP messages.</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> -Basavaraj</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> > -----Original Message-----</FONT> > <BR><FONT SIZE=2>> > From: ext Kent Leung [<A HREF="mailto:[email protected]">mailto:[email protected]</A>]</FONT> > <BR><FONT SIZE=2>> > Sent: 16 July, 2003 11:48 PM</FONT> > <BR><FONT SIZE=2>> > To: Alper Yegin</FONT> > <BR><FONT SIZE=2>> > Cc: Kuntal Chowdhury; Erik Nordmark; Patil Basavaraj (NET/Dallas); </FONT> > <BR><FONT SIZE=2>> > [email protected]; [email protected]; [email protected]; </FONT> > <BR><FONT SIZE=2>> [email protected]; </FONT> > <BR><FONT SIZE=2>> > [email protected]; Lila Madour (LMC); Avi Lior; </FONT> > <BR><FONT SIZE=2>> > [email protected]; Mike Borella</FONT> > <BR><FONT SIZE=2>> > Subject: Re: [mobile-ip] Revised agenda for: MIP4 - </FONT> > <BR><FONT SIZE=2>> Mobility for IPv4 </FONT> > <BR><FONT SIZE=2>> > BOF</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > Hi Alper.</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > At 08:52 AM 7/16/2003 -0700, Alper Yegin wrote:</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > > > - MN doesn't have DHCP capability (PPP/IPCP only)</FONT> > <BR><FONT SIZE=2>> > > > - Home domain may not use DHCP for address allocation </FONT> > <BR><FONT SIZE=2>> > > > (alternatives such as AAA</FONT> > <BR><FONT SIZE=2>> > > > or local pool)</FONT> > <BR><FONT SIZE=2>> > ></FONT> > <BR><FONT SIZE=2>> > >These constraints must be a particular architecture's</FONT> > <BR><FONT SIZE=2>> > constraints, not</FONT> > <BR><FONT SIZE=2>> > >general IETF protocol suite constraint. I think this is the</FONT> > <BR><FONT SIZE=2>> > core source of</FONT> > <BR><FONT SIZE=2>> > >difference in opinions.</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > I would agree with you from the purist perspective. Though</FONT> > <BR><FONT SIZE=2>> > I'm not sure</FONT> > <BR><FONT SIZE=2>> > if the world is that ideal. Else we would probably be </FONT> > <BR><FONT SIZE=2>> running ATM, or</FONT> > <BR><FONT SIZE=2>> > IPv6, or OSI. :) And using meters instead of yards. I'm </FONT> > <BR><FONT SIZE=2>> > getting off the</FONT> > <BR><FONT SIZE=2>> > issue.. but I think we still have to handle what we have </FONT> > <BR><FONT SIZE=2>> > been dealt. See</FONT> > <BR><FONT SIZE=2>> > possible alternative to solving the problem below.</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > > ></FONT> > <BR><FONT SIZE=2>> > > > #1 - MNs that support PPP/IPCP only, use RFC 1877. But</FONT> > <BR><FONT SIZE=2>> > this does not</FONT> > <BR><FONT SIZE=2>> > > > achieve the</FONT> > <BR><FONT SIZE=2>> > > > objective of getting the DNS server info from the home</FONT> > <BR><FONT SIZE=2>> > domain since</FONT> > <BR><FONT SIZE=2>> > > > PPP/IPCP terminates</FONT> > <BR><FONT SIZE=2>> > > > on the NAS/FA.</FONT> > <BR><FONT SIZE=2>> > ></FONT> > <BR><FONT SIZE=2>> > >I don't fully know which architecture we are solving this</FONT> > <BR><FONT SIZE=2>> > for, but if there</FONT> > <BR><FONT SIZE=2>> > >is authentication and AAA involved:</FONT> > <BR><FONT SIZE=2>> > >- PPP authentication (or MIPv4 auth), in conjunction with</FONT> > <BR><FONT SIZE=2>> > Radius/DIAMETER,</FONT> > <BR><FONT SIZE=2>> > >could bring in the DNS parameter to NAS. If NAS implements</FONT> > <BR><FONT SIZE=2>> > DHCP Relay or</FONT> > <BR><FONT SIZE=2>> > >Agent, it can deliver this parameter to the host.</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > As you probably already know, there is no PPP authentication</FONT> > <BR><FONT SIZE=2>> > for Mobile IP</FONT> > <BR><FONT SIZE=2>> > service in 3GPP2. And the reality is that not all operators </FONT> > <BR><FONT SIZE=2>> > want to use DHCP.</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > > ></FONT> > <BR><FONT SIZE=2>> > > > #2 - Not a technical issue, but changing how operators</FONT> > <BR><FONT SIZE=2>> > deploy their</FONT> > <BR><FONT SIZE=2>> > > > networks may be</FONT> > <BR><FONT SIZE=2>> > > > futile.</FONT> > <BR><FONT SIZE=2>> > > ></FONT> > <BR><FONT SIZE=2>> > > > So, back to attempting to resolve the requirement. Is</FONT> > <BR><FONT SIZE=2>> > there an alternative</FONT> > <BR><FONT SIZE=2>> > > > solution to</FONT> > <BR><FONT SIZE=2>> > > > getting the DNS server info to the MNs that can satisfy</FONT> > <BR><FONT SIZE=2>> > the hurdles? I</FONT> > <BR><FONT SIZE=2>> > > > don't see any</FONT> > <BR><FONT SIZE=2>> > > > in the opposition. Though I believe we need a solution here.</FONT> > <BR><FONT SIZE=2>> > > ></FONT> > <BR><FONT SIZE=2>> > > > Kent</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > If you are saying that this is not a generic Mobile IP issue but</FONT> > <BR><FONT SIZE=2>> > 3GPP2-centric. And</FONT> > <BR><FONT SIZE=2>> > that it's better to update IS-835 to add 3GPP2 VSA for these </FONT> > <BR><FONT SIZE=2>> > functions, I'm </FONT> > <BR><FONT SIZE=2>> > not sure</FONT> > <BR><FONT SIZE=2>> > if I would completely disagree. However, GPRS would have the </FONT> > <BR><FONT SIZE=2>> > same problem when</FONT> > <BR><FONT SIZE=2>> > PPP is not used. 3GPP may also encounter this issue, </FONT> > <BR><FONT SIZE=2>> > depending on how that</FONT> > <BR><FONT SIZE=2>> > L2 authentication is specified.</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > Kent</FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> > </FONT> > <BR><FONT SIZE=2>> </FONT> > </P> > > </BODY> > </HTML>