Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14733; 1 Dec 95 10:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14729; 1 Dec 95 10:12 EST Received: from tadpole.Tadpole.COM by CNRI.Reston.VA.US id aa12810; 1 Dec 95 10:12 EST Received: (from majordomo@localhost) by tadpole.tadpole.com (8.6.10/8.6.10) id IAA11914 for mobile-ip-dist; Fri, 1 Dec 1995 08:49:00 -0600 Received: from ftp.com (ftp.com [128.127.2.122]) by tadpole.tadpole.com (8.6.10/8.6.10) with SMTP id IAA11731 for ; Fri, 1 Dec 1995 08:36:02 -0600 Received: from ftp.com by ftp.com ; Fri, 1 Dec 1995 09:36:01 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 1 Dec 1995 09:36:01 -0500 Received: from kasten.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA03357; Fri, 1 Dec 95 09:33:01 EST Date: Fri, 1 Dec 95 09:33:01 EST Message-Id: <9512011433.AA03357@mailserv-D.ftp.com> To: mobile-ip@tadpole.com Subject: Re: (mobile-ip) Mobile IP Testing Report Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Repository: mailserv-D.ftp.com, [message accepted at Fri Dec 1 09:32:54 1995] Originating-Client: d-cell.ftp.com Content-Length: 1560 X-Orig-Sender: owner-mobile-ip@tadpole.com Precedence: bulk Reply-To: mobile-ip@tadpole.com > > 5. Router discovery solicitation must have a TTL of 1. > > The intent is for solicitations not be routed, right? > This is already specified in router discovery (albeit indirectly). RFC > 1256 says that solicitations are sent to either of: > > o 224.0.0.2 > o 255.255.255.255 > > Neither address should ever be routed. this would seem to solve the problem. > So far so good. But what happens if an MN has subscribed to > broadcast service with its HA?... we never discussed broadcast during the testing. ergo, the minutes of the testing meeting don't discuss broadcast... > A related question: should HA's forward broadcast packets whose TTL > is 1? I could imagine most bcast traffic is set to TTL = 1, so wouldn't these die in the tunnels? > > 14. Issues surrounding the 'lifetime' of router advertisements arose. > > The technique which we all seemed to settle on was that the lifetime > > in the router-advertisement part of the agent-advertisement was the > > life of the agent advertisement -- that is, a mobile node would > > delete the entry from its list of known agents in that amount of time. > > The FA advertisement period should be 1/3 of the lifetime -- that is > > the time between fa advertisements should be 1/3 of the advert lifetime, > > so 3 advertisements in a row must be lost for the entry to time out. > > Shouldn't the advertisement period be *randomized* around 1/3 of the > lifetime? yeah. editorial glitch on my part. -- Frank Kastenholz ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@tadpole.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14763; 1 Dec 95 10:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14759; 1 Dec 95 10:14 EST Received: from tadpole.Tadpole.COM by CNRI.Reston.VA.US id aa12859; 1 Dec 95 10:14 EST Received: (from majordomo@localhost) by tadpole.tadpole.com (8.6.10/8.6.10) id JAA12117 for mobile-ip-dist; Fri, 1 Dec 1995 09:03:58 -0600 Received: from ftp.com (ftp.com [128.127.2.122]) by tadpole.tadpole.com (8.6.10/8.6.10) with SMTP id IAA11729 for ; Fri, 1 Dec 1995 08:36:00 -0600 Received: from ftp.com by ftp.com ; Fri, 1 Dec 1995 09:35:58 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 1 Dec 1995 09:35:58 -0500 Received: from kasten.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA03353; Fri, 1 Dec 95 09:32:58 EST Date: Fri, 1 Dec 95 09:32:58 EST Message-Id: <9512011432.AA03353@mailserv-D.ftp.com> To: mobile-ip@tadpole.com Subject: Re: (mobile-ip) Mobile IP Testing Report Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Repository: mailserv-D.ftp.com, [message accepted at Fri Dec 1 09:32:53 1995] Originating-Client: d-cell.ftp.com Content-Length: 2287 X-Orig-Sender: owner-mobile-ip@tadpole.com Precedence: bulk Reply-To: mobile-ip@tadpole.com > > 3. The specifications should say that the TTL of router advertisements > > unicast to a Mobile Node (as a response to a solicitation) must be 1 > > to prevent routing of the advertisement. > > Some implementations may need that, but my implementation does the right > thing regardless of the TTL, so I don't think this limitation is needed. > > It would be ok to put a more general statement in the spec, such as > "an implementation should make sure to send packets on the right interface", > although it seems like a fairly obvious requirement. > > In any case, the spec should not dictate the way implementators should > solve the problem. The point is that these responses should not propagate beyond the network where the Mobile-Node is. It is not a Mobility-Agent implementation issue. Rather it's the router. If the TTL is >1 then a router on the subnet might pick up the packet and start forwarding it towards the Mobile-Node's home subnet. Setting the TTL to 1 prevents any router on the foreign subnet from propagating these packets farther than they need to go. > > 4. If a FA is sending an IP unicast response to a router solicitation, > > it MUST be sent to the hardware address of the sender of the > > solicitation. > > Does this mean that the FA should learn the hardware address of the MH > through some other means than ARP? I don't think this is a good idea. > Why don't we then always remember the hardware source address of all > incoming IP packets, and not just Router Solicitations? I contend that > ARP should still be the method of choice for learning about hardware > addresses. ARP can be used. The point was that the FA should not send these responses using the MAC Broadcast or a MAC Multicast address. ARP can be used to get the MAC address for the MH. So could remembering the source MAC address of the solicitation. Magic is also allowed :-) We just thought that these unicast-responses should not be broad/multi- cast (since they are IP-Unicast; if they are MAC-Broad/Multi-cast then every node will receive them and all but the target node will discard them, wasting bandwidth which can be limited in a wireless environment, and also wasting battery power for wireless...) -- Frank Kastenholz ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@tadpole.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08717; 8 Dec 95 2:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08713; 8 Dec 95 2:14 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa03887; 8 Dec 95 2:14 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA09307; Fri, 8 Dec 1995 01:09:07 -0600 Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA09298; Fri, 8 Dec 1995 01:08:56 -0600 Date: Fri, 8 Dec 1995 01:08:56 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Thompson Message-Id: <9512080708.AA09298@hosaka.smallworks.com> To: mobile-ip@smallworks.com Subject: (mobile-ip) Administrivia X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Jim Thompson The mobile-ip list has now moved to smallworks.com. (From tadpole.com, since I no longer work there, and have grown a little tired of administrating the list remotely via majordomo. Thus, the move. Also, the 'Reply-to:' field should be set to the name of the sender now, instead of being set to the name of the list. Jim ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12483; 11 Dec 95 13:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12478; 11 Dec 95 13:11 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa25785; 11 Dec 95 13:11 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA18045; Mon, 11 Dec 1995 11:42:28 -0600 Received: from motgate.mot.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA18035; Mon, 11 Dec 1995 11:42:19 -0600 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.7.1/8.6.10/MOT-3.8) with ESMTP id LAA27037 for ; Mon, 11 Dec 1995 11:42:16 -0600 (CST) Received: from il02dns1.comm.mot.com ([145.1.3.2]) by pobox.mot.com (8.7.1/8.6.10/MOT-3.8) with ESMTP id LAA09404 for ; Mon, 11 Dec 1995 11:42:15 -0600 (CST) Received: from becks.comm.mot.com (becks.comm.mot.com [145.1.80.10]) by il02dns1.comm.mot.com (8.7.2/8.7.2) with SMTP id LAA19854 for ; Mon, 11 Dec 1995 11:42:16 -0600 (CST) Received: from localhost by becks.comm.mot.com (4.1/SMI-4.1) id AA13320; Mon, 11 Dec 95 11:43:12 CST Message-Id: <9512111743.AA13320@becks.comm.mot.com> To: mobile-ip@smallworks.com Cc: solomon@becks.comm.mot.com Subject: (mobile-ip) Extension "Name Spaces" Date: Mon, 11 Dec 1995 11:43:06 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "James D. Solomon" X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: "James D. Solomon" Greetings, I'm still cleaning up the minutes from the Dallas sessions and hope to get them out by mid-week. One of the issues came up was that of the "name space" from which we are allocating extension "Type" values for Mobile IP. The current draft suggests that all extension "Type" numbers are allocated from a single, contiguous name space: 0 One-Byte Pad [1-15 Unused] 16 Mobile Service [17-18 Unused] 19 Prefix Lengths [20-31 Unused] 32 Mobile-Home Authentication 33 Mobile-Foreign Authentication 34 Foreign-Home Authentication [35-255 Unused] Dave Johnson suggested, and the working group agreed, that this is misleading in that we are really allocating extension Type numbers from two orthogonal spaces: Extension Space #1: | Extension Space #2 (ICMP Router Advertisement) | (Mobile IP Registration) ------------------------------+------------------------------------ 0 One-Byte Pad | [0-31 Unused] [1-15 Unused] | 32 Mobile-Home Authentication 16 Mobile Service | 33 Mobile-Foreign Authentication [17-18 Unused] | 34 Foreign-Home Authentication 19 Prefix Lengths | [35-255 Unused] [20-255 Unused] | Equivalently stated, the extensions we've defined thus far apply only to _either_ ICMP Router Advertisement messages _or_ to Mobile IP Registration Requests/Replies -- but _not_ to both! If someone in the future desires to define an extension that applies only to ICMP Router Advertisement, he need only examine space #1 to find an unallocated Type value. That is, today he _could_ select Type = 32 because it does not matter if he chooses the same number as an extension which only has meaning in the Mobile IP space (space #2). For this reason, the "two orthogonal spaces" method seems to be more appropriate and we reached consensus in Dallas that this should be the model. With this long-winded introduction, my question is as follows: Should the current extension values be renumbered to drive this point home? That is, should we give at least one extension in space #1 an itentical "Type" number to an extension defined in space #2? Thanks, Jim S. ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13695; 11 Dec 95 14:06 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13691; 11 Dec 95 14:06 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa10461; 11 Dec 95 14:06 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA18331; Mon, 11 Dec 1995 12:54:49 -0600 Received: from watson.ibm.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA18325; Mon, 11 Dec 1995 12:54:41 -0600 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0737; Mon, 11 Dec 95 13:54:22 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 5112; Mon, 11 Dec 1995 13:54:22 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Mon, 11 Dec 95 13:54:21 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA34920; Mon, 11 Dec 1995 13:54:46 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Charlie Perkins Message-Id: <9512111854.AA34920@hawpub1.watson.ibm.com> To: "James D. Solomon" Cc: mobile-ip@smallworks.com Subject: Re: (mobile-ip) Extension "Name Spaces" In-Reply-To: (Your message of Mon, 11 Dec 95 11:43:06 CST.) <9512111743.AA13320@becks.comm.mot.com> Date: Mon, 11 Dec 95 13:54:46 -0500 X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Charlie Perkins I thought that the working group specifically decided that even though the name spaces were to be separate, and thus eventually susceptible to overlaps in the numbering scheme, that for now we would make no changes in the actual numbers which were assigned to current extensions. I do remember that the question was specifically asked, and I remember that I suggested that the numbers should not change, and I thought there was consensus agreement on the point (and no disagreement). > One of the issues came up was that of the "name space" from which we > are allocating extension "Type" values for Mobile IP. The current > draft suggests that all extension "Type" numbers are allocated from a > single, contiguous name space: > > 0 One-Byte Pad > [1-15 Unused] > 16 Mobile Service > [17-18 Unused] > 19 Prefix Lengths > [20-31 Unused] > 32 Mobile-Home Authentication > 33 Mobile-Foreign Authentication > 34 Foreign-Home Authentication > [35-255 Unused] > > Dave Johnson suggested, and the working group agreed, that this is > misleading in that we are really allocating extension Type numbers > from two orthogonal spaces: > > Extension Space #1: | Extension Space #2 > (ICMP Router Advertisement) | (Mobile IP Registration) > ------------------------------+------------------------------------ > 0 One-Byte Pad | [0-31 Unused] > [1-15 Unused] | 32 Mobile-Home Authentication > 16 Mobile Service | 33 Mobile-Foreign Authentication > [17-18 Unused] | 34 Foreign-Home Authentication > 19 Prefix Lengths | [35-255 Unused] > [20-255 Unused] | > > Equivalently stated, the extensions we've defined thus far apply only > to _either_ ICMP Router Advertisement messages _or_ to Mobile IP > Registration Requests/Replies -- but _not_ to both! If someone in the > future desires to define an extension that applies only to ICMP Router > Advertisement, he need only examine space #1 to find an unallocated > Type value. That is, today he _could_ select Type = 32 because it > does not matter if he chooses the same number as an extension which > only has meaning in the Mobile IP space (space #2). For this reason, > the "two orthogonal spaces" method seems to be more appropriate and we > reached consensus in Dallas that this should be the model. > > With this long-winded introduction, my question is as follows: Should > the current extension values be renumbered to drive this point home? > That is, should we give at least one extension in space #1 an > itentical "Type" number to an extension defined in space #2? > > Thanks, > Jim S. Charlie P. ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15500; 11 Dec 95 16:06 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15496; 11 Dec 95 16:06 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa12832; 11 Dec 95 16:06 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA19088; Mon, 11 Dec 1995 14:53:03 -0600 Received: from ftp.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA19082; Mon, 11 Dec 1995 14:52:54 -0600 Received: from ftp.com by ftp.com ; Mon, 11 Dec 1995 15:52:47 -0500 Received: from mailserv-C.ftp.com by ftp.com ; Mon, 11 Dec 1995 15:52:47 -0500 Received: from elsinore ([128.127.233.4]) by mailserv-C.ftp.com (5.0/SMI-SVR4) id AA15743; Mon, 11 Dec 95 15:50:52 EST Message-Id: <9512112050.AA15743@mailserv-C.ftp.com> X-Sender: glass@128.127.2.120 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Dec 1995 15:48:03 -0500 To: "James D. Solomon" , mobile-ip@smallworks.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Glass Subject: Re: (mobile-ip) Extension "Name Spaces" Cc: solomon@becks.comm.mot.com X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Steve Glass At 11:43 12/11/95 -0600, James D. Solomon wrote: The accurate naming convention we have in place: >two orthogonal spaces: > > Extension Space #1: | Extension Space #2 > ICMP Router Advertisement | Mobile IP Registration >---------------------------+----------------------------------- > 0 One-Byte Pad | 0-31 Unused > 1-15 Unused | 32 Mobile-Home Authentication > 16 Mobile Service | 33 Mobile-Foreign Authentication > 17-18 Unused | 34 Foreign-Home Authentication > 19 Prefix Lengths | 35-255 Unused > 20-255 Unused | >we reached consensus in Dallas that this should be the model. Actually we agreed that this IS the current model. Since these name (number) spaces have a NULL intersection, your point that they may be wrongly viewed as a single, contiguous name space is valid since they are both mentioned together in the doc. >Should the current extension values be renumbered to drive this >point home (that is, should we give at least one extension in >space #1 an itentical "Type" number to an extension defined in >space #2? What this would do is force proper coding to ensure correct parsing of the name spaces (read: implementing the spec). I believe we agreed to have these two name spaces mentioned separately in the document. With that done there would be no confusion, so renumbering one (or both) of them is not necessary. Cheers, Steve ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19653; 11 Dec 95 21:38 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19649; 11 Dec 95 21:38 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa17740; 11 Dec 95 21:38 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA20708; Mon, 11 Dec 1995 20:26:39 -0600 Received: from mercury.Sun.COM by hosaka.smallworks.com (5.x/SMI-SVR4) id AA20701; Mon, 11 Dec 1995 20:26:26 -0600 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id SAA07276; Mon, 11 Dec 1995 18:26:25 -0800 Received: from jadeite.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA21481; Mon, 11 Dec 1995 18:26:21 -0800 Received: from cali by jadeite.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA21158; Mon, 11 Dec 1995 18:26:13 -0800 Date: Mon, 11 Dec 1995 18:26:20 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gabriel Montenegro Subject: Re: (mobile-ip) Extension "Name Spaces" To: mobile-ip@smallworks.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Gabriel Montenegro > With this long-winded introduction, my question is as follows: Should > the current extension values be renumbered to drive this point home? I think it's great that this is getting documented. Other than that, I cast my vote for not renumbering. -gabriel ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05432; 12 Dec 95 0:32 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05428; 12 Dec 95 0:32 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa01717; 12 Dec 95 0:32 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA21266; Mon, 11 Dec 1995 23:27:08 -0600 Received: from CHIMAY.MACH.CS.CMU.EDU by hosaka.smallworks.com (5.x/SMI-SVR4) id AA21260; Mon, 11 Dec 1995 23:27:00 -0600 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa20254; 12 Dec 95 0:26:20 EST To: "James D. Solomon" Cc: mobile-ip@smallworks.com In-Reply-To: Your message of "Mon, 11 Dec 95 11:43:06 CST" <9512111743.AA13320@becks.comm.mot.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Johnson Subject: Re: (mobile-ip) Extension "Name Spaces" Date: Tue, 12 Dec 95 00:25:20 EST Message-Id: <20252.818745920@CHIMAY.MACH.CS.CMU.EDU> X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Dave Johnson >Equivalently stated, the extensions we've defined thus far apply only >to _either_ ICMP Router Advertisement messages _or_ to Mobile IP >Registration Requests/Replies -- but _not_ to both! If someone in the >future desires to define an extension that applies only to ICMP Router >Advertisement, he need only examine space #1 to find an unallocated >Type value. That is, today he _could_ select Type = 32 because it >does not matter if he chooses the same number as an extension which >only has meaning in the Mobile IP space (space #2). For this reason, >the "two orthogonal spaces" method seems to be more appropriate and we >reached consensus in Dallas that this should be the model. Finally! :-) I've brought this up at several other meetings in the past, too... >With this long-winded introduction, my question is as follows: Should >the current extension values be renumbered to drive this point home? >That is, should we give at least one extension in space #1 an >itentical "Type" number to an extension defined in space #2? I don't think this is really necessary, as long as the document clearly identifies the two "spaces". I think you've explained it very well in your mail, and I expect it will end up equally (or more) clear in the draft, so renumbering the types isn't necessary. I only suggested this in Dallas so as to drive home the point in the meeting. Dave ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17423; 12 Dec 95 14:56 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17418; 12 Dec 95 14:56 EST Received: from [192.207.126.1] by CNRI.Reston.VA.US id aa15331; 12 Dec 95 14:56 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA24133; Tue, 12 Dec 1995 13:34:44 -0600 Received: from ftp.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA24127; Tue, 12 Dec 1995 13:34:33 -0600 Received: from ftp.com by ftp.com ; Tue, 12 Dec 1995 14:34:32 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 12 Dec 1995 14:34:32 -0500 Received: from kasten.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA12727; Tue, 12 Dec 95 14:31:24 EST Date: Tue, 12 Dec 95 14:31:24 EST Message-Id: <9512121931.AA12727@mailserv-D.ftp.com> To: "James D. Solomon" Subject: Re: (mobile-ip) Extension "Name Spaces" Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Cc: mobile-ip@smallworks.com Repository: mailserv-D.ftp.com, [message accepted at Tue Dec 12 14:31:15 1995] Originating-Client: d-cell.ftp.com X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Frank Kastenholz > With this long-winded introduction, my question is as follows: Should > the current extension values be renumbered to drive this point home? > That is, should we give at least one extension in space #1 an > itentical "Type" number to an extension defined in space #2? I don't recall the meeting deciding one way or the other. I'd note that there are implementations of the current (+/-) drafts. Though not shipping ones. Yes, I know that they are just #defines someplace. But still, the less churn the better. -- Frank Kastenholz ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25997; 13 Dec 95 20:32 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25993; 13 Dec 95 20:32 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa22260; 13 Dec 95 20:32 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA00143; Wed, 13 Dec 1995 19:19:27 -0600 Received: from alpha.xerox.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA00133; Wed, 13 Dec 1995 19:19:14 -0600 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15314(3)>; Wed, 13 Dec 1995 17:19:01 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 13 Dec 1995 17:18:53 -0800 To: mobile-ip@smallworks.com Cc: deering@parc.xerox.com Subject: (mobile-ip) old mobile-ip archives Date: Wed, 13 Dec 1995 17:18:39 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Deering Message-Id: <95Dec13.171853pst.75270@digit.parc.xerox.com> X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Steve Deering As part of end-of-year cleaning, I am planning to delete the mobile-ip WG archive that I maintained from June '92 to Oct '93, which is sitting in parcftp.xerox.com/pub/mobile-ip/. Here is the list of files, in case the current archivist or anyone else wishes to grab copies before they go away. I will delete them on December 22. -rwxrwxr-x 1 deering 765068 Oct 16 1993 admin* -rwxrwxr-x 1 deering 1897 Nov 7 1992 charter* -rwxrwxr-x 1 deering 53939 Jul 11 1993 cmu-mobile.txt* -rwxrwxr-x 1 deering 104971 Jun 25 1992 columbia-draft-june-92* -rwxrwxr-x 1 deering 280990 Nov 7 1992 columbia-slides-july-92.ps* -rwxrwxr-x 1 deering 51901 Feb 15 1993 ibm-draft-jan-93* -rwxrwxr-x 1 deering 46518 Jul 17 1992 ibm-draft-july-92* -rwxrwxr-x 1 deering 48407 Oct 28 1992 ibm-draft-oct-92* -rwxrwxr-x 1 deering 112609 Jun 11 1993 ibm-jenc4.ps* -rwxrwxr-x 1 deering 52849 Jun 11 1993 ibm-jenc4.txt* -rwxrwxr-x 1 deering 240082 Jun 17 1993 ibm-mobile-architecture.ps* -rwxrwxr-x 1 deering 288530 Aug 4 1993 ibm_umlis.ps* -rwxrwxr-x 1 deering 96935 Oct 15 1993 imhp.txt* -rwxrwxr-x 1 deering 532598 Oct 16 1993 mail-archive* -rwxrwxr-x 1 deering 417195 May 16 1993 mail-archive-1992* -rwxrwxr-x 1 deering 596760 Oct 10 1993 mail-archive-1993-1st-half* -rwxrwxr-x 1 deering 18077 Oct 16 1993 mailing-list* -rwxrwxr-x 1 deering 55592 Nov 14 1992 matsushita-draft-nov-92* -rwxrwxr-x 1 deering 58871 Feb 15 1993 matsushita-slides-nov-92.ps.Z* -rwxrwxr-x 1 deering 10941 Jun 9 1992 minutes-atlanta-91* -rwxrwxr-x 1 deering 3656 Jun 9 1992 minutes-san-diego-92* -rwxrwxr-x 1 deering 14534 Jun 9 1992 minutes-santa-fe-91* -rwxrwxr-x 1 deering 99522 Oct 13 1993 mobile-ip-draft.txt* -rwxrwxr-x 1 deering 670895 Jun 18 1993 myles-comparison.ps.Z* -rwxrwxr-x 1 deering 188953 Jul 5 1992 myles-critique-july-92.ps* -rwxrwxr-x 1 deering 1324308 Sep 8 1993 perkins-myles-mip.ps* -rwxrwxr-x 1 deering 64489 Sep 29 1993 perkins-myles-mip.txt* -rwxrwxr-x 1 deering 577075 Nov 7 1992 sony-slides-july-92.ps* Steve ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00379; 13 Dec 95 23:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00375; 13 Dec 95 23:11 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa00440; 13 Dec 95 23:11 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA00650; Wed, 13 Dec 1995 22:03:38 -0600 Received: from motgate.mot.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA00639; Wed, 13 Dec 1995 22:02:36 -0600 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.7.1/8.6.10/MOT-3.8) with ESMTP id WAA27517; Wed, 13 Dec 1995 22:02:34 -0600 (CST) Received: from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by pobox.mot.com (8.7.1/8.6.10/MOT-3.8) with ESMTP id WAA11730; Wed, 13 Dec 1995 22:02:32 -0600 (CST) Received: from becks.comm.mot.com (becks.comm.mot.com [145.1.80.10]) by il02dns1.comm.mot.com (8.7.2/8.7.2) with SMTP id WAA11881; Wed, 13 Dec 1995 22:02:34 -0600 (CST) Received: from localhost by becks.comm.mot.com (4.1/SMI-4.1) id AA18574; Wed, 13 Dec 95 22:03:28 CST Message-Id: <9512140403.AA18574@becks.comm.mot.com> To: minutes@CNRI.Reston.VA.US Cc: mobile-ip@smallworks.com Subject: (mobile-ip) Mobile IP Working Group Minutes, Dallas IETF Date: Wed, 13 Dec 1995 22:03:26 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "James D. Solomon" X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: "James D. Solomon" -----BEGIN PGP SIGNED MESSAGE----- Mobile IP MINUTES Dallas IETF, December 1995 Reported by Jim Solomon The Mobile IP working group met twice at the Dallas IETF. The first meeting was focussed on IPv4 mobility and the second was primarily concerned with IPv6 mobility. The organization of these minutes is by topic area: IPv4 then IPv6. IPv4 Mobility ============= Administrative Note: The Mobile IP mailing list has moved. The new location is as follows: General Discussion: mobile-ip@smallworks.com To Subscribe: majordomo@smallworks.com In Body: subscribe mobile-ip Many thanks to Jim Thompson for continuing to maintain the mailing list. 1) Patent Issues The outstanding patent issues facing Mobile IP have been solved: a) Perkins Patent. Tony read the summary of the opinion from Hale & Dorr, the law firm hired with ISOC funds to determine the scope-of-infringement of Mobile IP with respect to IBM Patent #5,159,592. The working group being generally pleased with the opinion has decided to publish the specification "as is" (i.e. no major substantive changes) and pursue PS RFC. The opinion from Hale & Dorr will be published as the appendix in the specification. b) Nonce Patent. It has been difficult to obtain a specific statement from IBM as to whether this patent is being asserted as relevant to Mobile IP. A proposal to mandate the use of timestamps, while allowing the optional use of nonces, was accepted by the working group. 2) Spec. Issues a) Requirements of FA location with respect to MN (i.e. "one hop away") and of HA location with respect to MN's home network (i.e. "must have an interface on") are never specified. Dave Johnson will supply text to the author. b) Temporary COA -- similar comment as in (a), namely, What's the relation between the COA and the MN's current location? Dave Johnson will supply text here as well. c) Extensions are being defined by this WG that apply to either ICMP Router Advertisement or Registration messages -- but not to both. It should be clear that the Extension values for each of these come from respectively separate numbering spaces. That is, an Extension intended only for ICMP Router Advertisements (e.g. Mobile Service Extension) and an Extension intended only for Registration Requests (e.g. Mobile-Home Authentication Extension), could both have the same Extension number. This should be clarified in the document. The working group decided not to renumber the extenstion Type values. d) The document should say that the advertising period should be NOMINALLY 1/3 of the Lifetime in the RFC1256-portion of the Agent Advertisement. e) Can an Agent Advertisement contain zero Router Addresses? The consensus is "yes, it can". In such a case, the MN MAY use the IP source address of the Agent Advertisement as a default router. If the "Num Addrs" is non-zero, then a default router MAY be chosen according to the rules of RFC1256 wherein the IP source address of the Agent Advertisement is interpreted to be the "worst" choice for address of a default router. f) FAs MUST be routers, that is, an MN must be capable of communicating by sending its packets through the FA to which it has registered. g) Solicitations SHOULD be rate-limited more so than the once per second currently specified in the draft. For example, exponential backoff was suggested. Dave Johnson will supply text to the editor. h) There was much discussion about the usefulness of prefixes for MN move detection in wireless environments where subnets can overlap. Tony Li and Charlie Perkins will put suitable text in the draft to discourage the use of prefixes in environments (e.g. certain wireless configurations) where they could lead to problems. i) Timestamp replay protection is broken. Two registrations with different COAs but both timestamps within the synchronization window would cause the wrong mobility binding to be current at the HA. As an additional rule, the HA must not accept any timestamp from an MN that is less than the currently accepted one. j) Usage of ARP is underspecified or downright broken: 1) Consider an MN that is not within the wireless range of its HA (and thus registers with an FA) but is within the wireless range of a CH on its home network. If the MN hears the CH's ARP and answers it, problems can arise if the MN then moves out of the range of the CH. Thus, while registered with an FA, the MN MUST NOT answer ARPs from any nodes other than that FA. 2) The ordering of operations when a MN leaves home and/or returns home is underspecified/wrong. When a mobile node leaves its home network and detects movement to a foreign network, the following sequence should occur: - MN stops answering ARPs - MN sends Registration Request - if HA accepts registration, it: a) sends gratuitous ARPs for the MN b) starts Proxy ARPing for the MN endif - HA sends Registration Reply. When an MN returns home, the following ordering occurs: - MN begins answering ARPs - MN sends gratuitous ARP(s) - MN sends Registration Request(s) - if HA accepts registration, it: a) stops Proxy ARPing for the MN b) sends gratuitous ARPs for the MN endif - HA sends Registration Reply. k) Some confusion was detected with regard to mobile routers. The language in the draft should perhaps be clarified in this regard. l) Validity checks in 3.6.2.1 are wrong with respect to receiving Registration Replies with a Code indicating a rejection by the FA. In this case, no MN/HA authenticator is likely to be found and, instead, an MN/FA authenticator must appear if the MN and FA share a security association. Jim Solomon to supply text. m) A suggestion was made that an FA provide tunneling in the reverse direction to provide location privacy for MNs. It was determined that this needed much more protocol mechanism and is a good topic for discussion on the mailing list. That is, it will be deferred until after the current draft goes PS. n) A suggestion was made to provide a mechanism to supply a node with an indication of WHICH extension was unrecognized or malformed. It was decided that at the time extensions are defined, the mechanism by which error reporting occurs (e.g. new code field, a general-purpose "bad extension" extension) should be defined as well. o) The current language in the draft states that if an MN sets the 'B' bit in a Registration Request then it will receive a copy of "all" broadcasts on the home net. The spec. should say that it is a matter of configuration at the HA as to which broadcasts get tunneled to the MN. 3) Mobile IP Applicability Statement. An applicability statement, as required for advancement of Mobile IP to Proposed Standard RFC (cf RFC1264), has been written by Jim Solomon and will be submitted as an I-D early next week. 4) Mobile IP MIB(s). David Cong and Mark Hamlen of Motorola have written a draft MIB for Mobile IP which will also be submitted early next week as an I-D. The group agreed to appoint the forementioned as working group editors of the MIB document. Charlie Perkins has agreed to assist in this effort. 5) Advancement to Proposed Standard RFC. All the requirements of RFC1264 have been (nearly) completed. Thus, when Charlie updates the draft, a working group last call will be issued, followed by submission of the draft to the IESG. Minimum Encapsulation could be advanced as an Informational RFC but "IP in IP" encapsulation MUST be advanced on the standards track. The co-chairs will consult with the Routing Area Director as for the rules for advancing IP in IP Encapsulation along the standards track. 6) Other Topics The following topics were discussed which are not part of the base technical specification but are nonetheless important to the Mobile IP working group: a) Route Optimization Dave Johnson presented the route optimization proposal as defined in draft-ietf-mobileip-optim-03.txt. The proposal involves a mechanism for distributing authentic binding information to correspondents of mobile nodes. The key distribution problem is mitigated by having authenticated bindings sent by the home agent rather than the mobile nodes themselves. The authors stressed the need for feedback on their proposal from the members of the Mobile IP working group. b) DHCP Extension Charlie Perkins presented a new option to DHCP for Mobile Home addresses for IPv4. DHCP currently provides an IP address for the local subnet. The new option requests an address that the mobile can use as a home address as well as an address of a home agent. The value of the option is 68. More investigation is required to determine how the mobile node and home agent can be set up with a security association. c) IP Squared Kazuhiro Okanoue presented his work on route optimization using Double-IP Headers (IP Squared) based on the Sony VIP work. This proposal uses IP concatenation, which uses an encapsulating IP header with the same protocol number. Statistically, it would be possible to differentiate this from the real data. IP concatenation is used by the mobile node to send data. All intermediate routers learn that the sender of the data is indeed a mobile node and then cache its care-of address. Such routers can then shortcut the routes to mobile nodes. d) Virtual Home Agents Dave Johnson presented a method on how to solve the problem of crashing home agents. This approach uses an extra address for home agents, which elect a "real" home agent from among the group. Tony Li noted that Cisco has a patent pending which might be relevant to this technology. e) Hierarchical Foreign Agent Charlie Perkins presented a method for short-cutting the registration process by registering a list of foreign agents that form a hierarchical tree. When moving among leaves in the tree, registration messages need only be sent back as far as the common branching node within the tree. IPv6 Mobility ============= Charlie Perkins presented an overview of his and Dave Johnson's IPv6 Mobility draft (see draft-perkins-ipv6-mobility-sup-02.txt). The working group reached consensus that this is the architectural framework to be adopted for IPv6 moving forward. Future revisions of the IPv6 mobility draft will thus be "official working group" documents. The remainder of these minutes summarize Charlie's presentation (notes taken by Tony Li): - Port IPv4 Mobile IP proposal over to IPv6, but add allowances for IPv6 flexibility. There is no installed base. Authentication is built into all nodes. We can include route optimization for effectively no cost because of authentication. - Foreign Agents are still useful in IPv6. They can do authentication, charge for connection services, produce or share a session key for new clients, negotiate compression, manage the local router. - Tunneling can use an IPv6 routing header. It provides a loose/strict source route, but done right and can be done in any packet. We may still want to do tunneling because the header is authenticated and thus only the source can insert a header into the packet. - Binding updates are new and come from the IPv4 route optimization proposal. The HA is responsible for updating the previous foreign agent and the correspondent node. Only the mobile node sends binding updates. - A binding update fits in a destination option. You can still register with your home agent to establish location. The MN still needs to register with the FA, so the registration is encapsulated and forwarded to the FA, and then relayed to the HA. - The FA can decapsulate incoming packets if they are encapsulated. The MN sends updates to CH, without acknowledgment. No routing header indicates that a binding is necessary. - Binding updates should be rate limited. Estimate the RTT and use this as an approximation for a rate at which to limit. One MAY send updates to all open TCP connections. - To do: Define binding update destination option Define binding ACK packet or option All nodes must be able to process them All nodes must be able to use and maintain a binding cache All nodes must be able to tunnel their own packets Insure that authentications works during registration - Issues: Interaction with IPv4 correspondents and (!) mobile mobiles Hop count limitations may halve the diameter of reachability Should beacons be on a separate multicast address for performance of non-mobile hosts? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMM+hiPu0ATQfF/PpAQFs1QP+PF4U2rW8GcuAYG0K7jFbpf/CjtzexiEJ ivKpKlelf2OlDiQKQYa5qCDRZTdI9V3NsIoNa3/9qQUK3KHvXL/t990/NW4Nfjws LL9UJqKDro6lUxV+V50mt2qT08fKICP2iF+GXHnENGxGfv7z1QbQJe66Xvq/zTCl 0bo4iAqRIpo= =bR0l -----END PGP SIGNATURE----- ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25768; 14 Dec 95 18:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25764; 14 Dec 95 18:47 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa19773; 14 Dec 95 18:47 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA03870; Thu, 14 Dec 1995 17:39:54 -0600 Received: from sics.se by hosaka.smallworks.com (5.x/SMI-SVR4) id AA03860; Thu, 14 Dec 1995 17:39:45 -0600 Received: from reshef.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA26030; Fri, 15 Dec 95 00:39:43 +0100 Received: by reshef.sics.se (5.65+bind 1.7+ida 1.4.2/SICSclient-1.1) id AA12755 (for mobile-ip@smallworks.com); Fri, 15 Dec 95 00:39:42 +0100 Date: Fri, 15 Dec 95 00:39:42 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: klemets@sics.se Message-Id: <9512142339.AA12755@reshef.sics.se> To: mobile-ip@smallworks.com Subject: Re: (mobile-ip) Mobile IP Working Group Minutes, Dallas IETF X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: klemets@sics.se > Dave Johnson presented the route optimization proposal A thing that apparently was not discussed in the meeting is whether the current way of doing simultaneous registrations is such a good thing. I talked to Dave about this last month, and we seemed to agree on that it is not very nice to have the HA send N copies of each packet if a MN is registered N times. The route optimization proposal says that if a HA receives a packet that arrived through a "special tunnel", it should drop the packet if decapsulating it would cause it to be forwarded to the source of the special tunnel. Reading between the lines and translating this to a scenario that involves multiple registrations means that HA must check if any of the N copies of the packet would be sent back to the source of the special tunnel. If so, the HA should decapsulate the packet anyway, but make sure that it is only forwarded through the other N-1 tunnels. I could not implement this in a clean fashion in my code. It would be interesting to hear how you other guys with implementations have addressed this issue. Perhaps it would be better to replace the current unicast based scheme for simultaneous registrations with one that uses multicast? For instance, the HA would tunnel the packet to one FA, who would multicast the encapsulated packet to the other FA's. I am proposing that the current method of doing simultaneous registrations is removed from the base spec, and that the working group should try to come with a better way of doing simultaneous registrations (probably using multicast), which would then be published as a separate RFC. As currently specified, simultaneous registrations are already optional, so publishing it as a separate document should be no different. Also, since simultaneous registrations were not tested in the interoperability testing meeting, it seems wrong to include it in the proposed standard. Flaky implementations with a too high upper bound on N can cause a lot of problems on the Internet. Anders ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17221; 15 Dec 95 13:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17217; 15 Dec 95 13:37 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa13965; 15 Dec 95 13:37 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA07964; Fri, 15 Dec 1995 12:25:55 -0600 Received: from watson.ibm.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA07958; Fri, 15 Dec 1995 12:25:47 -0600 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4261; Fri, 15 Dec 95 13:24:24 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 7773; Fri, 15 Dec 1995 13:24:24 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Fri, 15 Dec 95 13:24:23 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA28177; Fri, 15 Dec 1995 13:24:52 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Charlie Perkins Message-Id: <9512151824.AA28177@hawpub1.watson.ibm.com> To: TERAOKA Fumio Cc: mobile-ip@smallworks.com Subject: Re: (mobile-ip) Mobile IP Working Group Minutes, Dallas IETF In-Reply-To: (Your message of Sat, 16 Dec 95 01:31:41 V.) <199512151631.BAA12507@tera.csl.sony.co.jp> Date: Fri, 15 Dec 95 13:24:52 -0500 X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Charlie Perkins > Since I couldn't attend the mobile-ip sessions in Dallas IETF, > I couldn't give my opinion at the sessions. > > I disagree with draft-perkins-ipv6-mobility-sup-02.txt. This protocol > is an extension of mobile-IP for IPv4, and uses both encapsulation and > source routing. Therefore, it has several problems as follows: More properly, one should say that it is a great simplification of the IPv4 mobility framework, using features that are available in IPv6. > - From network architecture viewpoint, the protocol violates the subnet > model. Subnets served by FAs are not normal IPv6 subnets. > (Remember that communication between a FA and an MN is data-link > layer communication, not IP layer communication.) First, the proposal specifies that all routers must be able to perform mobility functions, so that all routers can be (the IPv6 analog of) foreign agents. Second, as detailed in the not-yet-released revision to our last draft, mobile nodes may acquire their own care-of addresses and not be constrained to use those offered by routers. This ability is also available in IPv4, but the IPv6 automatic address configuration makes it a lot more convenient than in IPv4. Third, any IP mobility solution is going to violate the subnet model somewhere, even if the violation occurs internally during a node's protocol stack processing. > - It is not elegant to use both encapsulation and source routing. > The IPv6 header of a packet send by CN is processed by routers > when source routing is used, while it is not processed by routers > when encapsulation is used. Almost all packets in IPv6 destined to a mobile node will use a routing header. That part is very elegant. In the rare case, a home agent is required to use encapsulation because it may be messy to insert routing headers in someone else's packet. Are you suggesting that it is more elegant to always require encapsulation, even though it's more expensive to do so? > - From technical viewpoint, multicast routing based on reverse path > forwarding cannot be applied to multicast packets sent by an MN > because the source address field of the packet does not indicate > the correct location of the MN. My intention is to use the same mechanism for IPv6 as is specified for IPv4. If the IPv4 mechanism is broken, then we should fix that right away. > - Packets sent by an MN might be discarded by a router that filters out > packets with illegal source addresses. This is a problem. A solution is for the mobile node to send out encapsulated packets using its care-of address as the source address in the outer packet header. This will work better for IPv6, if we assume that all nodes need to be able to handle IPv6 encapsulated packets. I'm hoping that's a valid assumption. > Fumio TERAOKA (SonyCSL) Charlie P. ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19057; 15 Dec 95 14:31 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19053; 15 Dec 95 14:31 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa15196; 15 Dec 95 14:31 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA08357; Fri, 15 Dec 1995 13:21:24 -0600 Received: from tadpole.tadpole.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA08351; Fri, 15 Dec 1995 13:21:12 -0600 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by tadpole.tadpole.com (8.6.10/8.6.10) with SMTP id NAA23487 for ; Fri, 15 Dec 1995 13:21:10 -0600 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17965; 15 Dec 95 14:09 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, SmallWorks.COM@CNRI.Reston.VA.US MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: mobile-ip@tadpole.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Subject: (mobile-ip) I-D ACTION:draft-ietf-mobileip-appl-00.txt Date: Fri, 15 Dec 95 14:09:24 -0500 Message-Id: <9512151409.aa17965@IETF.CNRI.Reston.VA.US> X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Internet-Drafts@CNRI.Reston.VA.US --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Applicability Statement for IP Mobility Support Author(s) : J. Solomon Filename : draft-ietf-mobileip-appl-00.txt Pages : 5 Date : 12/14/1995 As required by [RFC 1264], this draft report discusses the applicability of Mobile IP to provide host mobility in the Internet. The final form of this draft report is a prerequisite to advancing Mobile IP on the standards track. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-appl-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-appl-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-appl-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951215135804.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-appl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-appl-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951215135804.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13464; 20 Dec 95 11:01 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13460; 20 Dec 95 11:01 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa03087; 20 Dec 95 11:01 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA03676; Wed, 20 Dec 1995 09:54:42 -0600 Received: from motgate.mot.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA03670; Wed, 20 Dec 1995 09:54:29 -0600 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.7.1/8.6.10/MOT-3.8) with ESMTP id JAA21994; Wed, 20 Dec 1995 09:54:22 -0600 (CST) Received: from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by pobox.mot.com (8.7.1/8.6.10/MOT-3.8) with ESMTP id JAA14514; Wed, 20 Dec 1995 09:54:21 -0600 (CST) Received: from becks.comm.mot.com (becks.comm.mot.com [145.1.80.10]) by il02dns1.comm.mot.com (8.7.2/8.7.2) with SMTP id JAA29512; Wed, 20 Dec 1995 09:54:22 -0600 (CST) Received: from localhost by becks.comm.mot.com (4.1/SMI-4.1) id AA20610; Wed, 20 Dec 95 09:55:19 CST Message-Id: <9512201555.AA20610@becks.comm.mot.com> To: Jiang Ming Liang Cc: mobile-ip@smallworks.com Subject: Re: (mobile-ip) A Question Abt the Structure of Home Network In-Reply-To: Your message of "Wed, 20 Dec 1995 20:39:11 +0800." Date: Wed, 20 Dec 1995 09:55:19 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "James D. Solomon" X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: "James D. Solomon" In message , Jiang Ming Liang writes: > While reading the working group's draft-13, I found this point > not very clear. On page 31, it is said that when a mobile node comes > home it no longer needs the service of its home agent. If that is > the case and the mobile node is still served on the subnet by > another router, then the router must have a wireless interface and > then it is likely that the whole subnet is a wireless subnet by > which I mean that every host on the subnet is communicating with the > default router using a wireless network card. And that does not seem > to be necessary. There are three _primary_ cases: 1) The home network is virtual (i.e. not physically realized anywhere) in which case the mobile node is _never_ at home. This is an uninteresting case given your question. 2) The home network is not virtual wherein the home agent is also a good choice as a default router for hosts on the home network. For example: | +----+ +--| FH | | +----+ +----+ | [ Internet ] ----| HA |---+ (home network) +----+ | | ...... |..: MN : | :....: In this case, when the mobile node is on its home network, it does indeed function without "mobility services". However, it _does_ require the box labeled "HA" to act as a "default router" in order to communicate with the outside world. In this case the HA is acting as a "router" to the MN, not as a "home agent". Note that the media that comprises the home network can be anything, not necessarily wireless. 3) The home network is not virtual wherein the home agent is not a good choice for a default router for hosts on the home network. For example: | +----+ +--| FH | | +----+ | | +----+ +--| HA | | +----+ +---+ | [ Internet ] ----| R |---+ (home network) +---+ | | ...... |..: MN : | :....: In this case, when the mobile node is on its home network, it also functions without "mobility services". In this case the box labeled "HA" is not a good choice for a default router, thus the MN uses neither its "home agent" functionality nor its "router" functionality when at home. Again, note that the media that comprises the home network can be anything, not necessarily wireless. Hope this helps. Regards, Jim S. ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14452; 20 Dec 95 12:00 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14448; 20 Dec 95 12:00 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa04319; 20 Dec 95 12:00 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA05232; Wed, 20 Dec 1995 10:52:44 -0600 Received: from mercury.Sun.COM by hosaka.smallworks.com (5.x/SMI-SVR4) id AA05219; Wed, 20 Dec 1995 10:52:27 -0600 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id IAA00684; Wed, 20 Dec 1995 08:52:25 -0800 Received: from jadeite.eng.sun.com (jadeite-92.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21208; Wed, 20 Dec 1995 08:52:23 -0800 Received: from localhost by jadeite.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14043; Wed, 20 Dec 1995 08:52:09 -0800 Date: Wed, 20 Dec 1995 08:50:21 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gabriel Montenegro Subject: (mobile-ip) reserved flag bits in the registration request To: mobile-ip@smallworks.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Gabriel Montenegro In the registration request description (section 3.3), Rev 13 of the mobile-ip specification does not mention how to treat the reserved bits, although one could surmise that an agent that does not fully understand a request must deny it lest it commit to something it cannot provide. This would happen if in the future we decide to use the rsvd bits for additional flags. I think these bits should not be ignored. Accordingly, I suggest adding text like the following to the packet fields description in section 3.3: rsvd Sent as zero; must be zero on reception. A request with non-zero rsvd bits would be rejected. FA's would perhaps use codes 70 or 64, whereas HA's could use codes 134 or 128. By the way, the draft does specify that the flag bits in the advertisements should be ignored on reception. This is fine, as there is a big difference between saying: "this is what I *could* do for you" and "this is what I *will* do for you." -gabriel ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16479; 20 Dec 95 13:49 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16475; 20 Dec 95 13:49 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa06692; 20 Dec 95 13:49 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA06410; Wed, 20 Dec 1995 12:40:22 -0600 Received: from CHIMAY.MACH.CS.CMU.EDU by hosaka.smallworks.com (5.x/SMI-SVR4) id AA06404; Wed, 20 Dec 1995 12:40:14 -0600 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa01556; 20 Dec 95 13:39:49 EST To: mobile-ip@smallworks.com In-Reply-To: Your message of "Wed, 20 Dec 95 20:39:11 +0800" Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Johnson Subject: Re: (mobile-ip) A Question Abt the Structure of Home Network Date: Wed, 20 Dec 95 13:39:48 EST Message-Id: <1554.819484788@CHIMAY.MACH.CS.CMU.EDU> X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Dave Johnson >Hi everybody > I am quite new here. I am a first year student of the National University >of Singapore. I am doing my first year project about MIP. > While reading the working group's draft-13, I found this point not >very clear. On page 31, it is said that when a mobile node comes home it >no longer needs the service of its home agent. If that is the case and >the mobile node is still served on the subnet by another router, then the >router must have a wireless interface and then it is likely that the >whole subnet is a wireless subnet by which I mean that every host >on the subnet is communicating with the default router using a wireless >network card. And that does not seem to be necessary. > I hope it is my wrong understanding. If anybody can give me a picture >of what the home network should be like according to the draft, I will be >very thankful. The "services" here (although vaguely worded) refer to the intercepting and tunneling of packets for the mobile node. While at home, the mobile node acts like and is treated like a normal (stationary) node that has never been mobile. This does not imply that the home network must be wireless, although it certainly may be. In particular, a mobile node may use a variety of different network interfaces (if it is equiped with such hardware) as it moves from one network to another. For example, we are using Mobile IP to transparantly move between an ethernet network, an AT&T WaveLAN network, and CDPD. When disconnected from the ethernet, the mobile node starts using the WaveLAN PCMCIA card as its network interface, for example, and when returning home to the ethernet, it again starts using its ethernet PCMCIA card. The mobile node switches over time which of these network interfaces it is using its home address on. Dave ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16723; 20 Dec 95 14:02 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16719; 20 Dec 95 14:02 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa06962; 20 Dec 95 14:02 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA06486; Wed, 20 Dec 1995 12:53:43 -0600 Received: from CHIMAY.MACH.CS.CMU.EDU by hosaka.smallworks.com (5.x/SMI-SVR4) id AA06480; Wed, 20 Dec 1995 12:53:35 -0600 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa01593; 20 Dec 95 13:53:04 EST To: mobile-ip@smallworks.com In-Reply-To: Your message of "Wed, 20 Dec 95 08:02:26 CST" <9512201402.AA12176@ssd.comm.mot.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Johnson Subject: Re: (mobile-ip) Host Unreachable Date: Wed, 20 Dec 95 13:53:02 EST Message-Id: <1591.819485582@CHIMAY.MACH.CS.CMU.EDU> X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Dave Johnson >I have a question regarding ICMP messages generated by an decapsulating >agent. Specifically, section 4 of the "IP Encapsulation within IP" >draft states the following: > >" After an encapsulated datagram has been sent, the encapsulating > agent may receive an ICMP [8] message from any intermediate router > within the tunnel, except for the tunnel endpoint. " > >This suggests that the tunnel endpoint (in my case, the FA/decapsulating >agent) _never_ generates ICMP messages with regard to the reachability >of a visiting host. > >In a radio environment, a unit (visiting host) can effectively be >considered "host unreachable" for a variety of valid reasons. >Furthermore, the unreachable period of time could be considerable. > >My question is: > >If my FA determines that a visiting host is temporarily unreachable, >is it "legal" for the FA to generate ICMP messages? No, you shouldn't generate an ICMP in that case, as this would break the transparency of mobility for the correspondent node. Suppose the mobile node has just left one foreign agent and then registers with another. It is possible for a tunneled packet to arrive at the old foreign agent after the mobile node has left that foreign agent. If you just drop that packet at the old foreign agent, the correspondent node will (generally) retarnsmit it, and the home agent will then be able to tunnel it to the right (new) foreign agent. If, instead, you returned an ICMP, this could cause the correspondent node to decide to give up on the connection. The ICMPs sent "from any intermediate router within the tunnel, except for the tunnel endpoint" indicate a problem getting the tunneled packet to the foreign agent. This is a very different problem, and doesn't really have much to do with mobility. On its way to the foreign agent, the tunneled packet looks just like a normal IP packet (it is!), and such a packet could encounter a normal problem in reaching the foreign agent, regardless of the motion of the mobile node. Dave ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26052; 20 Dec 95 22:01 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26048; 20 Dec 95 22:01 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa04025; 20 Dec 95 22:01 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA08388; Wed, 20 Dec 1995 16:32:02 -0600 Errors-To: "|/usr/majordomo/wrapper majordomo"@SmallWorks.COM Received: from greatdane.cisco.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA08381; Wed, 20 Dec 1995 16:31:49 -0600 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id OAA11236; Wed, 20 Dec 1995 14:31:43 -0800 Date: Wed, 20 Dec 1995 14:31:43 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199512202231.OAA11236@greatdane.cisco.com> To: dbj@cs.cmu.edu Cc: mobile-ip@smallworks.com In-Reply-To: <1591.819485582@CHIMAY.MACH.CS.CMU.EDU> (message from Dave Johnson on Wed, 20 Dec 95 13:53:02 EST) Subject: Re: (mobile-ip) Host Unreachable X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Tony Li >I have a question regarding ICMP messages generated by an decapsulating >agent. Specifically, section 4 of the "IP Encapsulation within IP" >draft states the following: > >" After an encapsulated datagram has been sent, the encapsulating > agent may receive an ICMP [8] message from any intermediate router > within the tunnel, except for the tunnel endpoint. " > >This suggests that the tunnel endpoint (in my case, the FA/decapsulating >agent) _never_ generates ICMP messages with regard to the reachability >of a visiting host. > >In a radio environment, a unit (visiting host) can effectively be >considered "host unreachable" for a variety of valid reasons. >Furthermore, the unreachable period of time could be considerable. > >My question is: > >If my FA determines that a visiting host is temporarily unreachable, >is it "legal" for the FA to generate ICMP messages? Yes, certainly. However, if the FA generates ICMP messages, they should return to the correspondent. That is, the ICMP generated by the FA would not be directed at the encapsulating agent. No, you shouldn't generate an ICMP in that case, as this would break the transparency of mobility for the correspondent node. ? I don't follow this. In any IP communications, you can get an ICMP unreachable for ANY transient. Getting an ICMP unreachable from a random IP address should in NO way change the correspondent's behavior (other than to throttle the data rate). Suppose the mobile node has just left one foreign agent and then registers with another. It is possible for a tunneled packet to arrive at the old foreign agent after the mobile node has left that foreign agent. If you just drop that packet at the old foreign agent, the correspondent node will (generally) retarnsmit it, and the home agent will then be able to tunnel it to the right (new) foreign agent. If, instead, you returned an ICMP, this could cause the correspondent node to decide to give up on the connection. And that would be the old 4.2BSD bug. This is a broken behavior in the non-mobile arena too. There is no need to code around it in MobileIP. Tony ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08296; 21 Dec 95 4:34 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08292; 21 Dec 95 4:34 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa07225; 21 Dec 95 4:34 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA27915; Thu, 21 Dec 1995 03:19:23 -0600 Received: from sable.nus.sg ([137.132.1.21]) by hosaka.smallworks.com (5.x/SMI-SVR4) id AA27909; Thu, 21 Dec 1995 03:19:00 -0600 Received: from leonis.nus.sg (isc50010@leonis.nus.sg [137.132.1.18]) by sable.nus.sg (8.6.10/8.6.9) with ESMTP id RAA11382 for ; Thu, 21 Dec 1995 17:17:55 +0800 Received: (from isc50010@localhost) by leonis.nus.sg (8.6.10/8.6.9/CNS-3.5) id RAA05605; Thu, 21 Dec 1995 17:17:25 +0800 Date: Thu, 21 Dec 1995 17:17:24 +0800 (SST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jiang Ming Liang To: mobile-ip@smallworks.com Subject: (mobile-ip) Encapsulating A Broadcast Packet Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Jiang Ming Liang As mentioned in P47 of IETF's MIP draft 13, when the Home Agent receives a broadcast packet it will(provided the B bit in the registration request is set) tunnel the packet to MN's home address first. Then again tunnel the packet to MN's care of address. This is not to let the broadcast being sent to FA's subnet. This seems quite tedious. Why not let the HA change the destination of the packet to the MN's home address, and tunnel it directly to MN's care-of address? So the MN needn't be capable of detunneling( if dynamically assigned card-of adddress is not considered). Does the node care about whether its neighbours on the same subnet receive the packet or not as well? Or the process is for other considerations. Thanks in advance for any kindly answers. Ming Liang ______________________________________________________________________ | _____ |Name: Jiang Ming Liang | | /'\_/`\ __ /\___ \ |Email: jiangmin@iscs.nus.sg | | /\ \ /\_\ \/__/\ \ | isc50010@nus.sg | | \ \ \__\ \ \/_/ _\ \ \ |Homepage: | | \ \ \_/\ \ /\ \_\ \ | http://www.iscs.nus.sg/~jiangmin | | \ \_\\ \_\ \ \____/ |Address: Sheares Hall, Lower Kent | | \/_/ \/_/ \/___/ | Ridge Rd,Singapore(0511) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08584; 21 Dec 95 5:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08580; 21 Dec 95 5:11 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa07999; 21 Dec 95 5:11 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA28954; Thu, 21 Dec 1995 04:02:23 -0600 Received: from greatdane.cisco.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA28948; Thu, 21 Dec 1995 04:02:12 -0600 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA14113; Thu, 21 Dec 1995 02:01:03 -0800 Date: Thu, 21 Dec 1995 02:01:03 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199512211001.CAA14113@greatdane.cisco.com> To: isc50010@leonis.nus.sg Cc: mobile-ip@smallworks.com In-Reply-To: (message from Jiang Ming Liang on Thu, 21 Dec 1995 17:17:24 +0800 (SST)) Subject: Re: (mobile-ip) Encapsulating A Broadcast Packet X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Tony Li As mentioned in P47 of IETF's MIP draft 13, when the Home Agent receives a broadcast packet it will(provided the B bit in the registration request is set) tunnel the packet to MN's home address first. Then again tunnel the packet to MN's care of address. This is not to let the broadcast being sent to FA's subnet. This seems quite tedious. Why not let the HA change the destination of the packet to the MN's home address, and tunnel it directly to MN's care-of address? So the MN needn't be capable of detunneling( if dynamically assigned card-of adddress is not considered). Does the node care about whether its neighbours on the same subnet receive the packet or not as well? Or the process is for other considerations. Several protocols and stacks will not accept a packet as a broadcast unless the IP broadcast address is still in the header. Tony ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10386; 22 Dec 95 10:34 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10382; 22 Dec 95 10:34 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa00618; 22 Dec 95 10:34 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA03914; Fri, 22 Dec 1995 09:30:50 -0600 Received: from watson.ibm.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA03908; Fri, 22 Dec 1995 09:30:43 -0600 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7085; Thu, 21 Dec 95 17:56:54 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 8389; Thu, 21 Dec 1995 17:56:54 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Thu, 21 Dec 95 17:56:53 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA25756; Thu, 21 Dec 1995 17:57:27 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Charlie Perkins Message-Id: <9512212257.AA25756@hawpub1.watson.ibm.com> To: Gabriel Montenegro Cc: mobile-ip@smallworks.com Subject: Re: (mobile-ip) reserved flag bits in the registration request In-Reply-To: (Your message of Wed, 20 Dec 95 08:50:21 PST.) Date: Thu, 21 Dec 95 17:57:27 -0500 X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Charlie Perkins I have inserted the following into the new draft to respond to your request. 1) I explicitly call out that the 'rsvd' bits should be sent as zero in a Registration Request. 3) In section 3.7.2.3 (Denying Invalid Requests), I specify: "If a foreign agent detects unknown bits set in the Reserved Bits field of the registration request, it must deny the request with status code 70." 3) In section 3.8.2.3 (Denying an Invalid Request), I also specify: "If a home agent detects unknown bits set in the Reserved Bits field of the registration request, it must deny the request with status code 134." I used the language shown instead of, say, "detects any bits", to cover the case (as with the 'T' bit) where a home agent does in fact recognize a bit which is set. ======================================================================== > By the way, the draft does specify that the flag bits in the > advertisements should be ignored on reception. This is fine, > as there is a big difference between saying: "this is what > I *could* do for you" and "this is what I *will* do for you." I agree with this analysis. > -gabriel Charlie P. ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11460; 22 Dec 95 11:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11456; 22 Dec 95 11:37 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa01925; 22 Dec 95 11:37 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA04146; Fri, 22 Dec 1995 10:27:43 -0600 Received: from ftp.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA04139; Fri, 22 Dec 1995 10:27:30 -0600 Received: from ftp.com by ftp.com ; Fri, 22 Dec 1995 11:27:29 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 22 Dec 1995 11:27:29 -0500 Received: from kasten.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA16928; Fri, 22 Dec 95 11:24:10 EST Date: Fri, 22 Dec 95 11:24:10 EST Message-Id: <9512221624.AA16928@mailserv-D.ftp.com> To: mobile-ip@smallworks.com, jhalpern@newbridge.com Subject: (mobile-ip) nonce patent number Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Repository: mailserv-D.ftp.com, [message accepted at Fri Dec 22 11:24:01 1995] Originating-Client: d-cell.ftp.com X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Frank Kastenholz hi what's the patent number for the 'nonce patent'? -- Frank Kastenholz ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11959; 22 Dec 95 12:05 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11955; 22 Dec 95 12:05 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa02455; 22 Dec 95 12:05 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA04245; Fri, 22 Dec 1995 10:57:58 -0600 Received: from watson.ibm.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA04239; Fri, 22 Dec 1995 10:57:50 -0600 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0349; Fri, 22 Dec 95 11:56:58 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 9218; Fri, 22 Dec 1995 11:56:57 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Fri, 22 Dec 95 11:56:57 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA26895; Fri, 22 Dec 1995 11:57:32 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Charlie Perkins Message-Id: <9512221657.AA26895@hawpub1.watson.ibm.com> To: Frank Kastenholz Cc: mobile-ip@smallworks.com, jhalpern@newbridge.com Subject: Re: (mobile-ip) nonce patent number In-Reply-To: (Your message of Fri, 22 Dec 95 11:24:10 EST.) <9512221624.AA16928@mailserv-D.ftp.com> Date: Fri, 22 Dec 95 11:57:32 -0500 X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Charlie Perkins As detailed in the newest mobility draft which is all set and ready to go in, it is Patent #5,148,479. Regards, Charlie P. ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12061; 22 Dec 95 12:09 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12057; 22 Dec 95 12:09 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa02537; 22 Dec 95 12:09 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA04330; Fri, 22 Dec 1995 11:05:10 -0600 Received: from motgate.mot.com by hosaka.smallworks.com (5.x/SMI-SVR4) id AA04324; Fri, 22 Dec 1995 11:05:02 -0600 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.7.1/8.6.10/MOT-3.8) with ESMTP id LAA17251; Fri, 22 Dec 1995 11:04:58 -0600 (CST) Received: from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by pobox.mot.com (8.7.1/8.6.10/MOT-3.8) with ESMTP id LAA12219; Fri, 22 Dec 1995 11:04:57 -0600 (CST) Received: from becks.comm.mot.com (becks.comm.mot.com [145.1.80.10]) by il02dns1.comm.mot.com (8.7.2/8.7.2) with SMTP id LAA23387; Fri, 22 Dec 1995 11:04:57 -0600 (CST) Received: from localhost by becks.comm.mot.com (4.1/SMI-4.1) id AA08179; Fri, 22 Dec 95 11:05:55 CST Message-Id: <9512221705.AA08179@becks.comm.mot.com> To: Frank Kastenholz Cc: mobile-ip@smallworks.com, jhalpern@newbridge.com Subject: Re: (mobile-ip) nonce patent number In-Reply-To: Your message of "Fri, 22 Dec 1995 11:24:10 EST." <9512221624.AA16928@mailserv-D.ftp.com> Date: Fri, 22 Dec 1995 11:05:53 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "James D. Solomon" X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: "James D. Solomon" In message <9512221624.AA16928@mailserv-D.ftp.com>, kasten@ftp.com (Frank Kastenholz) writes: > what's the patent number for the 'nonce patent'? Patent Number: #5,148,479 Title: Authentication Protocols In Communication Networks Inventor: Raymond F. Bird, et. al. Assignee: IBM Regards, Jim S. ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13738; 22 Dec 95 13:40 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13734; 22 Dec 95 13:40 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa04688; 22 Dec 95 13:40 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA04880; Fri, 22 Dec 1995 12:29:14 -0600 Received: from mercury.Sun.COM by hosaka.smallworks.com (5.x/SMI-SVR4) id AA04869; Fri, 22 Dec 1995 12:29:01 -0600 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id KAA17294; Fri, 22 Dec 1995 10:28:59 -0800 Received: from jadeite.eng.sun.com (jadeite-93.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01435; Fri, 22 Dec 1995 10:28:56 -0800 Received: from cali by jadeite.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04940; Fri, 22 Dec 1995 10:28:41 -0800 Date: Fri, 22 Dec 1995 10:28:53 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gabriel Montenegro Subject: Re: (mobile-ip) Re: "Dynamically acquired" care-of addresses To: mobile-ip@smallworks.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Gabriel Montenegro I agree with your objections to this term. I vote for using JI's old term "pop-up". After all, it's used often enough in discussions, might as well make it official. It has the advantage of being nice and short, and that people already have a fairly good idea of what it means. We would just need to include it in the definitions section and use it throughout. I'd suggest adding its definition right after the definition for care-of address in section 1.6. As a first shot: Pop-up A mobile node whose care-of address is an address associated to one of its own interfaces. This address may be a temporary address acquired dynamically (e.g. by means of DHCP or PPP's IPCP), or through manual intervention. It may also be a permanent address assigned to one of the mobile node's interfaces (e.g. a permanent PPP address). Since pop-ups do not require a separate foreign agent, they can operate in foreign nets that lack Mobile IP support. If "pop-up" is not acceptable, how about "independent mobile node"? -gabriel ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14198; 22 Dec 95 13:47 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04956; 22 Dec 95 13:47 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14174; 22 Dec 95 13:47 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13874; 22 Dec 95 13:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mobile-ip@tadpole.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-mobileip-mib-fa-00.txt Date: Fri, 22 Dec 95 13:41:59 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9512221342.aa13874@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : The Definitions of Managed Objects for the Foreign Agent function of IP Mobility Support Author(s) : D. Cong, M. Hamlen, C. Perkins Filename : draft-ietf-mobileip-mib-fa-00.txt Pages : 18 Date : 12/18/1995 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Foreign Agent function definied in the Mobile IP Protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-mib-fa-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-mib-fa-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-mib-fa-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951218153428.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mib-fa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mib-fa-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951218153428.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14320; 22 Dec 95 13:48 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04997; 22 Dec 95 13:48 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14182; 22 Dec 95 13:47 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13857; 22 Dec 95 13:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mobile-ip@tadpole.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-mobileip-mib-mn-00.txt Date: Fri, 22 Dec 95 13:41:52 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9512221341.aa13857@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : The Definitions of Managed Objects for the Mobile Node function of IP Mobility Support Author(s) : D. Cong, M. Hamlen, C. Perkins Filename : draft-ietf-mobileip-mib-mn-00.txt Pages : 20 Date : 12/18/1995 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node function definied in the Mobile IP Protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-mib-mn-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-mib-mn-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-mib-mn-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951218153050.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mib-mn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mib-mn-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951218153050.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14327; 22 Dec 95 13:48 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14305; 22 Dec 95 13:48 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04984; 22 Dec 95 13:48 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14176; 22 Dec 95 13:47 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13906; 22 Dec 95 13:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mobile-ip@tadpole.com X-Orig-Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-mobileip-mib-ha-00.txt Date: Fri, 22 Dec 95 13:42:05 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9512221342.aa13906@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : The Definitions of Managed Objects for the Home Agent function of IP Mobililty Support Author(s) : D. Cong, M. Hamlen, C. Perkins Filename : draft-ietf-mobileip-mib-ha-00.txt Pages : 19 Date : 12/18/1995 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Home Agent function definied in the Mobile IP Protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-mib-ha-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-mib-ha-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-mib-ha-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951218153730.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mib-ha-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mib-ha-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951218153730.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14330; 22 Dec 95 13:48 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04998; 22 Dec 95 13:48 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14184; 22 Dec 95 13:47 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13929; 22 Dec 95 13:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mobile-ip@tadpole.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-mobileip-mib-sec-00.txt Date: Fri, 22 Dec 95 13:42:10 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9512221342.aa13929@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : The Definitions of Managed Objects for the Security function of IP Mobility Support Author(s) : D. Cong, M. Hamlen, C. Perkins Filename : draft-ietf-mobileip-mib-sec-00.txt Pages : 12 Date : 12/18/1995 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security function definied in the Mobile IP Protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-mib-sec-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-mib-sec-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-mib-sec-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951218154117.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mib-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mib-sec-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951218154117.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01819; 26 Dec 95 11:24 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id af01786; 26 Dec 95 11:24 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa23467; 24 Dec 95 19:01 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA09685; Sun, 24 Dec 1995 17:53:34 -0600 Received: from piraya.electrum.kth.se by hosaka.smallworks.com (5.x/SMI-SVR4) id AA09679; Sun, 24 Dec 1995 17:53:25 -0600 Received: from nostromo.electrum.kth.se (nostromo.electrum.kth.se [130.237.215.5]) by piraya.electrum.kth.se (8.6.10/8.6.9) with ESMTP id AAA07923; Mon, 25 Dec 1995 00:54:20 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gerald Maguire Received: (maguire@localhost) by nostromo.electrum.kth.se (8.6.10/8.6.9) id AAA04025; Mon, 25 Dec 1995 00:54:17 +0100 Date: Mon, 25 Dec 1995 00:54:17 +0100 Message-Id: <199512242354.AAA04025@nostromo.electrum.kth.se> To: mobile-ip@smallworks.com Cc: d91-fta@it.kth.se, d91-fbr@it.kth.se Subject: (mobile-ip) draft-ietf-mobileip-mib-*-00.txt X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Gerald Maguire Some comments on these recent drafts: WRT: The Definitions of Managed Objects for the Security function of IP Mobility Support draft-ietf-mobileip-mib-sec-00.txt mipSecKey OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "The shared secret key for the security associations." ::= { mipSecAssocEntry 5 } ;;GQMjr: Why should this be readable? This certainly seems like a VERY bad idea from a security point of view. Even if you have some SNMP based managers that you trust there is no reason you would reveal all your secrets to them. WRT: The Definitions of Managed Objects for the Foreign Agent function of IP Mobility Support draft-ietf-mobileip-mib-fa-00.txt {Most of these also apply to the corresponding parts of the other 2 documents.} 3.1. Object Selection Criteria To be consistent with IAB directives and good engineering practice, the authors have applied some criteria to select managed objects for the Mobile IP Protocol. (1) Partition management functionality among the Mobile Node, Home Agent, and Foreign Agent according to the partitioning seen in the Mobile IP Protocol. For example, the editors minimize the management requirements in the Mobile Node. ;;GQMjr: lanuage: For example, the editors minimize the management requirements in the Mobile Node. ==> For example, the editors minimized the management requirements in the Mobile Node. ;;GQMjr: Minimizing the management requirements for the Mobile Node - sounds like it was based on traffic considerations NOT simply on the partitioning. While minimizing is also based on an aim of the Mobile-IP proposal it is not simply due to the partitioning. ;;GQMjr: proposed language: Thus in addition to partiting the MIB, the editors minimized the management requirements in the Mobile Node in line with Mobile-IP's efforts to minimize traffic to and from the Mobile Node. (2) Require that objects be essential for either fault or configuration management. ;;GQMjr: Why not include those that are also necesaary for performance measurement and tuning? An important element of configuring Mobile-IP for actual use with involve measuring dynamic characteristics and then modifying configurations so as to optimize some metric. faIsBusy OBJECT-TYPE SYNTAX Boolean ACCESS read-write STATUS mandatory DESCRIPTION "Whether or not the foreign agent is too busy to accept additional registrations. If true(1), the agent is busy and any Agent advertisements sent from this agent should have the 'B' bit set to 1." ::= { faAdvertisement 2 } ;;GQMjr: language Why explicity state "true(1)" here and not in the earlier booleans? faVisitorRegFlags OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Registration flags sent by mobile node. Flags can be distinguished by applying the appropriate testing bit. Flag Bitmask Indication S 0x80 Request to retain prior binding B 0x40 Request to recieve broadcasts D 0x20 COA is local to mobile node M 0x10 Request to use minimal enc. G 0x8 Request to use GRE." ::= { faVisitorEntry 8 } ;;GQMjr: language: spell out "enc" ;;GQMjr: Why can't the user specify ipinip? The above assumes that there are only 3 values - thus specifying or not 2 of them is sufficient; but of course it is not. ;;GQMjr: Don't include the request corresponding to "Agent supports VJ compress." Thus you can't know if you have any requests for this type of service. Therefore you could NOT determine that perhaps you should offer this service (based on requests from users). Unless, a potential client will never ask, unless you advertise the service. faVisitorRegIsAccepted OBJECT-TYPE SYNTAX Boolean ACCESS read-write STATUS mandatory DESCRIPTION "Whether the registration has been accepted or not. If it is false(2), this registration is still pending for reply." ::= { faVisitorEntry 11 } ;;GQMjr: Here you use "false(2)", why not say "Unless, true(1), this registration is still pending, i.e. awaiting a reply." faRegRequestsRelayed OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of registration requests relayed to home agent by foreign agent." ::= { faRegistration 3 } ;;GQMjr: Why aren't the reasons simply a vector or a list of tuples (code_number, count) ? ;;GQMjr: This would support the addition of new codes without having to change the Mobile IP MIB doc. faReasonUnspecified OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of registration requests denied by foreign agent -- reason unspecified (Code 64)." ::= { faRegistration 4 } ... WRT: The Definitions of Managed Objects for the Mobile Node function of IP Mobility Support draft-ietf-mobileip-mib-mn-00.txt mnAdvFlags OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The flags contained in the most recently received advertisement. Flags can be distinguished by applying the appropriate testing bit. Flag Bitmask Indication R 0x8000 FA registration required B 0x4000 FA Busy bit H 0x2000 Agent is Home Agent F 0x1000 Agent is Foreign Agent M 0x800 Agent offers minimal enc. G 0x400 Agent offers GRE V 0x200 Agent supports VJ compress." ::= { mnRecentAdvReceived 3 } ;;GQMjr: Spell-out compression, encapsulation, etc. mnMoveFromHAToFA OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of times that the mobile node has detected movement from its home network to a foreign network." ::= { mnDiscovery 7 } ;;GQMjr: Does this "detected movement" mean: a. possible movement allowed OR b. movement actually made ? mnRegIsAccepted OBJECT-TYPE SYNTAX Boolean ACCESS read-only STATUS mandatory DESCRIPTION "True(1) if the mobile node has received a Registration Reply indicating that service has been accepted; false(2) otherwise. False(2) implies that the registration is still pending." ::= { mnRegistrationEntry 9 } ;;GQMjr: What value is used to indicate that registration was NEVER attempted? Since one possible reaction to heading an advertisement is to simply remember it (perhaps to use it for the short list of where to check in the future) - while not attempting to register. Cheers, Chip ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11310; 27 Dec 95 10:10 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11287; 27 Dec 95 10:10 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08814; 27 Dec 95 10:10 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11126; 27 Dec 95 10:10 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10723; 27 Dec 95 9:51 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: mobile-ip@tadpole.com X-Orig-Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-mobileip-protocol-14.txt Date: Wed, 27 Dec 95 09:51:18 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9512270951.aa10723@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : IP Mobility Support Author(s) : C. Perkins Filename : draft-ietf-mobileip-protocol-14.txt Pages : 68 Date : 12/26/1995 This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends packets destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, the packets are then delivered to the mobile node. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-protocol-14.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-protocol-14.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-protocol-14.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951226141356.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-protocol-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-protocol-14.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951226141356.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20471; 29 Dec 95 21:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20467; 29 Dec 95 21:50 EST Received: from hosaka.SmallWorks.COM by CNRI.Reston.VA.US id aa09778; 29 Dec 95 21:50 EST Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA28098; Fri, 29 Dec 1995 20:38:42 -0600 Received: from tadpole (tadpole.Tadpole.COM) by hosaka.smallworks.com (5.x/SMI-SVR4) id AA28092; Fri, 29 Dec 1995 20:38:33 -0600 Received: from ([166.104.36.47]) by tadpole (8.6.10/8.6.10) with SMTP id UAA12754 for ; Fri, 29 Dec 1995 20:38:27 -0600 Received: by (4.1/SMI-4.1) id AA23163; Sat, 30 Dec 95 11:40:15 KST Date: Sat, 30 Dec 95 11:40:15 KST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yong-Jin Park Message-Id: <9512300240.AA23163@> To: mobile-ip@tadpole.com Subject: (mobile-ip) submission X-Orig-Sender: owner-mobile-ip@smallworks.com Precedence: bulk Reply-To: Yong-Jin Park Please put my name on mailing address of the Mobile IP email newsgroup. park@hyuee.hanyang.ac.kr Yong-Jin Park ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com